Git rebase vs merge. Learning by doing

Agenda

1. Preconditions
2. Examine merge command
3. Examine rebase command
4. Conclusion
5. Links

Preconditions

It is expected that you know what is git and how to create branches, merge branches, and check git history. In this case, I use my favorite tool, Soursetree to visualize git branches and commits history.

The purpose of this article is to highlight the difference between merge and rebase on practice.

Examine merge command

I created main and featureOne branches. Then added a couple of commits to both of them:

Then I merged featureOne into main by running this command on main branch:

git merge featureOne

This is the result:

Long story short: 2 commits from featureOne branch were added to main as a single commit.

Examine rebase command

I created main and featureTwo branches. Then also added a couple of commits to both of them:

Then I run rebase command on featureTwo branch by running this command:

git rebase main

This is the result:

Then we need to run again git merge main on featureTwo to complete merging process.

One more scenario with rebase command. I have main and featureTree branches:

Then I push both branches to github and create PR from featureTree to main. And then I chose Rebase and merge option.

This is what I have after completing PR and pulling all the latest changes:

By the way, we can still see featureThree branch because I did not delete source branch after completing PR.

Conclusion

• With rebase we have a flat structure instead of a tree structure which we have with the merge.
• We created feature branches from the main. But after rebase command, commits made to feature branches were added “to the end” of the main branch.
• Also one more important detail with rebase command is, feature branches commits’ hashes were changed after rebase. That’s why we cannot use rebase when more than one developer works on the same feature branch.

Links

1. Sourcetree app: Simplicity and power in a beautiful Git GUI
2. git merge
3. git rebase