比如说，您已经推送了一些提交并将它们拉入生产环境，例如在您的服务器的 webroot 中。然后出了点问题。显然，您通常想要做的是将 webroot 中的文件暂时恢复到以前的状态，然后返回您的本地开发位置，修复损坏的地方，测试它，在损坏的提交之上提交并推送这些新的修复提交到主分支。然后再次转到生产 webroot 并将所有内容拉到最新提交，这样所有内容都已修复并正常工作。然后每个人都可以拉出 master 分支，而不必担心提交失败或重置 git head 或其他令人沮丧的事情。
那么：这是一种合法且安全的方法吗
在生产 webroot 中，在 master 分支上
>git log --pretty=format:"%h %ad | %s [%an]" --date=short
0fu83bd Wed Mar 6 17:47:42 2013 | Merge branch 'sample' [developer1]
fd442f8 Wed Mar 6 17:47:10 2013 | Some updates [developer1]
ad84471 Wed Mar 6 17:25:12 2013 | Added something [developer2]
找到你想暂时恢复文件状态的提交，比如ad84471
>git checkout ad84471
>git branch
* (no branch)
master
去任何你开发、修复、提交、[合并]、推送主分支的地方。当您这样做时，生产文件处于 ad84471 状态，没有人修改它们。然后回到生产 webroot：
>git checkout master
>git pull
>git branch
* master
>git log --pretty=format:"%h %ad | %s [%an]" --date=short
7guffbd Wed Mar 6 17:47:42 2013 | Fixed 0fu83bd bugs [developer1] <---new commit
0fu83bd Wed Mar 6 17:47:42 2013 | Merge branch 'sample' [developer1]
fd442f8 Wed Mar 6 17:47:10 2013 | Some updates [developer1]
ad84471 Wed Mar 6 17:25:12 2013 | Added something [developer2]
现在我们在 master 分支中，一切正常。每个人都只需拉出最新的更改就可以了。
我已经使用 md5deep 检查了文件，以确保一切都返回（在修复之前）到我们恢复的状态：
>md5deep -rel webroot > hashes_master_before_checkouting_ad84471
>git checkout ad84471
>git checkout master
>md5deep -rel webroot > hashes_master_after_checkouting_master_again
这些哈希之间的差异仅显示
webroot/.git/logs/HEAD
webroot/.git/index
已经改变。
所以这似乎是一个快速修复问题的好方法，或者我错了？
免责声明：我知道在很多项目中这与预期的工作流程背道而驰，而且这种做法不是很好，而且之前应该有自动化测试，但是对于开发人员很少的小项目，这通常是不可能或不切实际的，因此与使用 git reset 或 revert 相比，此方法可以节省大量时间并简化事情。