How to avoid merge commits when syncing a fork

Whenever you work on open source projects, you usually maintain your copy (a fork) of the original codebase. To propose changes, you open up a Pull Request (PR). After you create a PR, there are chances that during its review process, commits will be made to the original codebase, which will require you to sync your fork.

To sync your fork with the original codebase, ideally, you would use the web UI provided by your Git hosting service or run a git fetch and git merge in your terminal, as indicated in this Github tutorial. But with a PR open, syncing your fork that way will introduce an unwanted merge commit to your PR.

In this article, you will learn:

• what merge commits are and
• how to avoid them with git rebase when syncing a fork with an original codebase.

What is a merge commit?

A merge commit is just like any other commit, it is the state of a repository at a point in time plus the history it evolved from. But there is one thing unique about a merge commit: it has at least two parent commits.

When you create a merge commit, Git automatically merges the histories of two separate commits. This merge commit can cause conflicts and mess up a project’s Git history if present in a merged PR.

The annotated section in the image above shows a merge commit of two parent commits. Here is the link to the merge commit to the image.

Now you know what a merge commit is. Next, you will learn how to avoid it when syncing your fork with an original codebase.

How to avoid merge commits when syncing a fork in Git.

To avoid merge commits, you need to rebase the changes from the original remote codebase in your local fork before pushing them to your remote fork by following the steps below.

Step 1:
Create a link with the original remote repository to track and get the changes from the codebase with the command below:

$ git remote add upstream https://github.com/com/original/original.git

After running the above command, you will now have two remotes. One for your fork and one for the original codebase. If you run $ git remote -v, you will see the following:

origin https://github.com/your_username/your_fork.git (fetch)
origin https://github.com/your_username/your_fork.git (push)
upstream https://github.com/original/original.git (fetch)
upstream https://github.com/original/original.git (push)

In the above, upstream refers to the original repository from which you created the fork.

Step 2:
In this step, you fetch all the branches of the remote upstream with:

$ git fetch upstream

Step 3:
Next, you rewrite your fork’s master with the upstream’s master using git rebase.

$ git rebase upstream/master

Step 4:
Then finally, push the updates to your remote fork. You may need to force the push with “--force.”

$ git push origin master --force

Note:
You can skip the git fetch step by using git pull which is git fetch + git merge but with the --rebase  flag to override the git merge. The pull command will be:

$ git pull --rebase upstream master

Conclusion

In this article, you learned about merge commits and how you can avoid them when syncing your fork in Git using git rebase. There is a lot more to learn about git rebase. To learn more, check out the following resources:

• Git rebase official documentation
• What is Git Rebase, and How Do You Use It?
• Difference Between git merge and rebase