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

在大型组织中，使用瀑布方法通常会导致非常复杂的分支结构（又称分支spagetti）。

可以使用哪些分支策略从复杂的分支现实过渡到基于分支的开发之类的单分支模型？

更新：

要澄清的是，问题是关于迁移/过渡本身，而不是关于之前和之后的方法，这很清楚。

不可能真的是“今天在EOB，我们仍然是拥有数以万计的分支机构的瀑布，但是明天第一件事，我们将切换到基于中继的单分支CI”。

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

在此设置中，我还假定这些分支是根据尝试最大程度减少冲突的瀑布计划创建的。这意味着开发的目标是生产几种不同的产品。使用单分支开发模型时，也必须在单个产品上工作。如果几个产品都在一个分支发展模式同步发展，它有效地“胶水”的论文产品在一起的版本，所以我们可能在版本一个版本库中的保健品的X和越野车产品Ÿ，而在版本b产品X具有回归功能，产品Y具有错误修复功能，但是我们没有X和你很健康。这种情况将迫使我们考虑X和Y是在不同的存储库中开发的，这暗示它们应该是。

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

1. 排列存储库，以便轻松将其拆分为几个小型存储库。例如，重新排列当前存储库，以使每个顶级目录对应于您将来要创建的存储库。这样做，您可以继续使用每个人都熟悉的意大利细面条学科。

2. 完成第1步后，通过要求任何单个分支只能触摸一个顶级目录中的文件来完善分支意粉规则。

3. 当每个分支都符合步骤2时，执行拆分。开发人员只需删除路径的第一级即可轻松地将其待处理的更改转换为修补单个存储库的补丁。

现在已经执行了拆分，您可以开始处理分支学科本身。

4. 介绍编程技术，以帮助开发短暂的分支。分支寿命短是所有单分支方法的关键方面。他们的目标之一是减少花费在合并和调试长期存在的分支上的时间。一种流行的技术是引入“功能标记”，其中“工厂”使用配置标记来生成对象的历史版本或该对象的新的，最初部分开发的版本。

5. 到现在为止，您拥有数不胜数的存储库，每个存储库中只有几个分支，并且可以单击“我们在全球范围内采用基于主干的开发规范”按钮，而不会看到原始的分支-意大利面条山在主干上倒塌。

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

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

1. 你的目标是什么
2. 如何到达那里（迁移计划）

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

您拥有的所有分支机构或已经达到目的的分支机构都有可能。如果没有明确定义的目标流程，人们将继续以最适合自己的方式做对自己有用的事情（正确的做法是）。

例如，您的目标应该明确定义为Vincent Driessen定义了他的“成功的Git分支模型”。如果您查看此模型，它将非常精确：它指出应该在哪里稳定代码，应该在哪里开发不稳定的功能。它还说明了如何以及何时分支，更新和合并。您知道每个分支的用途以及如何处理它们。我们使用Vincent提出的变体，并且在Wiki中定义了我们的变体。

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

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

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

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

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

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

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

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

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

您可以按照以下简单的大纲开始使用：

1. 创建您的master / trunk分支的副本并调用它 temp_master
2. 查找与主/干线最大分歧的分支。
3. 确定是否需要保留，归档或删除分支。
   1. 如果需要保留它，请继续执行步骤4。
   2. 如果需要删除或存档，请删除并存档，然后返回到步骤2。
4. 重复步骤2，找到差异最小的下一个分支。
5. 合并在步骤2和步骤3中找到的两个分支，解决所有冲突。
6. 将这两个分支合并到temp_master分支中。
7. 测试temp_master代码中的代码，以查看其是否可以编译，构建以及运行其他任何自动化测试，以确保其完整性。
   1. 如果任何测试失败，请返回，找出原因，然后进行修复，然后重复该过程。
   2. 如果测试仍然失败，请选择两个不同的分支来使用。
8. 重复步骤2-7，直到只有两个分支，主分支/主分支和temp_master。
9. 最后，合并temp_master到主/主干并使用新的单分支模型。

对于具有典型4周冲刺周期大型企业的Git流量是首选方法，因为你得到特性分支主生产准备分支的好处是始终部署另外，主分支保持清洁，从不需要提交通过以下两种提交周期（从功能Develop和Develop分支掌握）。

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