Re: git fetch,git merge and git rebase

From: Jeff King <peff@peff.net>
Date: Feb 10, 2011, 23:03 UTC
Message-ID: <20110210230337.GB21335@sigill.intra.peff.net>
In-Reply-To: <4D5464E7.2010407@gmail.com>

On Thu, Feb 10, 2011 at 04:21:27PM -0600, Neal Kreitzinger wrote:

Show 8 quoted lines

> another definition of git-rebase:
> 
> git-rebase:  the MOST DANGEROUS command in git.  you can easily
> DESTROY your repo if you don't know what you're doing!  Until you get
> the hang of it, always make a copy of the before-image of the branch
> your rebasing (mybranch) by doing a "git checkout mybranch" and then
> "git branch copy-of-mybranch".  Then if you destroy mybranch you can
> recover it from copy-of-mybranch.

I won't claim that rebase isn't easy to shoot yourself in the foot with, but I think this advice is a little over-the-top. Rather than backing up branches, you would do better to learn about reflogs, as the reflog of mybranch will contain the original version. As will the reflog of HEAD, though if you have screwed up too badly, the reflog of mybranch will probably be a lot simpler to read.

You can see it with "git reflog show mybranch"; when you see the commit that you want to restore to, you can:

  git branch -f mybranch mybranch@{whatever}

to restore it there. That provides more-or-less the same safety as a backup branch (reflogs do expire, but something like three months later), plus it helps you in all the cases where you forgot to make a backup before screwing things up. :)

-Peff