Cover image for Git Rebase Is Not The Devil

Git Rebase Is Not The Devil

aemiej profile image Aemie Jariwala Updated on ・2 min read

Alerting the readers from before, this blog will share my personal experience and provide professional tips on git rebase, so if you want to advance yourself with the knowledge in the git, I recommend giving it a read.

First comes the experience now. I love the idea of open source and love indulging myself in contributing to the organizations on Github. Currently, I am an outreachy intern in Apache, and the past week, I worked on an issue that required learning of new concepts, and in the way, my mentor kept advising me to rebase my branch to avoid merge conflicts. But guess what, rebase scares the hell out of me only 'cause when I did try rebasing I lost all my commits for the issues and that freaked me out and I decided to just avoid it. Of course, I can't just give up so I tried it one more time carefully and voila, it happened perfectly and I understood the concept at last.


Now the tips, half of you know what rebasing might be and still be afraid to use it. I am going to define it just for those who don't know it yet. So rebasing helps you to put the commits of one branch on top of another branch to avoid any merge conflicts, that's its major use. The image will give a straightforward explanation.

Git Rebase

Beginning the journey to guide you, let's use a rebase for what it's mostly used. Creating the scenario, we have forked the example repo from Twelfth-Hour organization and we've got the feature branch for our example repo. After committing to it, it's no longer in par the master branch from the example repo on the Twelfth-Hour org, and from the image, we know what's the merge base i.e the intersecting commit for the two branches. Now giving you the step by step guide so that your feature is in par with the master branch of the main repo without losing your commits -

  1. git checkout feature
    This is the branch that we need to add the new commits of the master to.

  2. git remote add example https://github.com/Twelfth-Hour/example.git
    Here, we create a remote from the main repo that we have forked for this scenario.

  3. git fetch example
    This will fetch the entire codebase with all its branches from the example repo on Twelfth-Hour org.

  4. git rebase example/master
    Now it will do its process to get your branch in par with the main branch. However, there could be conflicts so it might abort in middle, don't freak out, just resolve those conflicts and continue the process of rebasing.

This might be the end of the blog but not the end to what rebase is capable of doing.

Posted on by:

aemiej profile

Aemie Jariwala


Intermediate in python machine learning concepts and a python developer


markdown guide

Always push to the remote and check that git status is clean before a rebase. They can go sideways and kill your work, especially if you don't know what on the other side. While anything that has been committed can be retrieved one way or another, it can be really hard for not advanced git users. Its much easier to keep git reset --hard origin/my-feature in your back pocket.