Comment by jsmthrowaway
7 years ago
No, it isn't, if you're playing with surgical tools that disrupt Git history, which was my point. It's a lot easier to revert to before you started than attempt to abort out of a huge rebase/squash/ugly merge conflict hell/rewrite of history. I'm not saying back up before every commit. I'm saying when `git status` is three pages long, you have 14,000 conflicts, and you're on a detached HEAD God knows where, it's your choice to spend the next hour typing the right Git commands to get back where you wanted to be, or just back out and try again. I know which one I'd prefer.
I'm sorry if I sound rude. I don't mean to be. I'm just saying that backing up your git workspace to recover from rebases or merges gone wrong is not necessary. Those are not "surgical tools", they don't modify existing commits. (edit: yes you can "edit commits", but they only create new commits, the old commits are not deleted in the process and they can still be found easily)
When you commit in git, that saves the whole project as a "snapshot". If you find yourself lost in some rebase hell or whatever, just reset HEAD back to a previous commit. It's simple as that! (git reset --hard <commit>)
Why I decided to reply to your comment was because this is a very crucial part of learning git. When you realize that you can always go back to what was before, you can start experimenting more freely.
> git reset --hard <commit>
Unless part of your surgery involves files that do not yet live in the history, or you're working on a detached HEAD in a mid-merge state, or... git reset --hard is a very dangerous operation unless you're 100% sure of the entire state of the repository. That is a very rapid way to lose work if you're not perfectly diligent.
And sure, you shouldn't have to back up .git or your workspace, but sometimes, it's a hell of a lot easier to ripcord out and say "screw it" if you have a complete workspace from before you decided to launch down the rebase hole or whatever.
You could run git reset without the --hard parameter to keep unstaged changes in the working directory
It's only easier to copy the directory if you haven't done the due diligence of learning git properly. It's a tool to avoid doing the ripcord approach -- ever.
Why not just create a new branch instead of copying your project over to a new dir?