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

Question

维护代码时要遵循的最佳做法和经验法则是什么？在开发分支中只有生产就绪代码，或者开发分支中是否应该提供未经测试的最新代码，这是一种好习惯吗？

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

编辑 - 补充问题 - 您的开发团队是否遵循“尽快提交 - 通常 - 甚至是代码包含 - 次要错误或不完整”协议或在将代码提交给DEVELOPMENT分支时，“commit-ONLY-perfect-code”协议？

Answer 1

更新2019年：

现在，问题将在使用Git的上下文中看到，并且使用distributed开发10年（{3}}（主要是workflow合作）显示了一般的最佳实践：< / p>

• master是随时可以部署到生产环境中的分支：下一个版本，其中选定的一组功能分支合并在master中。
• dev（或集成分支，或“next”）是为下一版本选择的功能分支一起测试的那个
• maintenance（或hot-fix）分支是当前版本演变/错误修复的分支，through GitHub

这种工作流程（您不将dev合并到master，但只将功能分支合并到dev，如果选择，则合并到master ，为了能够轻松删除未准备好下一个版本的功能分支）在Git仓库中实现，使用 with possible merges back to dev and or master （一个词，gitworkflow） 。
请参阅illustrated here。

rocketraman/gitworkflow

^{（来源：）}

注意：在该分布式工作流中，您可以随时提交并将某个WIP（正在进行中）工作推送到个人分支而不会出现问题：您可以重新组织（git rebase）您的提交，然后再将其作为其中的一部分特色分支。

---

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

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

首先，您的主干中的所有内容是否真的适用于下一个版本？ 您可能会发现一些当前开发的功能是：

• 过于复杂，仍需要精炼
• 没有及时准备好
• 有趣，但不适用于下一个版本

在这种情况下，trunk应该包含任何当前的开发工作，但是在下一个版本之前定义的发布分支可以作为 合并分支 ，其中只有相应的代码（在下一个版本中验证）合并，然后在认证阶段修复，最后在投入生产时冻结。

说到生产代码，您还需要管理补丁分支，同时请记住：

• 第一组补丁实际上可能在第一次发布到生产之前开始（意味着你知道你将投入生产时遇到一些你无法及时解决的错误，但是你可以在一个单独的分支中启动那些错误的工作）< / LI>
• 其他补丁分支可以从明确定义的生产标签
开始

说到dev分支，你可以拥有一个主干，除非你需要进行其他开发工作，你需要将并行：

• 大规模重构
• 测试新技术库，这可能会改变您在其他课程中调用内容的方式
• 新版本周期的开始，需要整合重要的架构变更。

现在，如果你的开发 - 发布周期是非常顺序的，你可以像其他答案所说的那样：一个主干和几个发布分支。这适用于小型项目，其中所有开发都必须进入下一个版本，并且可以冻结并作为发布分支的起点，可以在其中进行补丁。这是名义上的过程，但只要你有一个更复杂的项目......它就不够了。

---

回答Ville M.的评论：

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

Answer 2

我们使用：

• 开发分支

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

• 发布分支

没有新功能进入发布分支。只有重要的错误在发布分支中修复，修复这些错误的代码重新集成到开发分支中。

具有开发和稳定（发布）分支的两部分流程使我们的生活变得更加轻松，我不相信我们可以通过引入更多分支来改进它的任何部分。每个分支也有自己的构建过程，这意味着每隔几分钟就会生成一个新的构建过程，因此在代码检查之后，我们会在大约半小时内获得所有构建版本和分支的新可执行文件。

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

一般来说，我不喜欢每个开发人员在自己的分支机构工作的想法，因为你“跳过去直接转向集成地狱”。我强烈建议不要这样做。如果你有一个共同的代码库，你应该一起工作。这使得开发人员对其签名更加谨慎，并且根据经验，每个编码人员都知道哪些更改可能会破坏构建，因此在这种情况下测试更加严格。

早早办理登机手续的问题：

