Git 特征相互关联时的分支设置

假设我们在git下有一个web应用程序。我们正在进行本地化，因此我们有一个长期运行的主题分支“loc”。我们也正在做一个新的皮肤，将与l10n，所以我们有一个长期运行的主题分支'皮肤'

我们希望每个都有单独的分支，但问题是这两个特性相互纠缠。在执行l10n工作时，翻译消息的长度和其他因素会影响皮肤。同样，如果对外观进行更改，则可能需要对消息或其他l10n功能进行一些修改。从另一个角度来看：当我们对“loc”进行更改并希望进行测试时，我们希望获得“skin”的最新工作副本，反之亦然

那么，如何最好地处理这种情况呢？我们是否只使用一个分支，我们是否将两个分支馈送到一个中间分支“skin plus loc”，在那里我们进行测试，然后合并到dev中，我们是否继续将两个分支的尖端合并到彼此中？还是我们一直在将dev合并到它们中？处理此类案件的最佳做法是什么。

请参阅“”

分支用于隔离开发工作，允许单独的任务彼此独立地演化

---

如果您的两个任务（皮肤和本地化）紧密相连，那么它们应该在同一个分支中。与

dev

分支分开。

分支有许多有用的用途，但在本次讨论中，我将把它们分为两类：

• bug修复分支聚合了一系列松散相关的bug修复和改进
• 要素分支或主题分支将隔离要素上的工作，直到该要素准备合并

提出一个像样的分支策略意味着查看正在完成的工作，并识别这些变化应该存在于何处。在我看来，您的本地化工作听起来是独立的（更改不相互依赖）和稳定的（更改不会破坏构建），这使得它成为bug修复分支的主要候选

另一方面，听起来蒙皮工作更像一个功能；正在进行的工作密切相关，可能不稳定。因此，我会考虑使用一个特征分支。

让我假设我在上述评估中是正确的，并为您概述一个策略：

解决方案：重新设置错误修复分支的基础 假设满足以下条件，此解决方案是最佳的：

• 可以并允许重定基址。如果一个分支上只有一个开发人员，则默认情况下允许重定基址。然而，如果有几个开发人员，使用重定基址可能是危险的，除非您可以保证重定基址总是微不足道的

• 错误修复分支尽可能经常保持“干净”。站点应该从bugfix分支中的任何一点构建。如果开发太不稳定，不允许这样做，那么这不是一个好的解决方案

• 错误修复分支不依赖于功能分支。如果这两项工作之间存在大量耦合，那么重新定基将是痛苦的，应该避免这种解决方案

如果您能够满足所有这些需求，那么这将是一个非常干净和有利的场景。消除了非语义合并（即，仅为更新到今天的工作而进行的合并），并且提交历史非常清晰。因为bug修复分支是稳定的，所以它可以用作其他特性的根

最后，当将主题合并到bugfix分支中时，它将以快进的方式轻松出现。在这种情况下，我想禁用快速转发，因此合并和分支仍保留在提交历史记录中，以提供已开发功能的证据

问题：不可能/不允许重定基址 如果您有多个开发人员在分支上工作，并且无法确保重新调整不需要手动合并，那么重新调整是危险的

为了避免这个问题，你应该考虑使用较小范围的分支；与其有本地化分支，不如有“本地化个人设置”主题分支和“本地化管道”错误修复分支。这背后的动机是满足上述解决方案的条件：小型分支可以由单个开发人员处理，小型分支通常更容易重新设置基础，小型功能可以比大型功能更快地完成和共享

引入更多分支会简化您的开发，这似乎与直觉相反。然而，这类似于将一个双用途函数重构为两个单用途函数

问题：错误修复分支不干净，或者它取决于功能分支 此问题的解决方案与前一个相同：使用更多分支。如果存在依赖关系，那么您应该问问自己为什么会这样：我们应该提交到功能分支而不是错误修复分支吗？bug修复分支是否试图包含太多内容

分支机构应具有明确的用途和寿命。如果一个分支开始有多种用途，那么使用版本控制的优势就会减弱。最好有两个或三个微调的分支，而不是一个模糊的分支

旁白：为什么重复合并不好 默认情况下可能会发生反复合并。每个分支保持独立，合并用于使用另一个分支中发生的进度更新一个分支。没有必要隔离工作，因为它将定期共享

与重复合并相关的问题往往使这一替代方案难以维持。历史将被没有语义价值的合并所污染。重复合并还将迫使一个分支中的开发人员密切注意另一个分支中的更改，从而避免将其用作其他功能的根

如果重复合并似乎是唯一的选择，你可能想考虑只使用一个分支并用它来完成。目前的发展可能是如此错综复杂