Introduction

To pull a branch from somebody else’s repository, you usually add their repository as another Git remote, fetch from it, and then create a local branch that tracks the fetched branch. The key idea is that Git branches live under remotes, so you do not “pull from a person” directly. You fetch from a named remote and then check out the branch you want.

Add the Other Repository as a Remote

Suppose your main repository already has origin, and you want to access a collaborator’s fork.

git remote add alice https://github.com/alice/project.git
git remote -v

Now Git knows about another source of branches called alice.

This does not change your current branch or your main remote. It only tells Git where else it can fetch from.

Fetch the Remote Branches

After adding the remote, fetch its refs:

git fetch alice

Now you can inspect the branches available from that remote:

git branch -r

You should see names such as:

alice/feature-x
alice/fix-login

Check Out a Local Branch That Tracks It

If you want to work on alice/feature-x, create a local branch from it:

git checkout -b feature-x alice/feature-x

Or with newer switch syntax:

git switch -c feature-x --track alice/feature-x

Now you have a local branch based on the other person’s remote branch.

Pull Later Updates from That Same Remote Branch

Once your local branch tracks the remote branch, you can update it by pulling from the specific remote:

git pull alice feature-x

Or, if your branch tracking is configured correctly, plain git pull may be enough while you are on that branch.

Being explicit is safer when multiple remotes are involved.

Fetch Without Adding a Permanent Remote

If you only need the branch once, you can fetch it directly by URL:

git fetch https://github.com/alice/project.git feature-x
git checkout -b feature-x FETCH_HEAD

This is useful for one-off review work, but if you expect repeated collaboration, a named remote is cleaner.

Understand the Difference Between fetch and pull

git fetch downloads refs without merging them into your current branch.

git pull is roughly:

1. fetch
2. merge or rebase into the current branch

When working with somebody else’s repository, starting with fetch is often safer because it lets you inspect the branch before integrating anything into your current work.

If the Repository Is a Fork

A common setup is:

• 'origin = your fork'
• 'upstream = original repository'
• 'alice = collaborator fork'

That is perfectly valid. Git can work with as many remotes as you need, as long as you keep the names clear and avoid assuming everything comes from origin.

Verify Before Merging

After checking out the collaborator branch, inspect the history:

git log --oneline --decorate --graph -n 20

This matters because it tells you whether the branch is based on the expected mainline, whether it is stale, and whether merging it into your own branch will be straightforward.

Remove the Remote If It Was Temporary

If you only needed the collaborator remote briefly, remove it when you are done:

git remote remove alice

That keeps the repository configuration tidy and avoids clutter in tools that show all remotes and remote branches.

Common Pitfalls

The biggest mistake is confusing a remote branch name such as alice/feature-x with a local branch. Another is using git pull too early instead of fetching and inspecting first. Developers also sometimes create a local branch but forget which remote it tracks, which leads to later pulls going to the wrong place. Finally, if the collaborator repository is private, authentication and access must be working before any fetch or pull command will succeed.

Summary

• Add the other repository as a Git remote.
• Fetch its branches before trying to check one out.
• Create a local branch that tracks the collaborator’s remote branch.
• Prefer fetch first and inspect before merging or rebasing.
• Remove temporary remotes when they are no longer needed.