We use ‘git rebase’ and so should you
Why startups must understand and harness the power of rebasing
We rebase our branches instead of merging from master, and so should you.
It doesn’t matter if your start-up devs are new to Git or have weak Git-fu. Rebasing, while a little scary at first, offers you an easy ability to review your history cleanly, enabling a clear view of your codebases’s changes over time. Let’s view an example of how the commit log differs when merging versus rebasing.
Suppose you’ve been developing for a while and it’s time to merge your code with master. Here’s our feature branch’s commit log, prior to merging with master, in the terminal:
Or on Github:
The naive next step (often suggested by many Git tutorials) is to run a merge, to grab latest changes made to master:
feature_branch > git merge master
After merging, we solve whatever conflicts may arise, and verify by running a diff vs master to ensure it holds only our changes. All looks spiffy, until we inspect the commit log again:
Notice, all of the feature_branch commits are below the commits from master. Indeed, the same such order will be visible on Github:
Since we merged, Git ‘splices’ the commits together, resulting in a mixed history defined by the chronological time at which the commits were made and branches were merged. From this commit log, you can’t even see what the latest changes to the codebase have been, and you certainly won’t immediately see that we added the changes in feature_branch.
This is the essence of git merge and the underlying problem when merging master into your branch.
This might seem like a minor problem — it’s just the commit log, who cares? The end result — the code — is what you wanted it to be.
But consider your coworker, inspecting your work and reviewing changes to the codebase. (Specifically, when shit breaks and she is trying to track down what changed, that might have broke the site.) By looking at the commit log, she has no chance of knowing what the recent changes to the codebase have been. Sucks to be her. If you or she wish to revert some commit — how would you find the offending commit? It’s nigh impossible.
How can we use Github to add master’s code to our branch, such that our commits appear on top?
Enter rebase. Let’s pretend we never merged from master and go back to our pre-merged branch. This time, we’ll run:
feature_branch > git rebase master
Rebase grabs master and applies our commits ‘on top’ of them — which logically, is what the end result will be anyway. The resultant commit log looks like this:
And on Github:
Notice our feature_branch commits are on top, above master’s commits.
Now all the ‘top’ commits are the feature_branch’s, regardless of when they were chronologically made — which is what we would expect from a commit log, after I push my changes.
Once a startup hits a certain size, it’s going to have a lot of people submitting changes to the shared codebase(s), all the time. Situations will arise presenting a need to inspect what the most recent changes have been — if you merge from master, your commit log will be a mess and it will be very difficult to figure out what has happened. If you rebase over master you will be able to immediately see the latest set of changes applied to the codebase.
For extra credit (which we’ll cover elsewhere), you should rebase -i to squash together your commits. The end result after that will be a minified set of one or more commits (as per your choosing), culminating in a pretty, easy-to-read log:
Dig it — all of our feature_branch’s changes encapsulated into one commit message. Or on Github:
So, where does that leave us?
It doesn’t matter if your start-up has a lot of [Git] newbs with weak Git-fu. Rebasing, while a little scary at first, offers you the control to review your history cleanly, enabling a clear view of your codebases’s changes over time.
Be kind — rebase.