16 ms·

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_branch_backup. This same pattern is useful for other dangerous commands, like rebases or filter-branch. When you're done, just delete blah_branch_backup.

altonen 5y ago
You can also use git-reflog to restore the branch back to the state it was before the merge. So instead of creating a temporary branch, you can inspect the reflog, find the entry before the merge commit and do git reset --hard HEAD@{X}.
- balefrost 5y ago
  That's true! I personally prefer having a symbolic name for my backup, but the reflog is also very useful for "oops" moments.
- zelphirkalt 5y ago
  Afaik git branches are merely pointers to commits, so it makes sense, that one can go back finding the correct commit id.
- 5e92cb50239222b 5y ago
  reflog saved me a few times, just remember that commits not referenced by a pointer (like HEAD or branch) can be GCed and disappear at any point. They are likely to be there right after a merge/rebase is finished, but may not be there anymore an hour later.
icedchai 5y ago
I create backup branches all the time. Though I rarely have to use them, they have saved my butt a couple times!
- DarylZero 5y ago
  You don't need to create backup branches ahead of time with git, because the reflog saves every branch before every operation. You can create your backup branch from the reflog _after_ you discover you need it!
  - icedchai 5y ago
    I did use the reflog once, when I forgot to make a backup branch. It's not one of the commands I use regularly though.
erwincoumans 5y ago
Thanks, I should have been mote precise in my post. I meant, I zip repo root folder before a complex git operation (certainly not before every single merge). One example: changing the commit email, somewhere on the middle of many commits. On github, I sometimes need to use the work email instead of personal email (due to https://github.com/apps/google-cla https://github.com/apps/google-cla) Changing the email of an existing commit messed up my repo beyond repair. This is just one example from memory, it happens infrequently luckily. Thanks for the git tips :)
- balefrost 5y ago
  That's exactly the sort of operation for which backup branches can help. When you rewrite history, Git makes new commit objects that have the same topology as the original branch topology. It also updates the branch pointer to point at that new HEAD commit. History rewriting commands essentially just fork the repo at some point in the past and create an alternate commit history. The original commits still exist, at least for a little while. Git will eventually garbage-collect them. By creating a backup branch, you're "pinning" those old commits. With the backup branch in place, after you run a command that rewrites history, you will be able to look at the commit graph and see the point where the backup branch and the rewritten branch diverged. I used to do what you do until I learned more about how Git works internally. And Git's really not super complicated at its core. I think much of Git's complexity comes from the minutiae of the CLI options. (For example, when you want to delete something, do you use `-d` or an explicit `remove`? It depends on the command you're running.) But hey, if you have a workflow that works, then you do you.
wadkar 5y ago
> git branch blah_branch_backup Don’t forget to commit your changes if you’re going to `reset --hard` later!

altonen 5y ago

You can also use git-reflog to restore the branch back to the state it was before the merge. So instead of creating a temporary branch, you can inspect the reflog, find the entry before the merge commit and do git reset --hard HEAD@{X}.

balefrost 5y ago
That's true! I personally prefer having a symbolic name for my backup, but the reflog is also very useful for "oops" moments.
zelphirkalt 5y ago
Afaik git branches are merely pointers to commits, so it makes sense, that one can go back finding the correct commit id.
5e92cb50239222b 5y ago
reflog saved me a few times, just remember that commits not referenced by a pointer (like HEAD or branch) can be GCed and disappear at any point. They are likely to be there right after a merge/rebase is finished, but may not be there anymore an hour later.

icedchai 5y ago

I create backup branches all the time. Though I rarely have to use them, they have saved my butt a couple times!

DarylZero 5y ago
You don't need to create backup branches ahead of time with git, because the reflog saves every branch before every operation. You can create your backup branch from the reflog _after_ you discover you need it!
- icedchai 5y ago
  I did use the reflog once, when I forgot to make a backup branch. It's not one of the commands I use regularly though.

erwincoumans 5y ago

Thanks, I should have been mote precise in my post. I meant, I zip repo root folder before a complex git operation (certainly not before every single merge). One example: changing the commit email, somewhere on the middle of many commits. On github, I sometimes need to use the work email instead of personal email (due to https://github.com/apps/google-cla https://github.com/apps/google-cla) Changing the email of an existing commit messed up my repo beyond repair. This is just one example from memory, it happens infrequently luckily. Thanks for the git tips :)

balefrost 5y ago
That's exactly the sort of operation for which backup branches can help. When you rewrite history, Git makes new commit objects that have the same topology as the original branch topology. It also updates the branch pointer to point at that new HEAD commit. History rewriting commands essentially just fork the repo at some point in the past and create an alternate commit history. The original commits still exist, at least for a little while. Git will eventually garbage-collect them. By creating a backup branch, you're "pinning" those old commits. With the backup branch in place, after you run a command that rewrites history, you will be able to look at the commit graph and see the point where the backup branch and the rewritten branch diverged. I used to do what you do until I learned more about how Git works internally. And Git's really not super complicated at its core. I think much of Git's complexity comes from the minutiae of the CLI options. (For example, when you want to delete something, do you use `-d` or an explicit `remove`? It depends on the command you're running.) But hey, if you have a workflow that works, then you do you.

wadkar 5y ago

> git branch blah_branch_backup Don’t forget to commit your changes if you’re going to `reset --hard` later!