假设我们在git下有一个网络应用程序。我们正在进行本地化，因此我们有一个长期运行的主题分支'loc'。我们也在做一个与l10n一起使用的新皮肤，所以我们有一个长期运行的主题分支'皮肤'。
我们希望每个分支都有单独的分支，但问题是两个功能是纠缠在一起的。当你做l10n工作时，翻译的消息和其他东西的长度会影响皮肤。同样，如果您对皮肤进行更改，则可能需要对消息或其他l10n功能进行一些修改。从另一个角度来看：当我们在'loc'进行更改并且我们想要测试时，我们希望最近有'skin'的工作副本，反之亦然。
那么如何最好地处理这种情况 - 我们只使用一个分支，我们是否将两个分支都送入中间分支'skin-plus-loc'，我们在那里进行测试然后合并到dev中，我们是否继续合并这两个分支的提示可能会相互影响吗？还是我们继续合并开发？处理此类案件的最佳做法是什么。
答案 0 :(得分：1)
答案 1 :(得分：1)
分支机构有许多有用的用途，但在本次讨论中，我将把它们分为两类：
提出一个合适的分支策略意味着查看正在进行的工作并辨别这些变化应该存在的位置。在我看来，听起来你的本地化工作是独立的（更改不依赖于彼此）和稳定（更改不会破坏构建），使其成为错误修复分支的主要候选者。
另一方面，听起来皮肤工作更像是一个特征;正在进行的工作密切相关，可能不稳定。因此，我会考虑使用功能分支。
让我假装我在上述评估中是正确的，并为您勾勒出一个策略：
假设满足以下条件，此解决方案是最佳的：
可以重新进行重新定位。如果只有一个开发人员在分支上工作，默认情况下允许这样做。但是，如果有几个开发人员，除非你能保证变相总是微不足道，否则使用变基是危险的。
错误修复分支尽可能经常“干净”。该站点应该从bugfix分支中的任何一点构建。如果开发太不稳定而不允许这样做，那么这不是一个好的解决方案。
错误修复分支不依赖于功能分支。如果两个工作之间存在很多耦合，那么重新定位将是痛苦的，应该避免这种解决方案。
如果您能满足所有这些要求，那么这可能是一个非常干净和有利的方案。非语义合并（即，为了更新到今天的工作而完成的那些）被消除，并且提交历史非常清楚。由于bugfix分支是稳定的，因此可以将其用作其他功能的根目录。
最后，当将主题合并到bugfix分支时，它将毫不费力地作为快进发生。我喜欢在这种情况下禁用快速转发，因此合并和分支保留在提交历史记录中，以提供已开发功能的证据。
如果您有多个开发人员在分支机构工作，并且无法确保rebase不需要手动合并，那么重新定位是危险的。
要避免此问题，您应该考虑使用较小范围的分支;而不是拥有本地化分支，有一个“本地化个人设置”主题分支和“本地化管道”错误修复分支。这背后的动机是满足上述解决方案的条件：小型分支机构可以由单个开发人员处理，小型分支机构通常更容易变更，小型功能可以比大型分支机构更快地完成和共享。
引入更多分支可能会违反直觉，这将简化您的开发。但是，它类似于将一个双用途函数重构为两个单用途函数。
此问题的解决方案与前一个问题相同：使用更多分支。如果存在依赖关系，那么你应该问问自己为什么会这样：我们应该提交功能分支而不是bugfix分支吗？错误修正分支试图包含太多吗？
分支应该有明确的目的和寿命。如果分支开始具有多个目的，则使用版本控制的优点会减少。最好有两个或三个精细调整的分支而不是一个模糊分支。
重复合并可能是默认情况下会发生的事情。每个分支都是分开的，并且合并用于更新另一个分支，其中包含在另一个分支中发生的进度。没有必要隔离工作，因为它会定期共享。
与重复合并相关的问题往往使这种替代方案难以为继。历史将受到没有语义价值的合并的污染。重复合并还会迫使一个分支中的开发人员密切关注另一个分支中的更改，从而避免将其用作其他功能的根目录。
如果重复合并似乎是唯一的选择，您可能需要考虑只使用一个分支并完成它。目前的发展可能是如此交织在一起，现在有一个分支更有意义。当事情稳定下来时，如果这看起来很谨慎，就有可能将它们再次分开。