版本控制（TFS）的两种方法：需要建议

Question

我们正在我们的项目中达到一个点，我们需要进行生产部署，但还需要持续开发未来的功能。我们的源代码控制目前只有一个开发分支。在我以前的公司中，建立了一个3分支系统，包括开发，集成，生产。功能开发在开发中完成，在集成和生产中进行测试始终是在当前生产环境中运行的代码（从Integaration到生产合并完成并且部署完成时的breif时间除外）。

每次实时部署生产变更或合并到生产中时，新的归档分支将从生产中取出并获得版本号。对更高分支的任何更改都被合并回来，因此生产中的更改将使其返回到Development。它有效，但我一直认为不需要正在进行的集成和制作部门。

这个系统的两个方面我真的不喜欢：1）从Integration分支到Production分支的合并：我希望每次都有一个“干净”的Production分支，即使它们在合并后应该同步2）该系统不允许同时运行不同版本代码的系统进行多次部署，尽管这对我所工作的任何一个团队来说都不是必需的。

我听说这种模式很常见但是我现在正在建立的系统我提出以下建议：

拥有一个开发分支，每次开发准备好进行下一次生产部署时，都要创建一个新的Release分支。 Release分支将获得版本号，然后再次分支到归档分支。测试在Release分支上完成。部署完成后，在Release分支中完成任何生产修复，然后在部署批准后创建一个新的归档分支，并带有次要版本号增量。当Development中的新部署准备就绪时，将创建一个新的Release分支......

对我而言，这更简单，实际上更好：没有Integaration分支（较少合并），每个部署都有一个新的生产（发布）分支，适合当前的生产版本。我错过了什么？为什么选择开发，集成，生产模式？

由于

Answer 1

你的建议离建议不太远。 模型的主要区别在于，您建议您直接在以前的“集成”分支上进行开发。很多人建议从这个分支机构分支机构完成他们的工作，然后重新合并。但这取决于你团队的规模。

使用TFS分支的宝贵资源如下：

http://tfsbranchingguideiii.codeplex.com/

Answer 2

3分支系统的优势在于您的开发人员，测试人员和客户都拥有自己的代码隔离版本/分支。这提供了一种“门控”开发，其中功能只有在通过某个完整性/质量条时才能被提升到下一个分支，从而高度确信发布分支始终处于适合发送给客户的状态。

优点：

• 您（几乎）总是有一个可以立即发送给客户的构建。
• 您的测试人员（差不多）总是有一个工作版本来测试
• 发布分支是稳定的，因此您不必经常修复其中的错误并将它们反向合并到测试/ dev分支中。

缺点：

• 您必须经常合并以推广已完成的功能，直至发布分支。这不是太糟糕，因为这个合并只是一个快速复制操作（只要你不在测试/发布分支​​中进行编辑，你就不会有合并冲突来解决）。

如果您采用单个开发分支的方法，只有在需要发布时才从中拆分发布分支，那么大多数情况下您实际上是在一个不分支的系统中工作。也就是说，您的dev分支中有一个不稳定的工作进度构建，然后您可以将其复制到一个发布分支中，您可以将其作为一个正在进行的工作进行处理，直到它稳定下来以释放质量。如果在修改发布分支时继续开发dev分支中的功能，则会遇到很多合并冲突需要解决。你花了很多时间没有一个好的构建来测试，没有可发布的构建，你可以在需要时发布。

当您发布时，还没有太多需要将代码分支到归档分支 - 您需要做的就是在执行发布时标记代码以获得可以恢复的可靠“快照”将来。

Answer 3

您的提案听起来就像我的工作方式：

• 我在主要分支开发，直到我的开发准备就绪
• 然后创建一个发布分支，比如发布1.5
• 在测试发布分支后，它再次分支，称之为1.5.1
• 错误修复在主分支和所有活动版本分支（例如1.3,1.4,1.5）
中完成
• 定期发布分支机构的新版本（分支机构）并发送给客户（例如1.5.2,1.5.3 ......）

根据我的经验，这非常有效，但可能还取决于贵公司的组织方式。

Answer 4

我以前工作的一个地方每个版本都有一个分支。我们花在分支上的时间比合并时间多。这有点过分了。

如果您想到带有连接节点图的心理模型，则生产分支只是连接到主集成分支的另一个节点。