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:

Feature branch’s commit log, prior to merging with master

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:

Our branch’s commit log after merging from master. Note branch’s commits are not on top, and you must scroll down to find them.

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:

Our branch’s commit log after rebasing over master. Notice our feature branch’s commit appear on top, with a timestamp as if they were applied right now — which logically, they were.

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:

Cleanest Git log possible, using rebase interactive

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.