Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Rebasing Basics | More Advanced Workflows
course content

Contenido del Curso

GitHub Fundamentals

Rebasing BasicsRebasing 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.

Rebasing is the process of moving or combining a sequence of commits to a new base commit. This is done by replaying the changes from one branch onto another branch, resulting in a linear commit history.

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:

Three-way merge

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):

When you rebase a branch, you're essentially rewriting its history. This means that the old commits are replaced with new ones, which have different identifiers (hash sums) because they're based on different snapshots of the code. As shown in the animation above, the identifier of the commit on the feature/payment branch changed after rebasing.

¿Todo estuvo claro?

Sección 3. Capítulo 4
course content

Contenido del Curso

GitHub Fundamentals

Rebasing BasicsRebasing 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.

Rebasing is the process of moving or combining a sequence of commits to a new base commit. This is done by replaying the changes from one branch onto another branch, resulting in a linear commit history.

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:

Three-way merge

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):

When you rebase a branch, you're essentially rewriting its history. This means that the old commits are replaced with new ones, which have different identifiers (hash sums) because they're based on different snapshots of the code. As shown in the animation above, the identifier of the commit on the feature/payment branch changed after rebasing.

¿Todo estuvo claro?

Sección 3. Capítulo 4
some-alt