• 12 hours
  • Easy

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 8/21/19

Modify your branches with rebase

Log in or subscribe for free to enjoy all this course has to offer!

Git rebase vs git merge

You learned how to use git merge to combine two branches.  With git merge, you are able to combine the two unique histories of both branches without compromising any of that history as the commits were formed chronologically. Now let's talk about another form of combining branches: git rebase.  Although both commands combine branches,  they work very differently and serve different functions.

Here's a quick review of git merge. A merging a master and feature branch would look like this:

Add commit history of both branches using Git Merge
Add commit history of both branches using git merge 

As you may recall, the base is where the feature branch was first created off of the main repository.  The master branch shows an additional three commits that happened with the feature branch built as a result. The HEAD of the branch is where the branch is ready to merge with the master branch.  A new merge commit is created to combine the commits of the master and the feature.

The command to complete this merge while working on the master branch:

git merge feature

Git rebase also combines two branches and save the commit histories; however, there is a big difference in the way it is executed.  Let's look again at the master and the feature branch.  Imagine you are on the master branch, and instead of using git merge, you want to use git rebase as your command.  First, you will switch your working directory to the feature branch.  Next, run  git rebase to add the feature branch to your master:

git checkout feature
git rebase master

Now let's get a visual of how it looks:

Adding feature branch to master with Git Rebase.
Adding feature branch to master with git rebase.

You will see that now the feature branch has been tacked right on top of the master branch.  Also, the commits that were in the feature branch are all new commits after the tip of the master branch.

The commit history for the branch has been rewritten with fresh new commits.  Now, when exactly would you want to do this? 

✅ Dos with git rebase

For example, let's say that the second half of the master branch was being created separately on a local repo with a feature branch.  With git rebase, they can be combined to create one master branch without a lot of messy commits in different orders.

This type of organization helps with creating a visualization of relevant commits to those outside of the development team. Remember, messy code with multiple merges, branches, and extra commits can start to look pretty chaotic! 😜

❌ Don'ts with git rebase

There is a rule of thumb with using git rebase: never use it in a public repository.  If anyone else is working on that repository, hands off! 👐🏽

Since you are essentially rewriting project history, working on public repositories can cause a lot of havoc.  Multiple team members working on the main branch may have added a few commits to the master branch tip.  If you upload your rebased master branch to the main repository, you can rewrite your teammates commits with your own new commit history.

Needless to say, that will not make people happy.  Don't make that mistake!

Use interactive rebase

Git rebase has a lot of cool extra features that make this command fun.  Let's take a look at a few. Interactive git rebase is a subset of git rebase.  It provides more control over the commits themselves and what can be done with them. It is also a great tool to use to clean up your branch and make it presentable! 

First, the interactive git rebase is written with an i switch, which stands for interactive:

git rebase -i

If you go back to our earlier rebase, you see that we added three feature branch commits.  It is automated with git rebase.  What if you wanted to go further into it and combine commit 1 & 2?  Maybe commit 2 was just a test, and you want to combine it to commit 1 to make the code cleaner.  This is what you do:

git rebase -i master

Now we will be provided with each commit on a text editor opened up on Git Bash.  This will provide you with a few interactive git rebase options that can be used to manipulate the commit files.  In our case, we'll work with three commits, as seen below. These will create the new commits when rebased onto the master branch. 

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

Let's run through a few options.

Squash/fixup a commit

Now let's say that the second commit was an accident, so it doesn't make sense to keep in the history.  You can combine it with commit 1 using the following fixup command:

pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

Change the order of commits

We've changed our mind and go back to the commits in the last example with this command:  git rebase -i master 

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

Let's say you want to move commit 3 to line 1, and commit 1 to line 3. Git Bash won't argue with you! Put the commits in the order that you wish on the text editor and save! 

pick 5c67e61 Message for commit #3
pick 9480b3d Message for commit #2
pick 33d5b7a Message for commit #1

Now the git rebase interactive command will create the new commits in the new order. 

Change a commit message

Now let's change those commit messages above to make more sense.  Right now, it is labeling our first commit #3, and our third commit as #1. This can also be easily edited in the text editor:

pick 5c67e61 Message for new commit #1 
pick 9480b3d Message for commit #2
pick 33d5b7a Message for new commit #3 

There!  I added the keyword  new in front of commit to make the message more descriptive.  It is good to make your messages descriptive so others understand the purpose of your commits.

Rebase starting with specific commits on the branch

Now let's say you want to start your git rebase at the second commit in the feature branch instead of with the entire feature branch.

Remember the HEAD file?  This command will make the HEAD point to the specified commit to start the rebase.  It's like steering your car in the direction you want to turn.  Here is how it looks: 

git rebase -i HEAD~2

Remember that you must be in the branch with the commits.  So if you want to add the feature branch starting with commit 2 to the master branch, you have the feature branch as your working directory.  That can be done with the  git checkout feature command.

Let's recap!

This was a big one!

  • Git merge and git rebase combine the commit histories of two branches, but have different ways of doing it. 

  • Never use git rebase on a public repository or a branch that others are working on.

  • Git rebase adds one branch on top of the other with new commits.

  • Interactive git rebase can be used to manipulate commit history, change commit messages, combine (squash) commits together, and specify which commits you would like to include in the rebase.

Going further

For additional commands, check out this documentation on Interactive Git Rebase Commands.

Example of certificate of achievement
Example of certificate of achievement