Use git rebase to ensure you have the latest code from master, which will help avoid future merge conflicts.
Let’s walk through an example of how git rebase affects commit history:
Imagine you create a feature branch from master, and work on it over the course of a week. On Monday, you complete a
git pull on master and create a new branch feature_3,
git checkout -b feature_3 .
On Tuesday and Wednesday, you check in three commits (c1, c2, c3), and your git history looks something like this:
After your last commit on feature_3 you notice a pull request merged into master, that make changes to the classes you’ve been working on in feature_3.
To avoid future merge conflicts you decide to rebase your feature branch. After the rebase, your git history will look something like this:
You now have the most recent changes from master in your feature_3 branch. Notice how the original commit date from earlier in the week is still intact and you have the most recent commit from master.
What is the command to rebase?
git rebase will give you:
First, rewinding head to replay your work on top of it...
Fast-forwarded feature_3 to refs/remotes/origin/feature_3.
if there are no merge conflicts.
The most recent commits from master are now on your feature branch and you can continue coding.
What if there are merge conflicts during rebase?
The command for our example would be
git rebase -i HEAD~3, where
-i is “interactive” and
HEAD~# is the the number of commits from your branch history for your rebase. Entering
git rebase -i HEAD~3 will allow you to interact with the commits to cleanup any git history and/or address any merge conflicts.
pick 44d32e5 commit 1
pick f60bba8 commit 2
pick sdk898b commit 3
Here are some additional interactive features to use with
git rebase -i :
pick– the commit is included.
reword– allows you to change the commit message.
edit– you’ll be given the chance to amend the commit during the rebase. This is especially helpful when you run into merge conflicts.
squash– allows you to group multiple commits into a new commit. We have a guide for what happens when you squash in this blog post.
fixup– the commit is simply merged/sqaushed into the commit above it, and only one commit message is used to describe the change.
GitHub has a great article with additional detail on what happens in different scenarios during
git rebase --interactive .
Use git rebase to ensure you have a clean git history and can maintain a quality timeline to track when and what was committed.
For more information about how squashing affects your git history, check out An Illustrated Guide to Squashing in Git.