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

Question

维护代码时遵循的最佳实践和规则是什么？在开发分支中只有生产就绪代码是好的做法，还是应该在开发分支中提供未经测试的最新代码？

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

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

Answer 1

这一切都取决于你的发布管理的顺序性质

首先，是一切都在你的躯干真正为下一个版本？ 你可能会发现，一些目前开发的功能是：

• 过于复杂，仍然需要改进
• 没有准备好及时
• 有趣的，但不是这个下一代版本

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

当涉及到生产代码，您还需要管理你的补丁分支，同时牢记：

• 第一片组实际上可能之前开始首次发布到生产（意思你知道你会投入生产，但有些bug你不能及时修复，但你可以在单独的分支中为这些bug启动工作）
• 其他补丁分支将有奢侈品从一个明确定义的生产标签开始

当谈到Dev分支，你可以有一个主干，除非你有其他的开发工作，你需要做并行像：

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

现在，如果您的开发发布周期非常顺序，您可以按照其他答案的建议去做：一个主干和多个发布分支。这适用于小型项目，其中所有的开发工作都将进入下一个版本，并且可以被冻结，并成为发布补丁的起点，补丁可以发生。这是名义上的过程，但只要你有一个更复杂的项目......这是不够的。

---

要回答威乐M.的评论：

• 记住，Dev分支母鹿并不意味着“每开发一个分支”（这会触发“合并疯狂”，在每个开发人员将不得不合并其他人的工作以查看/获得他们的工作），但是每个开发工作需要一个开发分支。
• 当这些努力需要合并回主干（或您定义的任何其他“主”或发布分支）时，这是开发人员的工作，而不是 - 我再说一遍，不是 - SC管理员不知道如何解决任何冲突的合并）。项目负责人可能会监督合并，这意味着确保它按时开始/完成。
• 您选择适合实际不执行合并谁，最重要的是：
  • 有单元测试和/或装配环境中，你可以部署/测试合并的结果。
  • 已定义的标签之前合并，以便一开始就能够回到以前的状态，如果说合并证明其本身过于复杂或相当长来解决。

Answer 2

开发进去干线（SVN的风格）和版本（产品代码）得到了自己的分支机构

很 “科，按用途模式”（图3 The importance of branching models /！\ PDF）

Answer 3

我使用Git和我有2个分支：主和MAINT

• 主 - 开发代码
• 维护 - 机生产线ction代码

当我释放的代码到生产，我标记它，我合并主到MAINT分支。我总是部署maint分支。来自开发部门的修补程序我将它们选择到maint分支并部署修补程序。

Answer 4

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

在生产代码被彻底检查之前（通过质量检查和代码审查人员），没有代码被允许进入生产代码。

这种方式不会混淆哪些代码有效，它始终是主分支。

Answer 5

对于它的价值，这是我们如何做到这一点。

大部分开发工作都是在树干中进行的，尽管实验功能或可能会破坏系统的东西显然倾向于获得他们自己的分支。这很好，因为它意味着每个开发人员总是在其工作副本中拥有最新版本的所有内容。

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

对于产能的释放，我们支干线，停止添加新的功能，并在bugfixing和测试分支（定期合并回主干），直到它准备发布工作。在这一点上，我们做了一个最终的并入，以确保一切都在那里，然后释放。

维护然后可以根据需要对发布分支执行，这些补丁可以很容易地合并到主干。

我不主张这是一个完美的系统（它仍然有一些漏洞 - 我不认为我们的发布管理是足够紧密的过程还没有），但它工作得很好。

Answer 6

我们有一个“放”，其中包含目前什么是对生产或即将部署分支（已通过最QA）

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

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

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

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

---

它也一定柔性的 - 一个很琐碎的变化可以直接在发布分支发生，如果它被在很短的时间尺度释放（如1-2天左右）。

如果一个变化是把直接在生产某种原因（一个重要的客户，影响生产问题，它需要立即更改代码修复），这些更改将被放回BRANCH_RELEASE。那几乎没有发生过。

Answer 7

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

Answer 8

我们使用：

• 开发分支专门

，直到项目接近完成，或者我们正在创造一个里程碑版本（例如。产品演示，演示版本），那么我们（经常）岔开我们目前的发展科进：

• 发布分支

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

与发展和稳定的过程分为两个部分（释放）分支，使生活变得更加简单了我们，我不相信我们可以通过引入更多的分支机构提高它的任何部分。每个分支也有它自己的构建过程，这意味着每隔几分钟就会产生一个新的构建过程，因此在代码签入后，我们会在大约半小时内为所有构建版本和分支创建一个新的可执行文件。

系统有时也有分支的一个开发人员工作的一个新的，未经证实的技术，或创建一个概念证明。但通常只有在更改影响代码库的许多部分时才会这样做。这种情况平均每3-4个月发生一次，这种分支通常在一两个月内重新整合（或报废）。

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

在入住初期问题：

如果你只需要理想码进行检查的，那么其实也没什么应该得到检查没有代码是完美的，对于QA检验和测试。它需要在开发分支中，因此可以构建一个新的可执行文件。

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

时不时不可避免的合并码&数据签入将使该程序无法使用，直到新的代码已经建成。我们至少要在签入评论中添加“WAIT FOR BUILD”并/或发送电子邮件。在树枝上

Answer 9

开发代码，现场代码标签上的树干。

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

这里有一个更详细的一步一步的解释：

1. 做所有的分支上开发，经常犯，当您去。
2. 独立代码一旦所有的开发完成，审查更改。
3. 然后通过分支到测试。
4. 分支测试完成后，将代码合并到Release Candidate分支中。
5. 发布候选分支在每次合并后都会进行回归测试。
6. 在所有开发分支合并后对RC执行的最终QA和UA测试。
7. 一旦QA和UAT通过，合并发布分支到MAIN/TRUNK分支。
8. 最后，在此处标记中继，然后将该标记部署到Live。

Answer 10

我们在树干上开发，然后每两周分支并投入生产。只有重要的bug在分支中被修复，其余的可以再等两个星期。

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

基本上它可以在任何时候分支树干并投入生产。

Answer 11

这取决于项目。我们的网页代码被非常一致地检查，而我们的应用程序代码只在编译时才被检查。我注意到这和我们发布的东西非常相似。当应用程序遇到严格的最后期限时，Web应用程序可以随时增加。虽然我没有看到任何一种方法的质量损失。

Answer 12

为什么没有人提到这一点？ A successful Git branching model。

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

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