在错误合并后，最后一天的所有代码变换都被覆盖。因为没有注意到，所以在错误的合并之上进行了新的提交。我如何返回某个提交，然后添加错误合并后所做的提交？
git reset or git revert ?
您可以重写历史记录：
git checkout master // switch to master
git checkout -b fix_it // create a fix_it branch, and switch to it
git rebase -i <hash_right_before_bad_commit> // cherry-pick all the good commits - leave out the bad one
如果fix_it分支看起来不错，则该重置主人的时间，以便指向fix_it：
git checkout master
git branch old_master // create an old_master branch in case you want to rollback
git reset fix_it // now master has the new fixed history (without the bad commit)
// double-check your branches and make sure everything looks ok (and the bad commit is gone from your history)
git log --graph --all --oneline --decorate-short
// if everything looks good, push the changes to your remote repository
git push origin master --force // you'll need to force it since you've re-written history
// clean up the tmp branches
git branch -D fix_it, old_master
// inform your team members to force get master (or just to be safe, just re-clone repository).
显示当前状态
您可以通过命令看到所有分支参考：
git branch -a
您可以看到这样的提交历史记录命令：
git log --graph --decorate --oneline --all
原始状态
通常，您将分支参考本地和来源。本地引用是通过您刚刚完成的合并操作来修改的。
您有合并之前
eb686c4 (HEAD -> master, origin/master) some work 1
22abb23 (HEAD -> fix, origin/fix) some work 2
新状态
您有合并后
aa183c1 (HEAD -> master) some work 1
bb426c2 some work 2
cc686c4 (origin/master) some work 1
ddabb23 (HEAD -> fix, origin/fix) some work 2
回滚到Origin
因此，您可以通过命令
将reset分支滚动到上一个。# here you are at master (HEAD -> master)
git reset --hard origin/master
# or if you are not at master branch
git branch -f master origin/master
回滚至初步标记状态
是临时分支的愉快(我将分支称为m(：
# create branch m to ref to same commit as current branch (master)
git branch m master
# do merge or rebase
git merge ...
现在，如果您有一些问题，则可以像创建分支m时一样回顾大师：
# here you are at master (HEAD -> master)
git reset --hard m
# or if you are not at master branch
git branch -f master m
在您的情况下，这足以：
- 再次合并正确的分支与您的丢失更改
- 恢复合并提交(并且只有合并提交(，然后合并本应首先合并的当前分支
另一方面，您缺少某些提交，因为过去有些恢复的提交，您可能必须还原这些恢复。
git重置只有在您想强制某种状态并将其推向遥控器上，这可能会自行造成麻烦。仔细在那里对待，但根据存储库的状态，这可能是有道理的。