This question seams to deal with rewinding the commits from the master branch. Can I use a similar git reset --soft command on a branch in the repo or should I be trying to make sense of git revert?
Ultimately I'd like to rewind two branches by two or three commits (not just the last) in the bare repo.
I'm still not clear where the repo is. You say it's bare but you must have a non-bare somewhere too.
If you just want to rewind local branches then you want to use git reset. So if you have a local branch beta then you can rewind it like this:
$ git checkout beta
$ git reset --hard HEAD~2
This will drop 3 commits: HEAD, HEAD~1 and HEAD~2. These will get garbage collected in about 90 days so you can get them back if needed.
If you have a remote repo named origin (that is bare) and you'd like to rewind the branch over there, then you can do this via a forced push. Let's say you pushed 3 commits on beta before they're ready. You can keep them in your local project but remove them from the remote bare repo like this:
$ git push -f origin beta~3:beta
This can be harsh to others using that repository but it sounds like you're okay with that.
If you only have a bare repo then you can forcibly reset the branch like so:
$ git branch -f beta beta~3
Note: this also works for the first case of rewinding local branches. Again, this is unfriendly to anyone using this repo.
It depends on what you want to do. git revert will generate new commits in your repository to reverse the changes made by your selected commits. This is nice from a change tracking perspective -- you can see what was reverted and why, and you can always rethink your decision later.
You can run git reset (without --soft, which is only meaningful in a working copy) to simply reset the repository back to a previous state. This discards the commits after your selected commit, so you'll lose that history forever. If there are people with remote working copies of the repository, they will suddenly find their working copies out of sync (and they may inadvertently re-introduce the changes when they run git push).
If it's your own repository and you're not sharing it with anyone else, git reset is fine. Otherwise, git revert is probably the better choice, both because it leaves a trace in the repository history and interacts well with remote working copies.
