如何从复杂的分支现实过渡到单分支模型？

#1 楼

因为您提到了瀑布，所以我了解到您提到的众多分支都是功能分支，而不是维护分支。

在此设置中，我还假设这些分支是根据瀑布计划创建的试图最小化冲突。这意味着开发的目标是生产几种不同的产品。使用单分支开发模型时，也必须在单个产品上工作。如果在一个分支的开发模型中同时开发多个产品，则可以有效地将这些产品的版本“胶合”在一起，以便我们在版本库a中可以拥有健康产品X和有问题的产品Y，而在版本b中可以拥有产品X具有回归功能，产品Y具有错误修复功能，但我们没有X和Y都正常的版本。这种情况将迫使我们考虑X和Y是在不同的存储库中开发的，这暗示它们应该是。

因此，第一步应该执行存储库拆分：


整理存储库，以便轻松将其拆分为几个小型存储库。例如，重新排列当前存储库，以使每个顶级目录对应于您将来要创建的存储库。这样做，您可以继续使用每个人都熟悉的分支-意大利面条规则。
完成第1步后，通过要求任何单个分支只能触摸一个顶级目录中的文件来完善分支-意大利面条规则。
当每个分支都符合步骤2时，执行拆分。通过删除路径的第一级，开发人员可以轻松地将其待处理的更改转换为单个存储库的补丁。

既然已经执行了拆分，则可以开始处理分支学科本身。


介绍编程技术，以帮助开发短暂的分支。分支寿命短是所有单分支方法的关键方面。他们的目标之一是减少花费在合并和调试长期存在的分支上的时间。一种流行的技术是引入“功能标记”，其中“工厂”使用配置标记来生成对象的历史版本或该对象的新的，最初部分开发的版本。
现在，您有成千上万的存储库，每个存储库中只有几个分支，您可以打开“我们在全球范围内采用基于主干的开发规范”按钮，而不会看到原始的分支-意大利面条山在主干上倒塌。

存储库的实际划分可能是可选的，但是您必须采用策略来明确划定每个提交补丁的允许范围（以限制合并主分支中的更改时发生冲突的风险）。减少冲突所带来的开销是单分支模型方法论的目标之一，因此我认为这与您的情况有关。

#2 楼

从某物迁移到另一物时，只需定义两件事：


您的目标是什么
如何到达那里（迁移计划）

不幸的是，第一部分经常被忽略或过于模糊。您不能简单地说您所拥有的一团糟，而是想要对其进行组织。那是什么意思？每个人都有不同的解释（又称：每个开发人员都认为他或她的做事方式是最好的）。

机会是，您所服务的所有分支机构或已达到目标的分支机构。如果没有明确的目标流程，人们将继续以最适合自己的方式做对自己有用的事情（正确的做法）。例如，您的目标应该像Vincent Driessen定义的那样清晰地定义。 “成功的Git分支模型”。如果您查看此模型，它将非常精确：它指出应该在哪里稳定代码，应该在哪里开发不稳定的功能。它还说明了如何以及何时分支，更新和合并。您知道每个分支的用途，以及如何处理它们。我们使用Vincent提出的内容的变体，并且在我们的Wiki中定义了我们的变体。

重要的一点是让所有团队了解并就目标达成共识。可能需要提醒人们，您并不是在寻找他们个人最喜欢的分支模型，而是所有团队成员都可以同意并易于使用的模型。

一旦您有了目标，就可以就能详细说明您的迁移计划。该计划可以根据您的需要长短。我已经看到这种分支模型是在一夜之间强加的；在其他地方，它完成了2或3个冲刺。只要我们有所改善，对我来说就没什么关系。

您可以从“最大”或更重要的分支开始。例如：“从现在开始，master必须始终处于要在prod中部署的状态，而dev分支必须始终进行编译”（或任何规则）。然后，强制执行版本（发行版）分支。之后，强制执行功能分支。之后，如果可行，将代码冻结强加在版本分支上。

DevOps完全是关于通信，开放性和效率的。必须牢记这些概念，并在整个过程中进行沟通。

我建议邀请开发团队之外的一些人作为观察员参加过程会议。运维人员或中层管理人员可能会对您的模型说两三句话。应该优先考虑开发人员的需求，但是如果分支模型无法与事物的管理方式保持一致，那么最好现在就知道，而不是一两个月。

真正的大型团队，请尝试让所有人参与进来。在非常庞大的团队中，无论如何，您最终将召开两到三场会议。因此，邀请会议室中的团队负责人，但要进行网络广播，并让所有人都知道。如果有人有建议或疑虑，他们将可以向其团队负责人表达意见，如果该建议有效，将在第二次或第三次会议上解决。

#3 楼

实际上，将多分支hydra存储库转换为单个分支模型非常简单。

首先，您要从与自身或主干或主干之间差异最小的分支开始。检查他们的年龄和相关性。如果它们仍然相关，请开始将它们合并在一起并解决冲突。如果它们不再相关，请删除它们。

继续此过程，直到您设法合并了所有分支，解决了所有冲突并且只剩下一个分支。

您可以按照以下简单的大纲开始操作：


创建主/树干分支的副本，并将其命名为temp_master

使用与主/客车的最大分歧。
确定是否需要保留，归档或删除分支。


如果需要保留，请继续执行步骤4。
如果需要将其删除或存档，请删除并存档，然后返回步骤2。


重复步骤2以找到差异最小的下一个分支。
合并步骤2和步骤3中找到的两个分支，解决所有冲突。
合并您的这两个分支进入您的temp_master分支。
测试temp_master代码中的代码，以查看其是否可以编译，构建以及运行其他任何自动化测试，以确保其完整性。


如果任何测试失败，请返回，找出原因，然后进行修复，然后重复该过程。
如果测试仍然失败，请选择两个不同的分支进行操作。


重复步骤2-7，直到只有两个分支为止，即主/主干和temp_master。 />最后，将temp_master合并到master / trunk中，并使用新的单分支模型。

#4 楼

对于通常具有4周冲刺周期的大型组织，首选Git-Flow，因为
您可以使用Feature分支
主生产就绪分支始终可部署
此外，Master分支可以保持清洁，避免不必要的干扰通过以下两个提交周期进行提交（从功能到Develop以及从Develop分支到主节点）。

此外，分支还取决于产品发布的频率。对于频繁部署到生产环境，最好具有功能分支或集中式模型。在这种情况下，将分支机构的管理费用转移到较低环境中的强大测试中，以保持生产稳定性。