Git is an essential tool for software, as it allows teams to collaborate and review code.

One of the more powerful features of Git is being able to take the codebase and make your own code changes without interfering with someone else’s work.

The general strategy is simple: you’ll cut a branch from (typically) main, make changes to code and create the commits, then merge it back into the main branch.

Git also comes with a tool named “rebase”, which does something similar. There’s debate between rebasing and merging (HackerNews) as to which one is better.

Let’s talk about what the methods are and when you’d use them since they essentially do the same thing, right?

Git Merge vs Git Rebasing: Same job, different approach

The Atlassian tutorial states it well: “Both of these commands are designed to integrate changes from one branch into another branch - they just do it in very different ways.”

In short:

  • git merge creates a new commit when branches diverge,

  • git rebase takes your branch and rewrites the history you’re merging into.

Let’s take this as an example - suppose your branching schema looks like this. You have 3 commits you want to merge into a branch:

Running git merge will create a new single commit (if branches diverge from one another):

git rebase takes the commits and copies them to the branch you want to merge them into:

What’s important here is that no merge commit is created - commits are instead copied into the branch and are assigned new SHA values.

The Rule for Rebasing with Git

There is one key rule for using rebase: do not use it on public branches. That is, only use rebase on branches that are local (unpushed or a branch only you touch).

If you’ve pushed, shared, or someone has already reviewed the pull request, then you’re going to want to use a merge instead.

» As someone who’s had to undo someone else’s work when they rebased instead of a merge, please (and I beg you) don’t use rebasing in a shared branch 😅

Happy coding!

📧 Join the Python Snacks Newsletter! 🐍

Want even more Python-related content that’s useful? Here’s 3 reasons why you should subscribe the Python Snacks newsletter:

  1. Get Ahead in Python with bite-sized Python tips and tricks delivered straight to your inbox, like the one above.

  2. Exclusive Subscriber Perks: Receive a curated selection of up to 6 high-impact Python resources, tips, and exclusive insights with each email.

  3. Get Smarter with Python in under 5 minutes. Your next Python breakthrough could just an email away.

You can unsubscribe at any time.

Interested in starting a newsletter or a blog?

Do you have a wealth of knowledge and insights to share with the world? Starting your own newsletter or blog is an excellent way to establish yourself as an authority in your field, connect with a like-minded community, and open up new opportunities.

If TikTok, Twitter, Facebook, or other social media platforms were to get banned, you’d lose all your followers. This is why you should start a newsletter: you own your audience.

This article may contain affiliate links. Affiliate links come at no cost to you and support the costs of this blog. Should you purchase a product/service from an affiliate link, it will come at no additional cost to you.

Keep Reading