Understanding Git (Rebase)
Today we’ll be talking about a feature of git that is often misused and even more so misunderstood. Rebasing, can help make a projects git history significantly easier to understand and help make a complicated project much more accessible to new contributors. Firstly though, what is rebasing?
What is git rebase?
The first thing to understand about git rebase
is that it is intimately related to git merge
. Both of these commands are designed to integrate changes from one branch into another branch—they just do it in very different ways.
Consider what happens when you start working on a new feature in a new branch, then another team member updates the master
branch with new commits. This results in a forked history, which should be familiar to you all.
Now, let’s say that the new commits in master
are relevant to the feature that you’re working on. To incorporate the new commits into your feature
branch, you have two options: merging or rebasing.
The easiest way to merge these features from master branch into your feature branch would be to git merge
leaving you with a git history a little like this:
Merging is great because it’s a non-destructive operation. The existing branches are not changed in any way. This avoids all of the potential pitfalls of rebasing, which we’ll discuss below.
On the other hand, this also means that the feature
branch will have an extraneous merge commit every time you need to incorporate upstream changes. If master
is very active, this can pollute your feature branch’s history quite a bit.
Rebasing
As an alternative to merging, you can rebase the feature
branch onto master
branch using the following commands:
git checkout feature
git rebase master
This moves the entire feature
branch to begin on the tip of the master
branch, all of the new commits are incorporated into master
. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
The major benefit of rebasing is that you get a much cleaner project history. First, it eliminates the unnecessary merge commits required by git merge
. Second, as you can see in the above diagram, rebasing also results in a perfectly linear project history—you can follow the tip of feature
all the way to the beginning of the project without any forks.
But, there are two trade-offs for this pristine commit history: safety and traceability. If you don’t follow the Golden Rule of Rebasing, re-writing project history can be potentially catastrophic for your collaboration workflow. And, less importantly, rebasing loses the context provided by a merge commit — you can’t see when upstream changes were incorporated into the feature.
Interactive Rebasing
Interactive rebasing gives you the opportunity to alter commits as they are moved to the new branch. This is even more powerful than an automated rebase, since it offers complete control over the branch’s commit history. Typically, this is used to clean up a messy history before merging a feature branch into master
.
To begin an interactive rebasing session, pass the i
option to the git rebase
command:
git checkout feature
git rebase -i master
This will open a text editor listing all of the commits that are about to be moved:
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
This listing defines exactly what the branch will look like after the rebase is performed. By changing the pick
command and/or re-ordering the entries, you can make the branch’s history look like whatever you want. For example, if the 2nd commit fixes a small problem in the 1st commit, you can condense them into a single commit with the fixup
command:
pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
When you save and close the file, Git will perform the rebase according to your instructions, resulting in project history that looks like the following:
Eliminating insignificant commits like this makes your feature’s history much easier to understand. This is something that git merge
simply cannot do.
The Golden Rule of Rebasing
Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase
is to never use it on public branches.
For example, think about what would happen if you rebased master
onto your feature
branch:
The rebase moves all of the commits in master
onto the tip of feature
. The problem is that this only happened in your repository. All of the other developers are still working with the original master
. Since rebasing results in brand new commits, Git will think that your master
branch’s history has diverged from everybody else’s.
The only way to synchronize the two master
branches is to merge them back together, resulting in an extra merge commit and two sets of commits that contain the same changes (the original ones, and the ones from your rebased branch). Needless to say, this is a very confusing situation.
So, before you run git rebase
, always ask yourself, “Is anyone else looking at this branch?” If the answer is yes, take your hands off the keyboard and start thinking about a non-destructive way to make your changes (e.g., the git revert
command). Otherwise, you’re safe to re-write history as much as you like.
Force-Pushing
If you try to push the rebased master
branch back to a remote repository, Git will prevent you from doing so because it conflicts with the remote master
branch. But, you can force the push to go through by passing the --force
flag, like so:
# Be very careful with this command!
git push --force
This overwrites the remote master
branch to match the rebased one from your repository and makes things very confusing for the rest of your team. So, be very careful to use this command only when you know exactly what you’re doing.
One of the only times you should be force-pushing is when you’ve performed a local cleanup after you’ve pushed a private feature branch to a remote repository (e.g., for backup purposes). This is like saying, “Oops, I didn’t really want to push that original version of the feature branch. Take the current one instead.” Again, it’s important that nobody is working off of the commits from the original version of the feature branch.
We’ll extrapolate on this next time.