The Problem
There are a number of work-flows you can use. The main point is not to break history in a published branch unless you've communicated with everyone who might consume the branch and are willing to do surgery on everyone's clones. It's best not to do that if you can avoid it.
Solutions for Published Branches
Your outlined steps have merit. If you need the dev branch to be stable right away, do it that way. You have a number of tools for Debugging with Git that will help you find the right branch point, and then you can revert all the commits between your last stable commit and HEAD.
Either revert commits one at a time, in reverse order, or use the <first_bad_commit>..<last_bad_commit> range. Hashes are the simplest way to specify the commit range, but there are other notations. For example, if you've pushed 5 bad commits, you could revert them with:
# Revert a series using ancestor notation.
git revert --no-edit dev~5..dev
# Revert a series using commit hashes.
git revert --no-edit <last_good_commit_hash>..<last_bad_commit_hash>
This will apply reversed patches to your working directory in sequence, working backwards towards your known-good commit. With the --no-edit flag, the changes to your working directory will be automatically committed after each reversed patch is applied.
See man 1 git-revert for more options, and man 7 gitrevisions for different ways to specify the commits to be reverted.
Alternatively, you can branch off your HEAD, fix things the way they need to be, and re-merge. Your build will be broken in the meantime, but this may make sense in some situations.
The Danger Zone
Of course, if you're absolutely sure that no one has pulled from the repository since your bad pushes, and if the remote is a bare repository, then you can do a non-fast-forward commit.
git reset --hard <last_good_commit>
git push --force
This will leave the reflog intact on your system and the upstream host, but your bad commits will disappear from the directly-accessible history and won't propagate on pulls. Your old changes will hang around until the repositories are pruned, but only Git ninjas will be able to see or recover the commits you made by mistake.
Answer from Todd A. Jacobs on Stack OverflowVideos
The Problem
There are a number of work-flows you can use. The main point is not to break history in a published branch unless you've communicated with everyone who might consume the branch and are willing to do surgery on everyone's clones. It's best not to do that if you can avoid it.
Solutions for Published Branches
Your outlined steps have merit. If you need the dev branch to be stable right away, do it that way. You have a number of tools for Debugging with Git that will help you find the right branch point, and then you can revert all the commits between your last stable commit and HEAD.
Either revert commits one at a time, in reverse order, or use the <first_bad_commit>..<last_bad_commit> range. Hashes are the simplest way to specify the commit range, but there are other notations. For example, if you've pushed 5 bad commits, you could revert them with:
# Revert a series using ancestor notation.
git revert --no-edit dev~5..dev
# Revert a series using commit hashes.
git revert --no-edit <last_good_commit_hash>..<last_bad_commit_hash>
This will apply reversed patches to your working directory in sequence, working backwards towards your known-good commit. With the --no-edit flag, the changes to your working directory will be automatically committed after each reversed patch is applied.
See man 1 git-revert for more options, and man 7 gitrevisions for different ways to specify the commits to be reverted.
Alternatively, you can branch off your HEAD, fix things the way they need to be, and re-merge. Your build will be broken in the meantime, but this may make sense in some situations.
The Danger Zone
Of course, if you're absolutely sure that no one has pulled from the repository since your bad pushes, and if the remote is a bare repository, then you can do a non-fast-forward commit.
git reset --hard <last_good_commit>
git push --force
This will leave the reflog intact on your system and the upstream host, but your bad commits will disappear from the directly-accessible history and won't propagate on pulls. Your old changes will hang around until the repositories are pruned, but only Git ninjas will be able to see or recover the commits you made by mistake.
If you've already pushed things to a remote server (and you have other developers working off the same remote branch) the important thing to bear in mind is that you don't want to rewrite history
Don't use git reset --hard
You need to revert changes, otherwise any checkout that has the removed commits in its history will add them back to the remote repository the next time they push; and any other checkout will pull them in on the next pull thereafter.
If you have not pushed changes to a remote, you can use
git reset --hard <hash>
If you have pushed changes, but are sure nobody has pulled them you can use
git reset --hard
git push -f
If you have pushed changes, and someone has pulled them into their checkout you can still do it but the other team-member/checkout would need to collaborate:
(you) git reset --hard <hash>
(you) git push -f
(them) git fetch
(them) git reset --hard origin/branch
But generally speaking that's turning into a mess. So, reverting:
The commits to remove are the latest
This is possibly the most common case, you've done something - you've pushed them out and then realized they shouldn't exist.
First you need to identify the commit to which you want to go back to, you can do that with:
git log
just look for the commit before your changes, and note the commit hash. you can limit the log to the most resent commits using the -n flag: git log -n 5
Then reset your branch to the state you want your other developers to see:
git revert <hash of first broken commit>..HEAD
The final step is to create your own local branch reapplying your reverted changes:
git branch my-new-branch
git checkout my-new-branch
git revert <hash of each revert commit> .
Continue working in my-new-branch until you're done, then merge it in to your main development branch.
The commits to remove are intermingled with other commits
If the commits you want to revert are not all together, it's probably easiest to revert them individually. Again using git log find the commits you want to remove and then:
git revert <hash>
git revert <another hash>
..
Then, again, create your branch for continuing your work:
git branch my-new-branch
git checkout my-new-branch
git revert <hash of each revert commit> .
Then again, hack away and merge in when you're done.
You should end up with a commit history which looks like this on my-new-branch
2012-05-28 10:11 AD7six o [my-new-branch] Revert "Revert "another mistake""
2012-05-28 10:11 AD7six o Revert "Revert "committing a mistake""
2012-05-28 10:09 AD7six o [master] Revert "committing a mistake"
2012-05-28 10:09 AD7six o Revert "another mistake"
2012-05-28 10:08 AD7six o another mistake
2012-05-28 10:08 AD7six o committing a mistake
2012-05-28 10:05 Bob I XYZ nearly works
Better way®
Especially that now that you're aware of the dangers of several developers working in the same branch, consider using feature branches always for your work. All that means is working in a branch until something is finished, and only then merge it to your main branch. Also consider using tools such as git-flow to automate branch creation in a consistent way.
Git commit only saves it to the stage, which is locally on your computer. Use Push to update it to a remote server (Like github).
Use git revert <ID> to revert back to a previous commit. each commit has an identifying code.
See here for more details on revert
The above answer is not quite correct - git revert <ID> does not set your repository to that commit -- git revert <ID> creates a new commit that undoes the changes introduced by commit <ID>. It's more or less a way to 'undo' a commit and save that undo in your history as a new commit.
If you want to set your branch to the state of a particular commit (as implied by the OP), you can use git reset <commit>, or git reset --hard <commit> The first option only updates the INDEX, leaving files in your working directory unchanged as if you had made the edits but not yet committed them. With the --hard option, it replaces the contents of your working directory with what was on <commit>.
A note of warning that git reset will alter history -- if I made several commits and then reset to the first commit, the subsequent commits will no longer be in the commit history. This can cause some serious headaches if any of those lost commits have been pushed to a public repository. Make sure you only use it to get rid of commits that haven't been pushed to another repository!
Expanding what I wrote in a comment
The general rule is that you should not rewrite (change) history that you have published, because somebody might have based their work on it. If you rewrite (change) history, you would make problems with merging their changes and with updating for them.
So the solution is to create a new commit which reverts changes that you want to get rid of. You can do this using git revert command.
You have the following situation:
A <-- B <-- C <-- D <-- master <-- HEAD
(arrows here refers to the direction of the pointer: the "parent" reference in the case of commits, the top commit in the case of branch head (branch ref), and the name of branch in the case of HEAD reference).
What you need to create is the following:
A <-- B <-- C <-- D <-- [(BCD)-1] <-- master <-- HEAD
where [(BCD)^-1] means the commit that reverts changes in commits B, C, D. Mathematics tells us that (BCD)-1 = D-1 C-1 B-1, so you can get the required situation using the following commands:
$ git revert --no-commit D
$ git revert --no-commit C
$ git revert --no-commit B
$ git commit -m "the commit message for all of them"
Works for everything except merge commits.
Alternate solution would be to checkout contents of commit A, and commit this state. Also works with merge commits. Added files will not be deleted, however. If you have any local changes git stash them first:
$ git checkout -f A -- . # checkout that revision over the top of local files
$ git commit -a
Then you would have the following situation:
A <-- B <-- C <-- D <-- A' <-- master <-- HEAD
The commit A' has the same contents as commit A, but is a different commit (commit message, parents, commit date).
Alternate solution by Jeff Ferland, modified by Charles Bailey builds upon the same idea, but uses git reset. Here it is slightly modified, this way WORKS FOR EVERYTHING:
$ git reset --hard A
$ git reset --soft D # (or ORIG_HEAD or @{1} [previous location of HEAD]), all of which are D
$ git commit
Clean way which I found useful
git revert --no-commit HEAD~3..
git commit -m "your message regarding reverting the multiple commits"
This command reverts last 3 commits with only one commit.
Also doesn't rewrite history, so doesn't require a force push.
The .. helps create a range. Meaning HEAD~3.. is the same as HEAD~3..HEAD