As part of The 12 Days of #Commitmas, we’re all practicing our git-fu. I’ve learned a bit about rebasing that I’d like to show you now.
Why are we rebasing?
The definition, from man git-rebase, is “Forward-port local commits to the updated upstream head.” Clear as mud, if you ask me. Another way of putting it is that a rebase moves a branch to a new base commit. Let’s say you create a new branch from master on the 1st of the month and make two changes, then a week goes by. A half dozen changes have been made to master and your branch doesn’t have it. You can rebase your commits against the current master rather than the original master. Underneath the hood, git is rewriting the project history to achieve all of this. All the commits are actually new. This means the checksums for commits are unique (we’ll look at why that matters in a moment).
This is great for integrating your feature against the master and maintaining a linear history. There’s another reason we might want to rebase, though – maintaining a clear history.