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

我们已经在我们的项目中达到了一个需要进行生产部署但还需要持续开发未来功能的点。我们的源代码管理目前有一个开发分支。在我以前的公司中，开发，集成，生产部门设立了3个分公司系统。功能开发是在开发中完成的，在集成和生产中进行测试始终是在当前生产环境中运行的代码（除了从Integaration到Production以及完成部署完成合并的时间之外）。版本控制（TFS）的两种方法：需要建议

每当进行生产更改或合并到现场部署的生产中时，新的归档分支将被移出生产并给出版本号。对较高分支的任何更改都会合并回来，因此Production中的更改将使其回到开发阶段。它的工作，但我一直没有看到需要一个持续的集成和生产分支。

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

我听说过这个模型很常见，但在系统中，我建立我现在提出了以下几点：

有一个发展分支，创建一个新的发布分支每次发展为准备下一个部署生产。版本分支被赋予版本号，然后再次分支到归档分支。测试在Release分支上完成。部署完成后，在发布分支中完成任何生产修复，然后在部署获得批准后，创建新的归档分支，并添加次要版本号增量。当开发的新部署准备就绪时，将创建一个新的发布分支...

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

感谢

来源

2010-03-01 MrLane

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

优点：

你（几乎）总是有可能在瞬间被发送到客户注意到一个版本。
您的测试人员（几乎）总是有一个工作版本来测试
发布分支是稳定的，因此您通常不必修复其中的错误并将它们反向合并到测试/开发分支中。

缺点：

你必须经常合并推动完成功能到发布分支。这并不算太坏，因为这种合并只是一种快速复制操作（只要您不在测试/发布分支中进行编辑，您就不会遇到合并冲突）

如果你只需要一个单独的开发分支的方法，当你需要一个版本时，你就可以从中分离出一个分支，那么你大部分时间都在非分支系统中有效地工作。也就是说，您的开发分支中有一个不稳定的正在进行的构建，然后将其复制到发布分支中，在那里将其作为正在进行中的工作，直到它稳定下来以释放质量。如果您在修复发行版分支时继续在开发分支中开发功能，那么您将收到大量合并冲突来解决。如果没有一个好的构建来测试，你会花费很多时间，如果没有可释放的构建，你可以根据需要发布。

当您发布时，并不需要将代码分支到归档分支中 - 您只需在执行发布时标记代码以获得可靠的“快照”即可将来恢复。

来源

2010-03-04 22:21:40