如果您只需要签入 PERFECT CODE ，那么实际上什么都不应该被检入。没有代码是完美的，并且QA需要验证和测试它，它需要在开发分支，因此可以构建一个新的可执行文件。

对我们而言，这意味着一旦某个功能完成并由开发人员进行测试，就会检入。甚至可以检查是否存在已知（非致命）错误，但在这种情况下，受影响的人通常会通知bug。还可以检查不完整和正在进行的代码，但前提是它不会导致任何明显的负面影响，例如崩溃或破坏现有功能。

偶尔会出现一个不可避免的组合代码＆amp;数据签入将使程序无法使用，直到构建新代码。我们至少要在登记注释中添加“等待构建”和/或发送电子邮件。

Answer 3

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

大多数开发都是在trunk中进行的，尽管可能会破坏系统的实验性功能或事物会显着地获得自己的分支。这很好，因为它意味着每个开发人员都在其工作副本中始终拥有最新版本的所有内容。

这确实意味着保持行李箱处于模糊的工作状态非常重要，因为它完全可以完全打破它。在实践中，这种情况并不经常发生，并且很少是一个重大问题。

对于生产版本，我们分支主干，停止添加新功能，并处理错误修正和测试分支（定期合并回主干），直到它准备好发布。在这一点上，我们最后合并到trunk中以确保一切都在那里，然后释放。

然后可以根据需要在发布分支上执行维护，这些修复可以很容易地合并回主干。

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

Answer 4

为什么没人提这个呢？ A successful Git branching model

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

如果您的项目很小，请不要一直使用所有不同的分支（也许您可以跳过小功能的功能分支）。但除此之外，它就是这样做的方式！

Answer 5

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

不需要“只提交完美代码”规则 - 开发人员错过的任何东西都应该在四个地方被选中：代码审查，分支测试，回归测试，最终QA测试。

以下是更详细的逐步说明：

1. 在分支机构进行所有开发，随时进行。
2. 独立代码在所有开发完成后审核更改。
3. 然后将分支传递给Testing。
4. 分支测试完成后，将代码合并到Release Candidate分支。
5. 发布候选分支在每次合并后进行回归测试。
6. 在所有dev分支合并后，在RC上执行最终QA和UA测试。
7. 一旦通过QA和UAT，将发布分支合并到MAIN / TRUNK分支。
8. 最后，在此时标记Trunk，并将该标记部署到Live。

Answer 6

dev进入trunk（svn样式）和release（生产代码）获得自己的分支

这是“分支目的模型”（The importance of branching models /！\ pdf中的图3）

Answer 7

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

在彻底检查之前，没有代码被允许进入生产代码（由QA和代码审查员）。

这样就不会混淆哪些代码有效，它总是主要的分支。

Answer 8

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

Answer 9

我们在树干上开发，然后每两周分支并投入生产。只有关键错误在分支中修复，其余的可以再等两周。

对于trunk，唯一的规则是提交不应该破坏任何东西。要管理wip代码和未经测试的代码，我们只需添加适当的if语句，以便轻松切换打开和关闭。

基本上，任何时候都可以将树干分支并投入生产。

Answer 10

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

• master - 开发代码
• maint - 生产代码

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

Answer 11

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

每个项目，或在某些情况下，其他单位，都有自己的分支，从发布分支。

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

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

在合并完成后发现问题之前，该过程基本上没问题。如果一个WP在合并之后被“卡住”，它会在它之后保留所有内容，直到它被修复为止（我们不能再发布另一个版本，直到卡住了一个）。

---

它也有点灵活 - 如果在非常短的时间内（例如1-2天左右）发布，那么发布分支上可能会发生非常微不足道的变化。

如果由于某种原因直接将更改置于生产中（影响生产的关键问题，需要立即修改代码），那么这些更改将被放回到BRANCH_RELEASE中。这几乎不会发生。

Answer 12

这取决于项目。我们的Web代码检查非常一致，而我们的应用程序代码只有在编译时才会签入。我注意到这与我们发布的东西非常相似。当应用程序遇到困难的最后期限时，Web内容会随时上升。不过，我没有看到任何一种方法的质量下降。