Always be rebasing
ABR — Always Be Rebasing. Thats our mantra. It’s one of those small software industry things everyone has to learn. But it doesn’t seem to be taught anywhere other than blog posts and by annoyed coworkers.
This is how you start your day. Roll out of bed, open laptop, start Spotify, rebase. Now go make coffee.
The most basic use case for git rebase is keeping your development branch up to date with trunk. Whether that refers to master, develop, or your favorite epic or feature branch is up to you and your team. But it solves so many workflow issues and the positive impact on velocity starts to add up.
- Someone else broke the build? Ask them to fix it and then rebase.
- Epic merge conflict? Should have rebased when you woke up. And again.
- Tests passed on your feature branch but not after you merged to master? Should have rebased and ran tests on the union of both.
- Git log full of meaningless merge commits? Should have rebased instead.
- Returning to an abandoned branch that you want to update, but you also want all of the relevant commits near the top for an easy squash merge later? Rebase.
- Git bisect isn’t helpful because your log is full of dirty commits that don’t pass tests? Rebase interactive and squash.
If you’re working in a small team some of these problems might seem a bit contrived. But once you reach a certain size you won’t be able to keep up with the pace at which code is reviewed and landed by other teams anymore.
When you’re big enough that you can’t even merge a PR without rebasing twice back to back someone will probably suggest you need a submit queue. It’s also when I start using ugly scripts like this one instead of simply autocompleting git rebase.
¯\_(ツ)_/¯
ABR.
