Merging is not the only utility that can integrate changes from one branch onto another. In this article, we look into rebasing and learn how we can use it as an alternative to merging.

The basics of rebasing

In the previous part of this series, we’ve learned that merging can result in an additional merge commit. This might not be the desired outcome if we aim for the readability of our git logs.

Rebase aims to rewrite git history so that it is simple and straightforward. To visualize it, let’s start with a clean repository:

echo “# rebase-repo” >> README.md

git init

git add README.md

git commit -m “Initial commit”

git remote add origin git@github.com:mwanago/rebase-repo.git

git push -u origin master

_If you want to know the importance of the  _-u flag, check out the first part of this series.

Below, we simulate a very common situation. Imagine creating a new branch from master and starting to work on it. Before you finish up and want to merge it back to master, it contains some new changes.

git branch feature-two

echo “console.log(‘Feature one’)” > feature-one.js

git add ./feature-one.js

git commit -m “Added the first feature”

git push origin master

Above, we create the  feature-two branch and add some changes to the master. Now, our  feature-two is 1 commit behind the master branch. Let’s continue by adding some stuff to the feature-two.

git checkout feature-two

echo “console.log(‘Feature two’)” >> feature-two.js

git add ./feature-two.js

git commit -m “Added the second feature”

git push origin feature-two

#git #rebasing

Getting geeky with Git #5. Improving merge workflow with rebase
1.25 GEEK