问题描述
在 GitLab 上我的项目存储库中，我正确设置了受保护的分支，例如 develop 和 master 分支，以便合并请求是合并分支的唯一方法。 我测试了这个配置，我看到在受保护分支上推送代码会导致失败消息，但无论如何我都能够首先在本地合并我的主分支上的功能分支。
是否有可能完全阻止这种行为，或者可能会发生这样的情况，某人可能会错误地将其功能分支合并到 master 上，然后在将其推送到 GitLab 时被阻止，从而弄乱了提交？我知道您可以恢复错误的合并或提交，但是即使在本地完全阻止合并也会很好。 谢谢
解决方法
tl;dr： 不是真的。但这没关系，因为如果您的分支受到适当保护，您就不必担心人们在自己的存储库中做了什么。
解释： 答案不是确切的“是”或“否”的原因是因为您可以在自己的存储库中设置提交挂钩以防止某些操作（如果您愿意）。你也可以推荐其他人在他们的 repo 中做同样的事情。但这是他们的存储库，你不能强迫他们这样做。类似于你不能强迫某人在他们的桌子上以某种方式排列他们的键盘和鼠标，尽管你可以提出建议。你绝对可以锁定中央远程仓库中的分支，听起来你已经做到了，这应该就足够了。
关于您的具体问题：
...可能会发生这样的情况，某人可能会错误地在 master 上本地合并其功能分支，然后在将其推送到 GitLab 时被阻止并因此弄乱提交？
由于这个原因，不会在远程仓库上搞砸任何提交。如果您已将 master 配置为仅允许合并请求，那么任何人如何处理他们自己的 master 副本都无关紧要，因为他们无法推送它。此外，在完成 MR 之前测试合并是一个很好的做法，所以如果有人想在本地检出 master，在他们的功能分支中合并，然后在完成 MR 之前针对它运行单元和系统测试，他们应该被允许做这个。 （如果开发者在完成 MR 之前没有将自己的分支重新设置为最新的 master，则尤其如此。）
总结：这不是您需要担心的。让开发人员用自己的存储库做任何他们想做的事情。只要确保在每个合并请求的代码审查期间检查提交。这样你就会发现是否有人通过在他们的 MR 中包含他们自己的合并提交来弄乱图表。但无论如何，您应该在完成 MR 之前查看提交。
提示：我建议大多数开发人员永远不要（或很少）签出共享分支，例如 master 和 develop。通常人们对此的最初反应是认为我疯了（直到他们听到我的解释）。我这么说的原因是，如果你有那个分支的本地副本，它几乎总是过时的。当您第一次学习 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 并提取它。完全跳过这些步骤。正如我之前在本答案中提到的，如果您想签出 master 以合并到您的功能分支并在完成合并请求之前测试合并，您仍然可以这样做，但请考虑将分支命名为 {{ 1}}，可能类似于 master。或者，如果您确实检查 test/my-feature-branch 来测试您的合并，只需在完成后立即将其删除。或者更好的是，只需将您的功能分支重新定位到最新的 master 并进行测试。
如果您喜欢这个提示，这里还有另一个提示：“开发人员不应该（或很少）拉！”我将把它留给另一个讨论...
注意：请注意，在我的“从不结帐共享分支”和“从不拉”这两个经验法则中，我特意提到了“开发人员”。经理、产品负责人，以及某种程度上的 DevOps 人员，可能应该检查共享分支，也许还应该拉动，因为这对他们的用例更有意义。这里的关键是，这些人通常以只读模式使用存储库，或者在 DevOps 工程师的情况下，他们经常将共享分支相互合并。