Why You Should Consider Using `git-rebase`

Why You Should Consider Using `git-rebase`

For a long time, I was telling myself how ugly merge bulks were on my git history. Then I learned about git-rebase and how clean my history can be thanks to this command.

I remember a debate with one of my former CTO on how consistent git-rebase is even for the history on a uniq branch, like master.

His point was that having a merge bulk in our history represents the reality, ie different developers worked in parallel on the same project on the same branch at the same time. It's just a matter of graph.

My point is that using rebase does not hide this parallelism in the project history and allows a cleaner and more linear history. It is way simpler to read, in my point of view at least. But I do not have a real argument against the graphical representation.

Then I went through some lectures and something went in my mind. To explain it, I will shortly explain what rebase is about.

The rebase, as its noun indicates, reset the starting point of a branch and reapplies the set of commits you are fetching. Merge conflicts are combined with these commits so they become grouped together. And that, my friends, it is a huge difference to me!

Using merge to pull in changes mixes those changes with the resolved merge conflicts. This means that the current branch won't necessarily have the same state as the one it was based on (from the hierarchical structure). Since the resolved conflicts are grouped all together in one merge commit, you have also made it harder to cleanly cherry-pick individual changes.

This cherry-pick stuff is one of the reasons you really should consider using rebase.

If you can bring me more, I would really be happy about that! Feel free to comment.


For more details on git-rebase and git-merge, read git merge vs git rebase: Avoiding Rebase Hell by Jarrod Spillers. If you are still afraid of git-rebase, you should read The Magical (And Not Harmful) Rebase by Jeff Kreeftmeijer.

Show Comments