有没有办法通过具有不同和强制合并策略的拉取请求来合并 GitHub 上的分支？

Question

我有一个非常简单的设置。在功能分支中开发了一个功能，然后将 squash 合并到 develop 中，并且在准备好足够的功能后，我们想要对 master 进行合并提交。所有这些都应该通过拉取请求发生。这背后的想法是隐藏各个提交的所有细节，这些细节最终会出现在功能本身的develop/master 中。

目前，似乎不可能在不同的分支上实际执行不同的合并类型，如下所述：Set pull request merge options per branch

更重要的是——这真的是一个好策略吗？大多数使用它的人都是 Git 新手（包括我），所以我想让它尽可能简单和故障安全。在过去几个小时的谷歌搜索后，我找不到任何关于此的信息。

所以，我想我的问题是：有什么简单的方法或者最好的方法来设置它？其他人有同样的问题吗？如果是这样 - 他们如何解决？还是这个问题仅仅是因为对 GitHub 的理解不够好？

您也可以向我指出任何建议、文档或最佳实践吗？

Answer 1

GitHub 允许您调整每个存储库而不是每个分支的合并策略。您只能为整个存储库启用或禁用某些策略。

但是，您可以全局禁用变基，然后需要线性历史记录，这意味着唯一的选择是压缩合并。但是，这并不能防止您在需要合并提交时意外地将合并到错误的分支中。

我的总体策略是从不压缩合并。虽然它整理了历史记录，但它也阻止了 Git 检测 squash 合并的合并基础（因为没有创建实际的合并提交），因此它可能导致比平常更多的冲突。此外，由于许多新手 Git 用户选择一次又一次地重用同一个分支（出于我不知道的原因），这会导致奇怪的重复历史和奇怪的冲突。后者的答案当然是为每个特性使用一个新的分支，但这很难向用户解释。

如果您非常关心干净的历史记录，那么在代码审查中要求这样做；否则，生活在不整洁的历史中可能很好。前者是 Git 需要的，后者是 GitHub 内部使用的策略；两者都有效。

您也可以只要求用户在使用常规合并提交之前压缩他们自己的历史记录，这是我在其他地方看到的策略。这使您可以整洁且易于使用 squash，而没有 squash 合并的所有缺点。这就像git reset --soft develop 然后编写提交消息一样简单。