Why Git Rebase is Only for Experts
A surefire way to get into trouble with Git is by using rebase. Messing up here is so common that developers who use rebase often say they expect to make a mistake eventually. Before you know it, you're entering a world of pain, and getting out of trouble can prove very complicated.
Last night, I was reading an excellent blog post by Julia Evans called Git Rebase: What Can Go Wrong? In the post, Evans describes some of the most common problems you can encounter when rebasing and how to solve them. Some of these solutions may save you if (or when) you get into trouble.
Common problems include:
Fixing the same conflict repeatedly is annoying
Rebasing a lot of commits is hard
Undoing a rebase is hard
Force pushing can cause lost work
Force pushing makes code review harder
Loosing commit metadata
More difficult reverts
Rebasing can break intermediate commits
Accidentally run git commit --amend instead of git rebase --continue
splitting commits in an interactive rebase is hard
rebasing long lived branches can be annoying
(and more!)
All these pitfalls, and still, we keep rebasing. We keep getting into trouble because many Git beginner guides and HOWTOs frequently introduce rebase as a tool people should use far too early in their Git learning journey.
Another reason is that we care too much about having a neat and linear commit history.
Evans says it, too:
I think the goal of rebase is to have a nice linear commit history, which is something I like.
Rebase is a way to accomplish this, and because of that, developers tend to romanticise rebasing.
Git is built for concurrent and distributed workflows and does not care if history is linear. The bigger your team is, the more complex it becomes to make the commit history linear. Git rebase is a way of rewriting history. Like a time machine for your code base, it can move commits around and change the order of events.
Evans states that the goal of the "What can go wrong?" post isn't to convince anyone that rebase is bad and that you shouldn't use it. It is a potent tool in your tool belt, but as the Peter Parker Principle says, with great power comes great responsibility. Most of us may have seen a movie or two involving time travel, but have you ever seen one where altering the space-time continuum is considered safe?
In Conclusion
My advice to developers is this: unless you're a Git expert, do not rebase. It's not necessary. Far too many developer hours have been lost attempting to avoid "ugly" commit graphs. Having a "clean" commit history is less important than you think.
I'll leave you with this YouTube Short from Prefab, where he explains how to configure your computer to play Highway to the Danger Zone whenever the rebase command is triggered.
Have a great day!
-Steffen
P.S. You can reply to this email; it will get to me, and I will read it.