Introduction

To merge code from someone else's fork, you first fetch their branch into your local repository, then merge or cherry-pick it into the branch you want. The core Git idea is simple: a fork is just another remote source of commits.

Add the Fork as a Remote

Assume you already cloned the main repository and the original project is your origin or upstream. To bring in another contributor's fork, add it as a remote.

git remote add alice https://github.com/alice/project.git
git fetch alice

Now your local repository knows about branches from Alice's fork, such as alice/feature-branch.

You can inspect available branches with:

git branch -r

Merge the Fork Branch Into Your Branch

If you want to merge Alice's branch into your current local branch:

git checkout main
git pull
git merge alice/feature-branch

This creates a normal merge using the fork branch as the other side of the merge.

If the project uses a feature branch workflow, you might instead do:

git checkout my-integration-branch
git merge alice/feature-branch

That keeps main clean until you are ready.

Resolve Conflicts Like Any Other Merge

There is nothing special about conflicts just because the commits came from a fork. If Git reports a conflict, open the affected files, resolve the markers, then continue:

git add path/to/conflicted-file
git commit

At that point, you can push the merged result to your own remote.

When Cherry-Pick Is Better Than Merge

Sometimes you do not want the whole branch history. You only want one or two commits from the fork. In that case, fetch the fork and cherry-pick the specific commit instead of merging the full branch.

git cherry-pick <commit-sha>

That is useful when the contributor branch contains extra work you are not ready to merge.

Clean Up the Temporary Remote

If you added the fork remote only for one review, you can remove it afterward:

git remote remove alice

That keeps the local repository tidy, especially if you review many outside forks over time.

A Practical Review Workflow

A clean workflow looks like this:

1. Add the fork as a temporary remote
2. Fetch the remote branch
3. Create a local review branch
4. Merge or cherry-pick the changes
5. Run tests and review the diff
6. Push only after the integrated branch looks correct

This keeps the main branch stable and makes review easier.

If the hosting platform already has a pull request open, that pull request is often the safest review surface. The Git steps are still useful when you need to inspect the fork locally before approving or integrating it.

Common Pitfalls

• Do not confuse a local clone with a hosted fork. Git treats them both as remotes once you add the URL, but the collaboration workflow around them is different.
• Merging a contributor branch straight into main is often too aggressive; use a review branch when possible.
• If you only need one commit, merging the whole fork branch may bring in extra changes you did not intend to accept.
• Remember to fetch the fork remote before trying to merge its branch names locally.

Summary

• Add the fork as a remote, then fetch it.
• Merge the contributor branch like any other remote branch.
• Use cherry-pick when you want only selected commits instead of the whole branch.
• Treat fork integration as a normal Git review step, not as a special Git mode.