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
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 B, and
commit C. The second,
F. The third,
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.
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
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.