Git’s rebase command reapplies your changes onto another branch. As opposed to merging, which pulls the differences from the other branch into yours, rebasing switches your branch’s base to the other branch’s position and walks through your commits one by one to apply them again.

Let’s look at an example. While working on a branch named login , based on the master branch, one of your team members pushed some changes to master . You need these changes to finish the login feature in your branch.

Figure 1. The new commits in the master branch ( E and F ), are needed to finish work in the login branch.

Merging the master branch back into yours would result in a merge commit, which includes the changes between both branches and exists to show where a merge occured.

Figure 2. Merging the two branches results in a merge commit.

We won’t need to know when we merged the master into the login branch in the future. Instead, we’d like to pretend that all commits on the login branch happened based on the new state of the master branch.

Figure 3. Rebasing applies the commits from the login branch on top of the master branch.

Git’s rebase command temporarily rewinds the commits on your current branch, pulls in the commits from the other branch and reapplies the rewinded commits back on top. By switching the current This bases the current branch onto the other branch.

$ git rebase master First, rewinding head to replay your work on top of it... Fast-forwarded login to master.