When would one need git-rebase?

Everytime I read the gitrebase documentation, I get lost. It feels to me like a kind of a low-level operation (read: dark magic).

Quoting the docs:

  • GitLab SSL handshake error when performing a Git Pull/Clone Using TortoiseGit and Ansible
  • removing broken names in Git (dropbox conflicted copy)
  • Git branch not detached from an other branch
  • Why GIT reports “fatal: This operation must be run in a work tree” when exporting from bare repo?
  • Merge local Java project to existing git repo
  • How do I copy a block of code from one git branch to another, while retaining commit history?
  • Assume the following history exists
    and the current branch is “topic”:

           A---B---C topic
     D---E---F---G master 

    From this point, the result of either of the
    following commands:

    git rebase master 
    git rebase master topic 

    would be:

                   A'--B'--C' topic
     D---E---F---G master

    The question is: Why would anyone want to do such a thing?

    For one thing, it seems to “re-write” history, as if the branch started at a different point; essentially the commit history will be “a bunch of lies”.

    Another point, it doesn’t feel safe. I tried it once, got a ton of conflicts, and all hell broke loose. I don’t remember exactly how I resolved that hell, but if I recall correctly, it was on a temporary test branch or something like that.

    The other question: Am I missing some really cool/time-saving set of features by not knowing how to utilize git-rebase?


    Related question: Undoing a git rebase

  • Read from STDIN on a Git pre-commit Hook (with PHP)
  • How to clone a bitbucket repository?
  • Git: Stage into Commit, what is the right workflow?
  • How to push to github from cloud9?
  • git - push is failing with the error src refspec feature/add-foo-bar-to-foo does not match any
  • Using multiple branches of git notes
  • 4 Solutions collect form web for “When would one need git-rebase?”

    First, there are no unsafe operations in git. rebase has an abort operation, and all operations make it to the reflog, so you can undo anything. It is, in fact, quite the opposite.

    It allows you to feel free to commit any time you want without having to have a “good” build while you’re on the path to making one. The revisions you publish can be clean by squashing all of the steps you took along the way into a single commit.

    I use rebase all the time (quite often via pull which I generally have configured to rebase after the fetch phase). Don’t think of it as rewriting history — think of it as providing a tool for you to clean up your rough draft before you publish it.

    In a year from now, will it be important to anyone in your project to know that you really started this feature against revision E and not revision G?

    Unnecessary recursive merges obscure the more important parts of history.

    You need to use it for instance when you want to submit a patch to code that someone else’s modified. For example if you branched from revision 1.56 of a software and in the meantime the maintainer moved to revision 1.57, he/she would probably accept patches only on revision 1.57.

    You would rebase your branch to revision 1.57, correct all conflicts, verify and resubmit the patch.

    As soon as you merge “topic” back into “master” you will have those conflicts anyway. Thus, it is better to rebase “topic” onto “master” from time to time (it’s easier if if you do small steps than if you do one big step – at least imo). If you rebase before you merge, all the “risky” stuff happens in the branch and the merge is easy afterwards.

    See git rebase: keeping your branches current blog post by James Bowes

    Git Baby is a git and github fan, let's start git clone.