处理长期项目的产品版本控制和分支的最佳方法是什么？

一般而言，对于在产品生命周期中可能有多个版本并且需要先前产品支持的长期项目，处理产品版本和代码分支的最佳方法是什么？

从更具体的意义上说，假设适当的分布式版本控制在位（即git），并且团队的大小由小到大，并且开发人员可能同时从事多个项目。面临的主要问题是，有合同义务支持当时存在的旧版本，这意味着新开发无法修补旧代码（Microsoft Office产品可能就是其中的一个示例，您只能获得针对您拥有的功能年份）。

结果，当前的产品版本控制令人费解，因为每个主要产品都具有多个依赖项，每个依赖项都有其自己的版本，这些版本可能会在年度版本之间发生变化。同样，尽管每个产品都有其自己的存储库，但大部分工作不是在主要源主干上完成，而是在该年产品发布的分支上完成，而在发布产品时将创建一个新的分支，以便对其进行支持。反过来，这意味着获得产品的代码库并非易事，因为使用版本控制时可能会想到。

您需要多少（和哪种类型）结构在很大程度上取决于您想要执行的操作。弄清楚没有什么，没有什么，想要什么，以及什么不在乎。

一组好的决策示例可能是：

我们不能没有的生活：

• 能够随时重建任何过去的发行版
• 能够随时维护产品的多个受支持的主要版本

我们希望拥有的东西：

• 能够进行正在进行的主要功能开发（针对下一个主要版本），而不必担心分支合并
• 能够对过去的版本执行维护更新

我们可以没有的生活：

• 从当前工作到过去版本的变更的自动反向移植
• 永远不会中断主要功能的开发，即使是几天或一周

如果以上是您的目标，则可以采用以下过程：

1. 在VCS的主干上做所有开发工作（git中的“ master”）
2. 当您即将发布主要版本时，请停止主要功能的开发，并专注于一周左右的系统稳定性
3. 当主干看起来稳定时，为此主要版本创建一个分支
4. 现在可以在主干上进行主要功能的开发，而分支上仅允许错误修复和发行准备
5. 但是，必须首先在主干上测试对分支所做的所有错误修复。这样可以确保它们也将出现在所有将来的版本中
6. 准备发布时，在分支上创建一个（VCS）标签；即使在同一分支上进行了进一步的工作之后，也可以随时使用此标记来重新创建发行版
7. 现在可以在分支上准备对该主要版本（次要版本）的进一步维护版本；每个都将在发布前被标记
8. 同时，针对下一个主要版本的主要功能开发可以继续进行
9. 当您接近该发行版时，请重复上述步骤，为该发行版创建一个新的发行版分支。这使您可以同时具有处于支持状态的多个主要发行版，每个主要发行版在其自己的分支上，并且能够针对每个发行版发行单独的次要发行版。

此过程不会回答您所有的问题-特别是，您将需要一个适当的过程来确定可以对发布分支进行哪些修复，并确保不首先在发布分支上修复错误（此类修复）应尽可能在后备箱上进行测试）。但这将为您提供做出此类决策的框架。

“长期”是您需要版本控制的指示，但并不表示任何特定的版本控制和分支策略。更有趣的问题是您要支持多少个产品系列或主要版本系列（取决于与您的客户的合同）。您拥有维护合同的每个产品系列/主要版本系列至少需要一个分支。

另一方面，这取决于您的团队规模。如果您拥有庞大的开发团队，并且由不同的人并行处理不同的要素，那么与拥有一两个人的团队相比，显然需要更多的要素分支。如果您正在与更大的团队合作，则应考虑使用分布式版本控制，这可以使在不同分支上的并行工作（并在以后将它们重新集成到主干中）更加高效。

Git是一个版本控制工具-它管理文件的版本。您所需要的是一个配置管理工具。这些功能令人满意，但大多数来自IBM之类的公司。

版本控制工具提供了分支和标记功能，无需额外的工具支持即可进行简单的配置管理，因此精打细算的开发人员无法理解它们之间的区别。您的需求可能超出了GIT设计的范围。

我不知道，但可以肯定它会存在，它是用于Git的CM工具。

这个问题似乎与我最近回答的另一个问题非常相似。

简而言之，这听起来更像是产品设计和发行问题，而不是版本控制/分支问题。当然，如果您已经深陷问题之列，对我来说这很容易说，对您来说更难解决。

没有更详细地了解您的特定问题的细节。但是，总的来说，如果我有一个基于代码库的产品版本，并且产品之间有大量共享代码，那么如果可行的话，我希望以一种使产品更具模块化的方式重构产品，并且确保模块本身不需要其他代码分支。我还将查看我的部署模型，以查看是否有更好的方法来支持我的客户，同时仍保持许多代码库的统一。在需要特定客户定制的情况下，可能需要更大的模块粒度以减少系统中重复代码的数量。

这不是一件容易的事，但是如果您可以很好地管理工作，并且可以安排工作的时间，从而不需要一次全部“升级”，就可以分阶段进行修复。