Introduction

As a junior developer you have probably been in this position. You are a fresh new hire and know the basics of git and Github. You know simple operations like how to pull changes from main, create branches and create pull requests. Life is good for a while, you are creating new features and creating PR’s until one day your manager asks you to “rebase off of main” so you can finish implementing your new feature.

Immediately sweat drips down your forehead and your hands get cold. You have never done a rebase before and don’t where to start. Suddenly new git commands are being used like git force — push, git rebase — continue and others that you have never even seen before. Add to that being merge conflicts which are their own problem in of itself. To understand the concept of rebasing vs merging I want you to understand two movies, the 2019 superhero phenomenon Avengers: Endgame and the 1985 classic Back to the Future.

Rebasing with Marty McFly

If you have seen the movie, you know the premise, Marty goes back in time and creates changes in the past, i.e makes his dad courageous with standing up to Biff, and returns to the future to find that some things in his life have changed. The time travel mechanic for this movie is a very good point of comparison for rebasing. What Marty did in the movie was he essentially rewrote history by making changes and brought them to the present, this is what rebasing does in the context of git, except unlike Marty, with git you choose which changes you want to keep and which you want to discard in the case of a merge conflict (merge conflicts will be covered more in depth in a future article). When you rebase your branch off of the main/ master branch what you are essentially doing is moving your branch forward in time up to the latest commit in the main branch and branching off of that commit, alongside receiving the changes from the main branch to your feature branch.

Merging with Earth’s Mightiest Heroes

Merging handles bringing your branch up to date differently than rebasing does, just like Avengers: Endgame handles the concept of time travel differently than Back to the Future (they even reference it in the movie). The plot goes as follows, the avengers go back in time to retrieve the infinity stones after the events of the previous film, and when they return to the present they bring themselves back with the stones, however the main difference is that they DID NOT rewrite history like in Back to the Future (their original timeline remained the same as explained by the Hulk). Merging does the same thing in the context of git. When you merge the changes from main into your branch, you bring all of the commit history alongside the changes others have made since into your branch. The moment when you branched off of main in the git timeline remains the same in the eyes of git.

Rebasing vs. Merging: Which is better?

Like many things in life it depends on your specific use case. Rebasing is a destructive operation so developers have to be careful when using it, especially when working in teams or on open source projects. However, other times you may not care about the commit history that main has had since you have created your branch and only about the changes made. Reverting rebases can also be extremely difficult and close to impossible (according to sources online, I’ve never done it), while reverting a merge is relatively simple. A helpful stack overflow link is attached below where many developers give their two cents on rebasing vs merging.

https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge

With that being said I hope this article helps with some of the ambiguities one may have with rebasing vs merging. Thanks for reading!

Sources:

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge