在我看来，一个非常简单和干净的方法可以是：

回到A

git checkout -f A

将master的头指向当前状态

git symbolic-ref HEAD refs/heads/master

save

git commit

我很沮丧，这个问题无法得到回答。其他所有问题都与如何正确还原和保存历史有关。这个问题说：“我希望分支的头部指向A，即我希望B、C、D和head消失，我希望头部与A同义。”

git checkout <branch_name>
git reset --hard <commit Hash for A>
git push -f

我在阅读Jakub的帖子时学到了很多东西，但公司里的一些人（可以在没有Pull Request的情况下推送到我们的“测试”分支）推送了五次错误的提交，试图修复他在五次提交之前犯的错误。不仅如此，还接受了一到两个拉取请求，但现在情况很糟糕。所以忘掉它吧；我找到了最后一个好的提交（abc1234），并运行了基本脚本：

git checkout testing
git reset --hard abc1234
git push -f

我告诉在这个仓库工作的其他五个人，他们最好记录下过去几个小时的变化，并从最新的测试中删除/重新广播。故事结束。

还原共享存储库上的一组提交的简单方法是将git-rever与git-rev列表结合使用。后者将为您提供一个提交列表，前者将自己进行还原。

有两种方法可以做到这一点。如果要在一次提交中还原多次提交，请使用：

for i in `git rev-list <first-commit-sha>^..<last-commit-sha>`; do git revert --no-commit $i; done

这将恢复您需要的一组提交，但将所有更改保留在工作树上，之后应照常提交。

另一种选择是对每个还原的更改进行一次提交：

for i in `git rev-list <first-commit-sha>^..<last-commit-sha>`; do git revert --no-edit -s $i; done

例如，如果您有一个提交树

 o---o---o---o---o---o--->    
fff eee ddd ccc bbb aaa

要将更改从eee还原为bbb，请运行

for i in `git rev-list eee^..bbb`; do git revert --no-edit -s $i; done

如果你

合并提交和您无法恢复，并且你不介意粉碎你要还原的历史，

那么你可以

git reset --soft HEAD~(number of commits you'd like to revert)
git commit -m "The stuff you didn't like."
git log
# copy the hash of your last commit
git revert <hash of your last (squashed) commit>

然后，当您想要推送更改时，请记住使用-f标志，因为您修改了历史记录

git push <your fork> <your branch> -f

这些都不适用于我，所以我有三次提交要恢复（最后三次提交），所以我做到了：

git revert HEAD
git revert HEAD~2
git revert HEAD~4
git rebase -i HEAD~3 # pick, squash, squash

工作起来很有魅力：）

这是Jakub回答中提供的解决方案之一的扩展。

我面临的情况是，我需要回滚的提交有些复杂，其中几个提交是合并提交，我需要避免重写历史。我无法使用一系列git-restore命令，因为我最终在添加的反转更改之间遇到了冲突。我最终使用了以下步骤。

首先，检查目标提交的内容，同时将HEAD留在分支的顶端：

git checkout -f <target-commit> -- .

（--确保<targetcommit>被解释为提交而不是文件；.指的是当前目录。）

然后，确定在回滚的提交中添加了哪些文件，因此需要删除这些文件：

git diff --name-status --cached <target-commit>

添加的文件应在行的开头显示为“A”，并且不应有其他差异。现在，如果需要删除任何文件，请暂存这些文件以进行删除：

git rm <filespec>[ <filespec> ...]

最后，提交回复：

git commit -m 'revert to <target-commit>'

如果需要，请确保返回到所需状态：

git diff <target-commit> <current-commit>

应该没有区别。