[xaphod]

This is so wrong. :) With git you exactly do not have to backup your local workspace, because it already is backed up in git.

If it is committed, it is safe. You can go back to it. If you messed up your branch, just reset it to something that was good. No need to do manual backups.

[bpchaps]

Sure it's wrong if you know what you're doing. But that's not who the blog post is for.

Sometimes it's okay to take liberties with good practices - especially when learning, or when the world is on fire and a push needs to happen now.

[richforrester]

> or when the world is on fire and a push needs to happen now.

The unwanted reality we live in.

[jsmthrowaway]

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.

[xaphod]

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.

[jsmthrowaway]

> 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.

[u801e]

You could run git reset without the --hard parameter to keep unstaged changes in the working directory

[minor3rd]

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.

[iamjaredwalters]

Why not just create a new branch instead of copying your project over to a new dir?