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

Question

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

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

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

Answer 1

更新2019年：

这些天，问题将在使用Git的背景下看到，并且使用distributed开发的10年workflow（主要合作through GitHub）显示了一般的最佳实践：

• master是随时准备部署到生产中的分支：下一个版本，在master中合并了一组选定的功能分支。
• dev（或集成分支，或'next'）是为下一个版本选择的功能分支一起测试的那个
• maintenance（或hot-fix）分支是当前版本演变/错误修复的一个，with possible merges back to dev and or master

这种工作流程（你没有将dev合并到master，但你只将功能分支合并到dev，然后如果选择，则合并到master，以便能够轻松删除未准备好下一个版本的功能分支）使用gitworkflow（一个词，illustrated here）在Git repo本身中实现。 在rocketraman/gitworkflow查看更多信息。

（来源：Gitworkflow: A Task-Oriented Primer）

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

---

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

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

首先，你的后备箱中的所有东西是否真的适合下一个版本？您可能会发现一些当前开发的功能是：

• 太复杂，仍需要改进
• 还没准备好
• 有趣但不适用于下一个版本

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

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

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

当涉及到dev分支时，你可以有一个主干，除非你需要进行其他开发工作，例如：

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

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

---

回答Ville M.的评论：

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

Answer 2

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

• master - 开发代码
• 尺寸 - 生产代码

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

Answer 3

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

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

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

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

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

---

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

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

Answer 4

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

Answer 5

我们用：

• 开发部门专门

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

• 发布分支

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

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

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

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

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

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

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

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

Answer 6

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

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

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

这是一个更详细的逐步说明：

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

Answer 9

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

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

Answer 10

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

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

这种方式对于哪些代码工作没有混淆，它始终是主要分支。

Answer 11

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

Answer 12

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

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

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