“git rebase -i” – finally

As you have already guessed from the title of this post that I am a beginner in git. So far I was making do with basic pull, diff, add, commit commands in git. But when my mentor reviewed some 10 patches that I sent him and shared his feedback, he suggested me to get familiar with the following three as they were to be my “new best friends” when I incorporate his reviews in my code.
[sourcecode language=”shell” gutter=”false”]
git commit –amend
git add -p
git rebase -i

Barring “git add -p”, the other two will help you to rewrite your commit history. I needed to squash some of the commits, amend nearly all the commit messages and amend some of the commits themselves to make necessary changes in the code based on the feedback from my mentor. Initially, I was very apprehensive about the whole thing. But you can trust Rewriting History chapter of the Pro Git book and get started.


  1. Hello Satabdi!

    Git rebasing is great for rewriting history but once you have pushed to remote repository and rebased your local repository it will create fast-forwards problem. So far the only viable solution I have found is to delete the remote repo/branch and re-push all re-based code again. Have you found a better way around this?

    1. Nope. In fact, the Pro Git book says not to attempt such a thing – “Do not rebase commits that you have pushed to a public repository.” They explained it nicely here why one should not do it.

      1. Rebasing is not wrong 🙂 neither is rebasing local commits that have already been pushed! the fine print says it’s not the right thing to do when you have collaborators on the project. My question was what is one to do when one is the only author + a rebase on local commits that have already been pushed has been done? I haven’t found any ‘git ‘ type solution to it, hence I asked 🙂

Comments are closed.