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

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

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

编辑-补充问题-您的开发团队在向 DevelopMENT 分支提交代码时，是否遵循“尽快提交并且经常即使代码包含小错误或不完整”协议或“提交仅完美代码”协议？

56223 次浏览
小开

Dev 进入主干(svn 样式)并发布(产品代码)得到它们自己的分支

这是“按目的划分的模型”(分支模型的重要性/! pdf 中的图3)

小开

我使用 git 并且我有两个分支: 师父和 保持

  • 主开发代码
  • 维修生产代码维修生产代码

当我将代码发布到生产环境中时，我对它进行标记，并将 师父合并到 保持分支。我总是从 保持分支部署。我从开发分支中挑选补丁来维护分支并部署补丁。

小开

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

在完全检查生产代码之前(由质量保证(QA)和代码审查员) ，不允许任何代码进入生产代码。

这样就不会混淆哪些代码可以工作，它总是主分支。

小开
最佳答案

2019年更新:

如今，这个问题可以在使用 Git 的上下文中看到，使用 分发开发 工作流程(主要是 通过 GitHub协作)的10年显示了一般的最佳实践:

  • master是随时可以部署到生产环境中的分支: 下一个版本中，一组选定的特性分支合并到 master中。
  • dev(或集成分支，或‘ next’)是为下一个版本选择的特性分支一起进行测试的分支
  • maintenance(或 hot-fix)分支是针对当前版本进化/bug 修复的 与可能的合并返回到 ABC2和或 master分支

这种工作流程(你不合并 dev到 master，但是你只合并功能分支到 dev，然后如果选择，到 master，为了能够很容易地删除功能分支没有准备好下一个版本)是在 Git 回购本身，与 吉特工作流(一个词，这里有插图)。
在 本文作者: Adam Dymitruk的评论和讨论中记录了这样做和基于主干的开发的历史。

https://github.com/rocketraman/gitworkflow/raw/master/docs/images/topicgraduation.png

(资料来源: 面向任务的入门教程)

注意: 在分布式工作流中，你可以随时提交，并且可以毫无问题地将一些在制品(Work In Progress)推送到个人分支: 在将提交变成功能分支的一部分之前，你可以重新组织(git rebase)你的提交。

原始答案(2008年10月，10多年前)

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

首先，你后备箱里的东西都是 真的是为了下一个版本吗？ 您可能会发现，目前开发的一些函数是:

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

在这种情况下，主干应该包含任何当前的开发工作，但是在下一个发行版之前定义的发行版分支可以作为 整合科，其中只有合适的代码(为下一个发行版验证)被合并，然后在同源阶段固定，最后在进入生产阶段时冻结。

当涉及到生产代码时，您还需要管理您的 修补树枝，同时记住:

  • 第一组补丁实际上可能在首次发布到生产环境之前就已经开始了(这意味着您知道您将带着一些无法及时修复的 bug 进入生产环境，但是您可以在一个单独的分支中启动这些 bug 的工作)
  • 其它补丁分支机构将有机会从一个定义明确的生产标签开始

当涉及到开发分支时，您可以有一个主干，除非您有其他开发工作需要使 并行如下:

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

现在，如果您的开发-发布周期是非常连续的，那么您可以按照其他答案的建议进行: 一个主干和几个发布分支。这种方法适用于小型项目，在这些项目中，所有的开发都会进入下一个版本，并且可以被冻结，作为发布分支的起点，在这些分支中可以进行补丁。这是一个名义上的过程，但是一旦你有了一个更复杂的项目... ... 这就不够了。

回答维尔 · M 的评论:

  • 请记住，开发分支并不意味着“每个开发人员一个分支”(这将触发“合并疯狂”，因为每个开发人员将不得不合并其他人的工作来查看/获取他们的工作) ，而是每个开发工作一个开发分支。
  • 当这些努力需要合并回主干(或任何其他“主”或发布分支你定义) ，这是开发人员的工作，没有-我重复，不-SC 经理(谁不知道如何解决任何冲突的合并)。项目负责人可以监督合并，这意味着要确保合并按时开始/完成。
  • 不管你选谁来合并，最重要的是:
    • 拥有单元测试和/或程序集环境，您可以在其中部署/测试合并的结果。
    • 定义了一个标签 在此之前作为合并的开始，以便能够回到以前的状态，如果说合并证明自己太复杂或相当长的解决。
