DEV Community

Cover image for Git Rebase Is Not The Devil
Aemie Jariwala
Aemie Jariwala

Posted on • Updated on

Git Rebase Is Not The Devil

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.

Happiness

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.

Top comments (2)

Collapse
 
waylonwalker profile image
Waylon Walker

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.

Collapse
 
kakashi profile image
Mayank Goyal

Interesting