March 18, 2019

Rebasing commits instead of merging

When working with Git it is not uncommon for work to be done in parallel to each other on different branches. Sooner or later these branches will either be merged together or diverge more and more. Sometimes two features might depend on each others changes.

Lets say that you are building a new feature for playing sounds whenever the user presses a button ( awesome feature, I know…). At the same time, some changes are being made to the Audio API so that some parameters will be different when calling playSound. If you just ignore these changes until you are done with the feature you will end up with merge conflicts at the time of merging your branch into master. A better way is to get those changes as soon as possible and continue to make your feature based on those changes.

One option is to simply merge the changes from the master branch into your feature branch and continue working.


1
2
git checkout {branch}
git merge master

The problems with this approach might not seem obvious at first, but in time and when more people are working on the same project some issues start to occur.

First, more merge commits are now being made with no meaningful content in them, meaning more noise is being added to the history. Second, starts to look more and more like a tangled mess which makes it very hard to follow what is going on.

An example of a tangled git log with a lot of merge commits.

Since git commits only apply changes to the repository, a better approach is to start basing your changes on the new Audio API changes, using git rebase. This essentially takes your changes and make it seem as if you started your work after the new API changes were made.

To perform a rebase in the terminal start by checking out the branch you would like to rebase on and make sure you are up to date. In this example we will rebase on master.


1
2
git checkout master
git pull

Once that’s done, go back to your branch and type the following.


1
2
git checkout {branch_name}
git rebase master

That’s it! Now, you might have to solve some conflicts that you need to solve. In that case you have to manually solve the conflicts and then, in the terminal type


1
git rebase --continue

Below is a graphical comparison of how using merge and rebase can look like after it’s completed.

On the left the new changes on master are first merged into the branch before the branch itself is merged into master. On the right, the changes on the branch (starting from c5) are rebased on the newest changes and then merged into master once they are completed.

The benefits of rebasing are the following:

  • It’s easier to discover where bugs were introduced. Since all the commits are not tangled up it’s easier to follow the changes as a straight line.
  • It’s easier to revert commits.
  • You get a cleaner history that is easier to follow and your team easily keep up.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *