Introduction

To pull a branch from another repository, you do not clone everything again. The usual Git workflow is to add that repository as another remote, fetch its branches, and then either create a local branch from the fetched ref or merge, rebase, or cherry-pick from it.

Add the Other Repository as a Remote

Start by giving the other repository a remote name:

git remote add teammate https://git.example.com/team/project.git
git fetch teammate

Now Git knows about the refs in that repository, such as:

teammate/feature-x
teammate/fix-auth

You can inspect them with:

git branch -r

This step is better than copying patches around because it lets Git manage history normally.

Create a Local Branch from the Remote Branch

If you want to work directly on that branch locally:

git switch -c feature-x teammate/feature-x

This creates a new local branch named feature-x starting from the fetched remote-tracking branch.

You can now review, test, and modify the code just like any other local branch.

If you do not want the same local name, pick another one:

git switch -c review-feature teammate/feature-x

Merge the Branch into Your Current Work

If your goal is not to check out the branch directly, but to bring it into your current branch, fetch first and then merge:

git switch main
git fetch teammate
git merge teammate/feature-x

That creates a normal merge using the branch from the other repository as input.

This is common when reviewing work from a fork or from a repository that is not your default origin.

Rebase or Cherry-Pick Instead of Merging

You are not limited to merge. Once the branch has been fetched, it behaves like any other reachable ref.

Rebase example:

git switch my-feature
git fetch teammate
git rebase teammate/feature-x

Cherry-pick example:

git fetch teammate
git cherry-pick teammate/feature-x~2..teammate/feature-x

Use these only when they match the history shape you want. Merge is usually the most straightforward option when the goal is simply "bring in that branch."

Pull Directly from a URL When You Must

Git also allows a direct fetch or pull from a repository URL without permanently adding a named remote:

git fetch https://git.example.com/team/project.git feature-x

That can be useful for one-off situations, but it is less convenient than a named remote if you expect to interact with the repository repeatedly.

In practice, a named remote is cleaner because you can fetch again later and Git remembers where the branch came from.

Understand the Difference Between fetch and pull

People often say "pull a branch from another repository," but in Git terms:

• 'fetch downloads refs and objects'
• 'pull is usually fetch plus merge or rebase into the current branch'

When the repository is not one of your normal remotes, fetch is often the safer first step because it lets you inspect what arrived before deciding how to integrate it.

That is why many experienced Git users avoid a blind pull here and prefer:

git fetch teammate
git log --oneline --decorate teammate/feature-x -5

Then they decide whether to check out, merge, rebase, or cherry-pick.

Clean Up When You Are Done

If the extra remote was only temporary, remove it:

git remote remove teammate

That keeps your repository configuration tidy. The local branches and commits you already created remain in your repository; removing the remote only removes the remote configuration.

Common Pitfalls

• Trying to git pull from another repository before adding or fetching it as a remote.
• Forgetting that fetch alone does not change your current branch.
• Merging a remote branch when you really wanted to inspect it on a local branch first.
• Using cherry-pick for an entire branch when a merge would preserve history more cleanly.
• Leaving one-off remotes around and later forgetting where they came from.

Summary

• The standard way to pull a branch from another repository is git remote add, then git fetch.
• After fetching, you can check out a local branch from the remote-tracking branch or merge, rebase, or cherry-pick from it.
• 'fetch is usually safer than a blind pull because it separates download from integration.'
• Named remotes are better than one-off URL fetches when you expect repeated interaction.
• Once the branch is fetched, Git treats it like any other reachable branch reference.