Yep. That is the important tip, right here.

    $ pushd ..
    $ cp -a my-project my-project-before-I-did-git-surgery
    $ popd

Then relax. This is extremely important before playing with nasty Git surgical tools such as huge rebases. Borked it up?

    $ pushd ..
    $ rm -rf my-project
    $ cp -a my-project-before-I-did-git-surgery my-project
    $ popd

Undo is a great thing, and it's also important to triple check the entire state of the repository before you push, because pushing is basically committing to whatever surgery you've done. If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever.

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.

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.

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

The unwanted reality we live in.

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?

>If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever.

I disagree. I don't have much experience using git with big teams, but at least for small team where a developer usually owns a feature branch, force pushing to the branch to take into account criticism on commits can be helpful. Of course, in that case, feature branches are considered non shared.

Git own "next" branch is actually force pushed to all the time, to remove patches which didn't make the cut for example.

Personal opinion - re-reviewing a pull request when someone has erased all context from your last review of that PR via a rebase and force push is a royal PITA. Especially for changes that span more than a few files. Did they address your concerns? The only way to know is to go back through all of the changes on that feature branch, and hope you don't miss anything.

This, in contrast with just reviewing the latest commit, potentially going back to the rest of the changes with an eye towards the latest commit.

It frankly bugs the piss out of me when people rebase and ask me to review their latest changes - it feels disrespectful of my time.

I've taken to making the change as a fixup commit and leaving it in the PR for code review. Then when the changes are approved a quick `git rebase -i --auto-squash` cleans everything up before merging the branch back into `develop`.

> force pushing to the branch to take into account criticism on commits can be helpful

Hm? Criticism on commits should be additive. The commit was made, response was made, and a new commit addresses the response. Rewriting history breaks a lot of things and removes context. Another approach:

1) Add commit addressing criticism.

2) Squash when merging feature in to master, which is one of the only cases where I think rewriting history is OK.

Much cleaner master history, no rewriting history (which you should never do once another checkout sees your branch, including GitHub), and a number of other benefits. If you're routinely force pushing feature branches, something is broken in your workflow, IMO.

practicing safe version control is better than abstinence

I see what you did there...