小开

不管怎样，我们就是这么做的。

大多数开发是在主干中执行的，尽管实验性的特性或者可能会严重破坏系统的东西往往会有自己的分支。这样做效果非常好，因为这意味着每个开发人员总是在他们的工作副本中拥有所有内容的最新版本。

这确实意味着保持主干在模糊的工作状态很重要，因为完全有可能完全打破它。在实践中，这种情况并不经常发生，也很少是一个重大问题。

对于一个生产版本，我们分支主干，停止添加新特性，并致力于修正错误和测试分支(定期合并回主干) ，直到它准备好发布。在这一点上，我们做一个最后的合并到主干，以确保一切都在那里，然后释放。

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

我不认为这是一个完美的系统(它仍然有一些漏洞——我不认为我们的发布管理是一个足够严格的过程) ，但它工作得足够好。

小开

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

每个项目，或者在某些情况下其他单元，都有自己的分支，从发布开始就有了分支。

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

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

在合并完成之后发现问题之前，流程基本上是正常的。如果一个 WP 在被合并之后被“卡住”，那么它会保持合并之后的所有内容，直到它被修复(在被卡住的版本被释放之前，我们不能进行下一次发布)。

它还具有一定的灵活性——如果发布的时间非常短(比如1-2天左右) ，那么一个非常微小的更改可能会直接发生在发布分支上。

如果由于某种原因(一个关键的影响客户的生产问题，需要立即修复代码更改)而将更改直接放到生产环境中，那么这些更改将被放回 BRANCH _ RELEASE 中。这种事很少发生。

小开

哦，是的——还有一件事——我们在 cvs HEAD 中保留非生产代码(即永远不会发布的代码，例如工具脚本、测试实用程序)。通常它需要被清楚地标记，以便没有“意外”释放它。

小开

我们使用:

  • 专责发展部

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

  • 释放分支

发布分支中没有新的特性。只有重要的 bug 在发布分支中被修复，修复这些 bug 的代码被重新集成到开发分支中。

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

偶尔，我们也会为单个开发人员设立分支，从事一项新的未经验证的技术，或者创建一个概念验证。但是通常只有当更改影响到代码库的许多部分时才会这样做。这种情况平均每3-4个月发生一次，这样的分支通常在一两个月内重新整合(或报废)。

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

关于提前登记的问题:

如果只需要签入 完美的密码，那么实际上不应该签入任何内容。没有代码是完美的，QA 需要在开发分支中对其进行验证和测试，这样才能构建新的可执行文件。

对我们来说，这意味着一旦一个特性完成并被开发人员测试，它就会被签入。如果存在已知的(非致命的) bug，它甚至可以被检入，但是在这种情况下，受到 bug 影响的人通常会被告知。还可以检入不完整和正在处理的代码，但前提是它不会造成任何明显的负面影响，比如崩溃或破坏现有功能。

不时地，一个不可避免的联合代码和数据检查将使程序无法使用，直到新的代码已经建立。我们至少要在签入注释和/或发送电子邮件中添加一个“ WAITFORBUILD”。

小开

分支上的开发代码，主干上标记的实时代码。

不需要有一个“只提交完美代码”的规则——开发人员遗漏的任何东西都应该从四个方面着手: 代码评审、分支测试、回归测试测试、最终的 QA 测试。

下面是一个更详细的逐步解释:

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

我们开发的树干，然后分支每两周，并投入生产。只有重要的错误是固定在分支，其余可以等待另外两个星期。

对于主干，惟一的规则是提交不应破坏任何内容。为了管理 wip-code 和未测试的代码，我们只需添加适当的 if 语句，以便于打开和关闭。

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

小开

这取决于项目。我们的 web 代码是非常一致地签入的，而我们的应用程序代码只有在编译时才被签入。我注意到这和我们释放东西的方式非常相似。当应用程序面临严峻的最后期限时，Web 内容会随时上升。不过，我没有看到任何一种方法的质量下降。

小开

为什么没人提起这件事。

这是我的终极分支模型！

如果你的项目很小，不要一直使用所有不同的分支(也许你可以跳过小特性的特性分支)。除此之外，这才是正确的做法！

branching model


提交答案