A few months ago I had to clean up some branches from an older project that was being added to with new features where I needed to rollback one of the branches to a specified commit.
In my mind I really had two choices overall: git reset and git revert. Here are the main descriptions for each:
NAME
git-revert - Revert some existing commits
SYNOPSIS
git revert [--[no-]edit] [-n] [-m <parent-number>] [-s] [-S[<keyid>]] <commit>… git revert (--continue | --skip | --abort | --quit)
DESCRIPTION
Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).
Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-restore[1], specifically the --source option. Take care with these alternatives as both will discard uncommitted changes in your working directory.
NAME
git-reset - Reset current HEAD to the specified state
SYNOPSIS
git reset [-q] [<tree-ish>] [--] <pathspec>… git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>] git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>…] git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
DESCRIPTION
In the first three forms, copy entries from <tree-ish> to the index. In the last form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <tree-ish>/<commit> defaults to HEAD in all forms.
History: To Be Seen Or Not To Be See. That Is Thy Question
While there's a lot to look at, and there are other considerations to be thinking about, for me it mainly came down to whether or not I wanted a clean commit history or to maintain the older history of commits as well.
Since I didn't want to keep the history, because there was no need in maintaining any commit history after the commit that I wanted to be the last shown (before the new features were added). I stayed with what I had done in the past--good old git-reset:
git reset --hard <commit>
git push --force
It's clean. It gets me what I want. It doesn't have the overhead of managing conflicts or multiple reverts, which can make it even more unwieldy because it adds another commit for each rollback.
And absolutely--if not coordinated with multiple users it can lead to problems because it essentially re-writes history--and there are use cases where you may need or want to keep that history alive.
But if there are bad commits that need to go?
git reset for the win!
