我们的项目已达到一个阶段，我们需要进行生产部署，但也需要持续开发 future 的功能。我们的源代码控制目前只有一个开发分支。在我之前的公司，建立了开发、集成、生产三个分支系统。功能开发在开发中完成，集成和生产中的测试始终是在当前生产环境中运行的代码(除了从集成到生产进行合并并完成部署的短暂时间)。
每次生产发生更改或合并到实时部署的生产中时，都会从生产中删除一个新的存档分支并赋予版本号。对更高分支的任何更改都会被合并回来，因此生产中的更改将返回到开发中。它有效，但我始终认为没有必要进行持续的集成和生产分支。
这个系统的两个方面我真的不喜欢:1)从集成分支合并到生产分支:我希望每次都有一个“干净”的生产分支，即使它们在合并后应该保持同步2) 该系统不允许系统的多个部署同时运行不同版本的代码，尽管我工作过的任何一个团队都还没有要求这样做。
我听说这种模型很常见，但在我现在设置的系统中，我提出以下建议:
拥有一个开发分支，每次开发准备好下次部署到生产时创建一个新的发布分支。发布分支被赋予一个版本号，然后再次分支到归档分支。测试是在 Release 分支上完成的。一旦部署，任何生产修复都在发布分支中完成，然后在部署获得批准后，将创建一个新的存档分支，并增加次要版本号。当开发中的新部署准备就绪时，将创建新的发布分支...
对我来说，这更简单，实际上更好:没有集成分支(较少合并)，并且每个部署都有一个新的生产(发布)分支，并满足当前的生产版本。我缺少什么？为什么选择开发、集成、生产模式？
谢谢
最佳答案
3 分支系统的优点是您的开发人员、测试人员和客户各自拥有自己独立的代码版本/分支。这提供了“门控”开发，其中功能只有在通过一定的完整性/质量标准时才能升级到下一个分支，从而使发布分支始终处于适合发送给客户的状态充满信心。
优点:
- 您(几乎)总是有一个可以立即发送给客户的版本。
- 您的测试人员(几乎)总是有一个可以测试的工作版本
- 发布分支很稳定，因此您不必经常修复其中的错误并将它们反向合并到测试/开发分支中。
缺点:
- 您必须经常合并才能将已完成的功能提升到发布分支。不过，这还不算太糟糕，因为此合并只是一个快速复制操作(只要您不在测试/发布分支中进行编辑，就永远不会遇到需要解决的合并冲突)
如果您采用单一开发分支的方法，仅在需要发布时才从中分离出发布分支，那么大多数时候您都在无分支的系统中有效地工作。也就是说，您的开发分支中有一个不稳定的正在进行的构建，然后您将其复制到发布分支，在那里您将其作为正在进行的工作进行处理，直到它稳定到发布质量为止。如果您在修复发布分支错误的同时继续在开发分支中开发功能，那么您将需要解决大量合并冲突。您花费了大量时间，没有一个好的构建版本可供测试，也没有一个可以在需要时发布的可发布构建版本。
发布时也没有太多需要将代码分支到存档分支 - 您所需要做的就是在发布时标记代码以获得可以恢复的可靠“快照”将来。
关于version-control - 版本控制 (TFS) : Need advice 的两种方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2353935/