我经常犯这个错误，我想知道是否有更好的解决方案，以及我目前的解决方案是否有风险。
这是工作流程
我的错误是，在第5步附近，我应该做类似第12步的操作，以创建一个新分支，以使这项工作与其他任务分开，以便我可以轻松地回到该分支或根据需要重新构建不同的补丁程序。订购或其他。相反，我将新代码推送到master分支上，大约在第10步时，我意识到master不再是公司已批准的最新和最佳版本的代码，而是我自己的努力。因此，在使用交互式rebase将自己的提交压缩为一个提交之后，我正在执行另一个交互式rebase，以使master指向应该指向的位置，即，其他人的作品已经完成了审核过程。
编辑以澄清问题：当我“掌握”时，这不会将我的更改发布给其他所有人。有一些提交挂钩魔术可以创建Gerrit代码审查任务，并且只有在获得批准的情况下，我的提交才会合并到远程存储库中。道歉，误导大家。我在这里只关心我的本地仓库。
我的问题是双重的。就风险而言，这种做法有多严重？如何加以改进？我不是在寻求避免初始错误的帮助。我想我只需要更加小心我要推送到哪个分支。问题是如何最好地将master指向上一次提交而又不打扰/冒风险/丢掉任何东西。
答案 0 :(得分：1)
如果您只推送了一次提交，则可以执行以下操作：
git checkout master
git reset --hard HEAD~
git push -f
这会将master恢复到先前的提交。如果进行了更多提交，则可以将HEAD~替换为任何其他提交（SHA1哈希，分支名称，标记名称等）。
我的错误是，我应该在第5步附近进行第12步之类的操作
我建议在第4步，完全进行任何编码之前，创建一个新分支。这里不应该有歧义。典型的最佳实践是创建一个新的功能分支，以使工作分开进行，并且只有在工作完成后才将其合并到master中。在master上进行半完成的工作将使您的软件不稳定且难以发布。
答案 1 :(得分：1)
我正在将新代码推送到master分支上，大约在第10步时，我意识到master不再指向该公司已批准的最新和最佳版本的代码，而是我自己的努力。
问题的根源在于，您甚至甚至可以直接推送到共享存储库上的master分支。您应该从共享存储库中拉出，但是要推到自己的前叉并发出拉出请求。您的拉取请求应先由其他人进行审核，然后再由您以外的其他人合并。是的，您可以避免通过尽早创建自己的分支来避免掌握母带，但是真正的问题是您（以及大概其他人）根本可以直接推动母带。
就风险而言，这种做法有多严重？如何改进？
这很糟糕，主要是因为（再次）您根本不应被允许这样做。您怎么知道您的“解决方案”是正确的？在别人意识到自己搞砸之前，如果其他人将他们的更改（可能已审核或尚未审核）合并到您的顶部，该怎么办？
此修复程序适用于disallow pushes directly to master。
更新：鉴于您的评论是您不是在谈论共享仓库中的master分支，而是您自己的fork中的master分支，因此您的解决方案似乎还不错。您自己的仓库中的master分支实际上并没有多大意义，至少对于我所见过的大多数工作流程而言，意义不大。通常，您在自己的分支中工作，然后将该分支推到您的派生分支，并向共享存储库发出拉请求，这时应该进行代码审查，或者在合并代码之前进行其他检查。因此，修复自己的master分支的过程很好-将工作保存到新分支，然后重置或重新设置master分支以使其与远程master保持同步。