Git 是否可以完全阻止受保护分支上的本地合并？

在GitLab上的项目存储库中，我正确地设置了受保护的分支，如develop和master分支，这样合并请求是合并分支的唯一方法。 我测试了这个配置，发现在受保护的分支上推送代码会导致失败消息，但在任何情况下，我都能够首先在本地合并主节点上的功能分支

是否有可能完全阻止这种行为，或者有人可能会错误地在主机上本地合并其功能分支，然后在将其推送到GitLab时被阻止，从而破坏提交？我知道您可以还原错误的合并或提交，但即使在本地完全阻止合并也很好。

---

谢谢

tl；博士：不太可能。但这没关系，因为如果你的分支机构得到了适当的保护，你就不必担心人们在自己的回购协议中会做什么

解释：答案不是确切的“是”或“否”的原因是您可以在自己的回购协议中设置提交挂钩，以防止某些操作。你也可以建议其他人在回购协议中也这样做。但这是他们的回购协议，你不能强迫他们这么做。类似于你不能强迫别人把键盘和鼠标按某种方式放在桌子上，尽管你可以提出建议。您完全可以锁定中央远程回购中的分支，听起来您已经这样做了，这就足够了

关于你的具体关切：

…可能会发生这样的情况：有人错误地在主机上本地合并其功能分支，然后在将其推送到GitLab时被阻止，从而导致提交混乱

由于此原因，远程回购上不会出现任何提交错误。如果您已将

master

配置为仅允许合并请求，那么任何人对自己的master副本做什么都无关紧要，因为他们无法推送它。此外，在完成MRs之前测试合并是一种很好的做法，因此，如果有人想在本地签出

master

，在其功能分支中进行合并，然后在完成MR之前对其运行单元和系统测试，那么应该允许他们这样做。（如果开发人员在完成MR之前没有将自己的分支重新设置到最新的

master

，这一点尤其正确。）

总而言之：这不是你需要担心的事情。让开发商通过自己的回购协议为所欲为。只需确保在检查每个合并请求的代码时检查提交。这样，如果有人在MR中包含了他们自己的合并提交，你就会发现他正在搞乱图表，但无论如何，在完成MR之前，你应该先查看提交情况

提示：我建议大多数开发人员不要（或很少）签出共享分支，例如

master

和

develope

。通常，人们对此的最初反应是认为我疯了（直到他们听到我的解释）。我这样说的原因是，如果你有一个分支的本地副本，它几乎总是过时的。当您第一次学习Git时，您可以学习

Git checkout master

，然后

Git pull

使其更新。然后使用

git checkout-b my new branch

（或

git switch-c my new branch

）从那里创建分支，然后关闭并运行。但最终您将忘记拉取最新的master，并开始从较旧版本的master创建分支。那么你会怎么做呢？只要想使用

master

分支，只需使用

origin/master

！假设您定期

git fetch

（您应该这样做），

origin/master

将始终是最新的，因此您甚至不需要浪费时间签出

master

并将其取出。完全跳过这些步骤。正如我前面在这个回答中提到的，如果你想签出“代码>主代码/代码>合并到你的特征分支并在完成合并请求之前测试合并，你仍然可以这样做，但是考虑把分支命名为除代码>主< /代码>以外的东西，也许类似于<代码> Test/My特征分支< /代码>。或者，如果您确实签出

master

来测试合并，只需在完成合并后立即将其删除即可。或者更好的方法是，只需将您的功能分支重新设置到最新的

origin/master

上，并进行测试即可

如果你喜欢这个技巧，这里还有另外一个：“开发人员永远不应该（或者很少）拉！”我将把它留给另一个讨论

---

注意：请注意，在我的“从不签出共享分支”和“从不拉”经验法则中，我特意提到了“开发人员”。经理、产品负责人，以及某种程度上的DevOps人员，可能应该检查共享分支，也许还应该退出，因为这对他们的用例更有意义。这里的关键是，这些人通常以只读模式使用回购协议，或者在DevOps工程师的情况下，他们经常将共享分支合并到彼此中；博士：不太可能。但这没关系，因为如果你的分支机构得到了适当的保护，你就不必担心人们在自己的回购协议中会做什么

解释：答案不是确切的“是”或“否”的原因是您可以在自己的回购协议中设置提交挂钩，以防止某些操作。你也可以建议其他人在回购协议中也这样做。但这是他们的回购协议，你不能强迫他们这么做。类似于你不能强迫别人把键盘和鼠标按某种方式放在桌子上，尽管你可以提出建议。您完全可以锁定中央远程回购中的分支，听起来您已经这样做了，这就足够了

关于你的具体关切：

…可能会有人误以为