1. 3
  1.  

  2. 5

    I don’t think the author has enough experience using git to be dispensing advice on it.

    You use reset if you want to locally drop one or more commits, moving the changes back into the index (unless you use reset --hard, which is, in my experience, rarely what you want). You use reset to change the local ‘history’, which is not a problem if you do it locally to e.g. create better commits before pushing to remote. You should never [1] use reset to drop a commit that has already been pushed to a remote repo shared with others.

    You use revert if you need to ‘publish’ a revert of one or more commits that have already been pushed to a remote repo. revert is just a convenience command to append a new commit that exactly undoes one or more previous commits. It does not change the history.

    It’s recommended to use git revert instead of git reset in enterprise environment.

    It’s recommended you try to make sure you don’t need to use git revert. Use git reset as much as you want. If you seem to need a push -f, you’re doing it wrong. Don’t ever [1] do that.

    [1] For certain values of (n)ever. If you are absolutely sure you know what you’re doing, and your colleagues know as well, you can use push -f.

    1. 5

      You probably want the (unfortunately less ergonomic) --force-with-lease, not -f/--force, to avoid accidentally overwriting any changes that have happened after your last fetch, though.

      1. 1

        I didn’t even know this existed until magit made it visible in its menus. After some research, --force-with-lease is almost always the right answer (though, YMMV)

      2. 3

        I’m comfortable resetting and force pushing to a WIP feature branch, but that’s a privilege of our workflow.

        1. 4

          Another thing you can do is use git commit --fixup and then rebase autosquash at the end.

          I wonder if revert would be better understood if it were called “invert” instead.

          1. 2

            That looks useful! Thanks!

        2. 2

          Reset without --hard is rarely what I want. :)

          I use it for example when I merged in master and made a few mistakes resolving conflicts. To try a new merge, I reset hard. Well, I usually reset, then notice I forgot --hard, and then checkout.

          To clean up my local history, I usually do rebase -i instead of reset.

          I also use reset to undo a rebase. Usually when resolving conflicts failed. That might be my general theme: Use reset to make another try resolving conflicts.

          1. 1

            rebase -i is the best way to clean up commits (squash/drop/reorder/change comment) if you know how to use it well. sometimes though a reset –hard is nice to just drop changes that you don’t want but still have commits you like from the branch.