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?
The command 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.
5 keys to successful organizational design
How do you create an organization that is nimble, flexible and takes a fresh view of team structure? These are the keys to creating and maintaining a successful business that will last the test of time.Read more
Why your best tech talent quits
Your best developers and IT pros receive recruiting offers in their InMail and inboxes daily. Because the competition for the top tech talent is so fierce, how do you keep your best employees in house?Read more
Technology in 2025: Prepare your workforce
The key to surviving this new industrial revolution is leading it. That requires two key elements of agile businesses: awareness of disruptive technology and a plan to develop talent that can make the most of it.Read more