您如何维护开发代码和生产代码？[关闭]

维护代码时应遵循的最佳实践和经验法则是什么？在开发分支中仅提供生产就绪代码是一种好习惯，还是在开发分支中提供未经测试的最新代码？

你们如何维护您的开发代码和生产代码？

编辑-补充问题-您的开发团队是否遵循“尽快并可能甚至在代码中包含次要错误或未完成的情况下提交”协议或“提交-将代码提交到DEVELOPMENT分支时是否只有“完美代码”协议？

更新2019：

这些天来，这个问题将在使用Git的上下文中看到，并且使用分布式的 10年开发工作流（主要通过GitHub进行协作）的展示了一般的最佳实践：

• master是随时可以部署到生产中的分支：下一个版本，其中已合并了一组选定的功能分支master。
• dev（或集成分支，或' next'）是一起测试为下一版本选择的功能分支的分支
• maintenance（或hot-fix）分支是当前版本演进/错误修复的分支，并可能合并回dev和或master

这种工作流程（您不合并dev到master，而是只合并功能分支到dev，然后如果选择则合并到master，以便能够轻松删除不准备用于下一版本的功能分支）使用gitworkflow（一个词，在此说明）回购自身。
查看更多rocketraman/gitworkflow。亚当·迪米特鲁克（Adam Dymitruk）在本文的评论和讨论中记录了这样做与主干开发之间的历史。

^{（资源： Gitworkflow：面向任务的入门）}

注意：在该分布式工作流程中，您可以随时提交并向个人分支推送一些WIP（进行中的工作）而不会出现问题：您可以重新组织（git rebase）提交，然后再将它们纳入功能分支。

原始答案（2008年10月，十多年前）

这完全取决于发布管理的顺序性质

首先，行李箱中的所有物品是否真的适用于下一版本？您可能会发现一些当前开发的功能是：

• 太复杂了，仍然需要完善
• 没有及时准备
• 有趣，但不适用于下一个版本

在这种情况下，主干应该包含当前的所有开发工作，但是在下一个发行版之前定义的发行分支可以用作合并分支，在该合并分支中，仅合并适当的代码（针对下一个发行版进行了验证），然后在认证阶段进行修复，最终在生产过程中冻结。

当涉及到生产代码时，还需要管理补丁程序分支，同时请记住：

• 第一组补丁实际上可能是在首次发布到生产环境之前开始的（这意味着您知道您将带着一些无法及时修复的错误进入生产环境，但是您可以在单独的分支中启动这些错误的工作）
• 其他补丁分支将从定义明确的生产标签开始奢侈

对于开发分支，您可以有一个主干，除非您需要进行其他并行开发，例如：

• 大规模重构
• 测试新的技术库可能会改变您在其他类中调用事物的方式
• 新发行周期的开始，需要合并重要的体系结构更改。

现在，如果您的开发-发布周期是非常连续的，则可以按照其他答案的建议进行操作：一个主干和多个发布分支。这适用于小型项目，在该小型项目中，所有开发都必定会进入下一个发行版，并且可以冻结，并用作发行分支的起点，可以在该分支进行补丁。那是正常的过程，但是一旦您有一个更复杂的项目……这已经不够了。

回答Ville M.的评论：

• 请记住，开发分支并不意味着“每个开发人员一个分支”（这会引发“合并疯狂”，因为每个开发人员必须合并其他人的工作才能看到/获得他们的工作），而是每个开发一个开发分支努力。
• 当需要将这些工作合并到主干（或您定义的任何其他“主”或发布分支）中时，这是开发人员的工作，而不是 -我再说一遍，不是-SC经理（谁不知道如何解决）任何有冲突的合并）。项目负责人可以监督合并，这意味着确保合并按时开始/完成。
• 无论您选择实际进行合并的哪个人，最重要的是：
  • 具有单元测试和/或组装环境，您可以在其中部署/测试合并结果。
  • 在合并开始之前已定义了一个标签，以便在所述合并证明自身过于复杂或解决时间过长时能够返回到先前状态。

我们用：

• 开发部专门

直到项目接近完成，或者我们正在创建一个里程碑版本（例如，产品演示，演示版本），然后（定期）将当前的开发分支分支到：

• 发布分支

没有新功能进入发布分支。在发行分支中仅修复了重要的错误，而用于修复这些错误的代码已重新集成到开发分支中。

由开发和稳定（发布）分支组成的两部分过程使我们的工作变得更加轻松，我不相信我们可以通过引入更多分支来改善其中的任何部分。每个分支都有其自己的构建过程，这意味着每两分钟就会产生一个新的构建过程，因此在代码签入后，我们将在大约半小时内找到所有构建版本和分支的新可执行文件。

有时，我们也为单个开发人员提供分支机构，以开发新的未经验证的技术或创建概念验证。但是通常只有在更改影响代码库的许多部分时，才可以执行此操作。这种情况平均每3-4个月发生一次，而这样的分支通常会在一两个月内重新整合（或报废）。

通常，我不喜欢每个开发人员都在自己的分支机构工作的想法，因为您“跳过并直接进入集成地狱”。我强烈建议不要这样做。如果您有一个通用代码库，则应该一起使用它们。这使开发人员对他们的签入更加警惕，并且每位编码人员都具有丰富的经验，知道哪些更改有可能破坏构建，因此在这种情况下测试将更加严格。

