误推master后如何恢复

Question

我经常犯这个错误，我想知道是否有更好的解决方案，以及我当前的解决方案是否有风险。

这是工作流程

1. git 结账大师
2. git拉
3. git 子模块更新 --init --recursive
4. （编辑、调试、测试）
5. git 提交 -a
6. git push origin HEAD:refs/for/master
7. （更多编辑、测试等）
8. git 提交 -a
9. 吉特克
10. （咒骂）
11. git rebase -i HEAD~2 # 选择并将我的两个提交压缩在一起
12. git checkout -b 任务ID
13. git 结账大师
14. git rebase -i HEAD~2 # 选择前一个用户的提交，删除我自己的

我的错误是，在第 5 步的某个地方，我应该执行类似于第 12 步的操作来创建一个新分支，以使这项工作与其他任务分开，以便我可以轻松地返回到它或以所需的顺序重新设置不同的补丁或其他任何内容。相反，我将新代码推送到主分支上，大约第 10 步我意识到，这master不再指向公司已批准的最新、最好的代码版本，而是我自己的努力。因此，在将我自己的提交压缩为一个交互式的提交之后rebase，我正在执行另一项交互式操作rebase以返回master它应该在的位置——即，已经通过审核过程的其他人的工作。

编辑澄清：当我“推送到master”时，这不会将我的更改发布给其他人。有一些提交钩子魔法可以创建 Gerrit 代码审查任务，并且只有获得批准后，我的提交才会合并到远程存储库中。抱歉误导了大家。我在这里关心的只是我的本地仓库。

我的问题是双重的。就风险而言，这种做法有多糟糕？如何改进？我并不是寻求帮助来避免最初的错误。我想我只需要更加小心我要推向哪个分支。问题是如何最好地指向master先前的提交而不干扰/冒险/丢失任何东西。

Answer 1

如果您只推送了一次提交，您可以执行以下操作：

git checkout master
git reset --hard HEAD~
git push -f

这会将 master 恢复到之前的提交。如果您进行了更多提交，则可以替换HEAD~为任何其他提交（SHA1 哈希、分支名称、标签名称等）。

我的错误是在第 5 步附近我应该做类似第 12 步的事情

我建议在第 4 步，在进行任何编码之前，创建一个新分支。这里不应有任何歧义。典型的最佳实践是创建一个新的功能分支，以便继续单独工作，并且仅在工作完成后将其合并到主分支中。在 master 上提交半完成的工作会使你的软件不稳定并且难以发布。