Rebasing Basics

Making a Commit on the main Branch

Let's start by making a commit directly in the remote main branch by editing the README.md file in the remote repository. This will cause the main branch and the feature/payment branch to have a diverging commit history.

Here is the line added to the file:

Here is the respective commit message:

Understanding Rebasing

As we mentioned in the previous chapter, once the feature branch is reviewed and tested, it can and should be merged back into the main branch. Up until now, we have only used the git merge command for this purpose. However, another approach is to use the git rebase command.

When we create a branch, Git tracks the latest commit on both branches. If only one branch has new changes, Git can fast-forward and apply the changes. However, if both branches have new changes, Git creates a new merge commit, resulting in a three-way merge.

Here is what a three-way merge would look like in our case, where C4 was the latest commit on the feature/payment branch before merging:

However, three-way merges can complicate debugging because of the split, non-linear history. By rebasing, we change the base of our commits and replay them on top of the new base, allowing Git to perform a fast-forward merge and maintain a linear history.

Here is an animation to illustrate how rebasing can be performed in our case (the commit identifiers do not correspond to the real ones here):