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