我有一个非常简单的设置。在要素分支中开发要素，然后将壁球合并到develop，并且准备好足够的要素后，我们要对master进行合并提交。所有这些都应该通过请求请求来实现。其背后的想法是隐藏单个提交的所有细节，这些细节最终将在功能本身之后的develop / master中结束。
当前，似乎不可能在不同的分支上强制实施不同的合并类型，如下所述：Set pull request merge options per branch
更重要的是-这实际上是一个好策略吗？从事此工作的大多数人（包括我）都不是Git的新手，所以我想使它变得尽可能简单和故障安全。经过数小时的搜寻后，我找不到任何相关资讯。
所以，我想我的问题是：什么是简单的方法或最好的方法？别人有同样的问题吗？如果是这样-他们如何解决？还是这个问题仅源于对GitHub的理解不够充分？
您也可以指出我的任何建议，文档或最佳做法吗？
GitHub可让您调整每个存储库（而非每个分支）的合并策略。您只能为整个存储库启用或禁用某些策略。
但是，您可以全局禁用重新基准，然后需要线性历史记录，这意味着唯一的选择是挤压合并。但是，这并不能防止您想要合并提交时意外地将壁球合并到错误的分支中。
我的总体策略是永远不要合并。在整理历史记录的同时，它还防止Git检测到壁球合并的合并基础（因为未创建实际的合并提交），因此它可能导致比平常更多的冲突。而且，由于许多新手Git用户选择一次又一次地重复使用同一分支（出于我未知的原因），这导致了奇怪的重复历史和怪异的冲突。后者的答案当然是为每个功能使用一个新的分支，但这很难向用户解释。
如果您非常关注干净的历史记录，请在代码审查中进行；否则，只保留不整洁的历史可能很好。前者是Git要求的，后者是GitHub内部使用的策略；两者都有效。
[您也可以只要求用户在使用常规合并提交之前先压缩自己的历史记录，这是我在其他地方看到的策略。这使您的壁球变得整洁和易于使用，而没有壁球合并的所有缺点。就像执行git reset --soft develop然后编写提交消息一样简单。