Git Rebase vs. Merge

Before I worked on a large application with many other developers, I never put much thought into the git process. I learned the basic commands required to collaborate with one other person and push personal projects to Github.

I had never heard of git rebase until a coworker suggested our team start using it instead of git merge. We’re all in different time zones and pushing changes throughout the day to the dev branch. When I was ready to push my code, I would switch to the dev branch and pull the changes:

git checkout dev
git pull

And then go back to my branch and merge the current dev branch into my own:

git checkout my_branch
git merge dev

Then I would test my changes and make sure everything was still working fine.

While merging allowed us to test our code with other developers’ code before adding the changes to the dev branch, it made a mess of the repository’s commit history. If anyone needed to trace a bug back to its source, it would be extremely difficult to follow the history of the project.

This is because git merge takes all of my commits and inserts them chronologically into the list of commits that have been added to the dev branch since I created my own branch.

For example, let’s say there are three developers who all create branches from the dev branch at the same time. Each developer makes three commits. The first developer names them commit A, commit B, and commit C. The second, D, E, and F. The third, G, H, and I.

The first developer pushes his changes to dev first. Then, the second developer uses git merge dev to test their changes with the first developer’s and the third developer does the same.

The commit history ends up like this:

All of the commits are ordered by when they happened, but we want them to be grouped by contribution. It would be a lot easier to read this history if it were ordered, in this case, alphabetically. Also, it would be nice to get rid of those extra merge commits before each pull request.

Enter git rebase. While git merge dev commits the changes from dev to my working branch, git rebase dev takes the dev branch and makes it the HEAD of my working branch, placing my changes on top of the current dev branch.

In other words, it’s like I created my branch from the current dev, not the outdated dev code I did create it from.

For example, if we take the same three developers from before with the same commits in the same chronological order, but we use git rebase dev instead of git merge dev, we’ll see the difference in the commit history:

Now that I’m looking at it, I realize I should have used the same letters as before. Nevertheless, you can see how much cleaner this is. The commits are in alphabetical order and divided by the pull request merge, making it really easy to see each developer’s contribution.