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 rebasing developers will 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 romanticize 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, and be careful, should you choose to rebase!