关于提前入住的问题：

如果您只需要签入PERFECT CODE，那么实际上什么都不需要签入。没有代码是完美的，并且要QA对其进行验证和测试，它必须在开发分支中，以便可以构建新的可执行文件。

对我们来说，这意味着一旦某个功能完成并由开发人员测试，就将其检入。甚至可以检入是否存在已知（非致命）错误，但在那种情况下，可能会受到该错误影响的人是通常情况下 仅当不引起任何明显的负面影响（如崩溃或破坏现有功能）的情况下，也可以检入不完整且仍在进行中的代码。

直到现在，在构建新代码之前，不可避免的代码和数据组合检查将使程序无法使用。我们至少要做的是在签到注释中添加“ WAIT FOR BUILD”和/或发送电子邮件。

对于它的价值，这就是我们的做法。

大多数开发工作都是在主干中进行的，尽管实验性功能或可能会严重破坏系统的功能往往会获得自己的分支。这非常有效，因为这意味着每个开发人员始终在其工作副本中拥有所有内容的最新版本。

这确实意味着将中继线保持在模糊的工作状态非常重要，因为完全可以完全断开它。在实践中，这种情况很少发生，并且很少是重大问题。

对于生产版本，我们分支主干，停止添加新功能，并进行错误修复和测试分支（定期合并回到主干），直到可以发布为止。这时，我们将最终合并到主干中，以确保所有内容都在其中，然后释放。

然后，可以根据需要在发布分支上执行维护，并且这些修订可以轻松地合并回主干。

我并不是说这是一个完美的系统（它仍然存在一些漏洞-我认为我们的发布管理还不够严格），但是它运作良好。

为什么没人提这个呢？成功的Git分支模型。

对我来说，这是最终的分支模型！

如果您的项目很小，请不要一直使用所有不同的分支（也许您可以跳过小的特征的特征分支）。但是否则，这就是这样做的方式！

分支上的开发代码，在Trunk上标记的实时代码。

不需要“只提交完美的代码”规则-开发人员错过的所有内容都应该在四个地方处理：代码审查，分支测试，回归测试，最终QA测试。

这是更详细的分步说明：

1. 在分支上进行所有开发，并在执行过程中定期提交。
2. 完成所有开发后，对变更进行独立代码审查。
3. 然后将分支传递到测试。
4. 分支测试完成后，将代码合并到Release Candidate分支中。
5. 每个单独的合并后，对Release Candidate分支进行回归测试。
6. 所有开发分支合并后，将在RC上进行最终的质量检查和UA测试。
7. 通过QA和UAT后，将发布分支合并到MAIN / TRUNK分支。
8. 最后，在那时标记Trunk，然后将该标记部署到Live。

开发人员进入主干（SVN风格），发布（生产代码）获得自己的分支

这就是“按目的划分的模型”（分支模型的重要性中的图3 /！\ pdf）

我们通过将生产代码（主干）与开发代码（每个开发人员都有自己的分支）完全分开来解决此问题。

在生产代码中，未经质量检查和代码审查者彻底检查，不得将任何代码写入生产代码。

这样就不会混淆哪个代码有效，它始终是主要分支。

哦，是的-另一件事-我们将非生产代码（即永远不会发布的代码-例如工具脚本，测试实用程序）保留在cvs HEAD中。通常，需要对其进行清楚的标记，以便没人“意外”释放它。

我们在树干上进行开发，然后每两周分支一次并投入生产。分支中仅修复了严重的错误，其余的可以再等待两周。

对于主干，唯一的规则是提交不应破坏任何内容。要管理wip代码和未经测试的代码，我们只需添加相应的if语句即可轻松打开和关闭。

基本上，可以随时分支主干并将其投入生产。

我使用git并且有2个分支：master和maint

• 主-开发代码
• 维护-生产代码

当我将代码发布到生产环境时，我对其进行了标记，并将master合并到maint分支。我总是从维护分支进行部署。来自开发分支的补丁我将它们挑选到维护分支并部署补丁。

我们有一个“发布”分支，其中包含当前正在生产或即将部署的产品（已通过大多数质量检查）

每个项目，或在某些情况下为其他单元，都有其自己的分支，该分支从发行版开始分支。

由项目开发人员将更改提交到其项目自己的分支中。发行版会定期合并回开发分支。

一旦分支上的所有工作包都经过了质量检查（单元测试，系统测试，代码审查，QA审查等），分支将合并到发布分支中。新版本是从release分支构建的，最终验证在该版本上进行。

在完成合并后发现问题之前，该过程基本上是可以的。如果WP在合并后被“卡住”，它将保留它之后的所有内容，直到它被修复为止（在释放被卡住的WP之前，我们无法进行其他发行）。

它在某种程度上也很灵活-如果在很短的时间内（例如1-2天左右）发布，则可以在发布分支上直接进行非常小的更改。

如果出于某种原因将更改直接应用于生产（严重的影响客户的生产问题，需要立即更改代码以进行修复），则将这些更改放回BRANCH_RELEASE中。那几乎不会发生。

这取决于项目。我们的Web代码被一致地签入，而我们的应用程序代码仅在编译时才被签入。我注意到这与我们发布内容的方式非常相似。在应用程序遇到困难的最后期限时，Web内容会尽可能地增加。我没有看到任何一种方法的质量下降。