你如何维护开发代码和生产代码？
维护代码时遵循的最佳实践和规则是什么？ 在开发分支中只有生产就绪代码是好的做法，还是应该在开发分支中提供未经testing的最新代码？
你们如何维护你的开发代码和生产代码？
编辑 – 补充问题 – 您的开发团队是否遵循了“尽可能快地提交”，即使是“即使是包含小错误或不完整”协议或“提交 – ONLY-perfect-code“协议，同时向开发分支提交代码？
这一切都取决于您的发布pipe理的顺序性质
首先， 真的是你的箱子里的一切， 为下一个版本 ？ 您可能会发现，目前开发的一些function是：
- 太复杂，还需要提炼
- 没有及时准备好
- 有趣，但不是为了这个下一个版本
在这种情况下，trunk应该包含任何当前的开发工作，但是在下一个版本之前早期定义的发布分支可以用作合并分支 ，其中只有合适的代码（对下一版本进行validation）被合并，然后在authentication阶段被修复，并在生产过程中最终冻结。
当涉及到生产代码时，您还需要pipe理您的补丁分支 ，同时牢记：
- 第一套补丁程序可能实际上是在第一次发布到生产环境之前开始的（也就是说，你知道你将会投入一些你不能及时修复的bug，但是你可以在一个单独的分支中启动这些补丁程序）
- 其他补丁分支将有一个明确的生产标签开始的奢侈品
当涉及到开发分支，你可以有一个主干，除非你有其他的开发努力，你需要做平行如：
- 大规模的重构
- testing一个新的技术库，这可能会改变你在其他类中调用事物的方式
- 开始一个新的发布周期，其中重要的架构变化需要被合并。
现在，如果你的开发周期是非常连续的，你可以按照其他答案的build议：一个主干和几个发布分支。 这对小型项目是有效的，所有的开发工作肯定会进入下一个版本，并且可以被冻结，并成为发布补丁的起点，补丁可以发生。 这是名义上的过程，但只要你有一个更复杂的项目…这是不够的。
要回答Ville M.的评论：
- 请记住，开发分支不意味着“每个开发人员一个分支”（这将触发“合并疯狂”，因为每个开发人员必须合并其他人的工作才能看到/得到他们的工作），而是每个开发人员一个开发分支努力。
- 当需要将这些努力合并回主干（或者你定义的任何其他“主”或发布分支）时，这是开发者的工作， 而不是 – 我再说一遍，不是 – SCpipe理者（谁不知道如何解决任何冲突的合并）。 项目负责人可以监督合并，意思是确保按时开始/完成。
- 无论你select谁来合并，最重要的是：
- 有可以部署/testing合并结果的unit testing和/或组装环境。
- 在合并开始之前已经定义了一个标签，以便如果所述合并certificate自己太复杂或者需要很长的时间才能够回到之前的状态。
我们用：
- 开发部门独家
直到项目接近完成，或者我们正在创build一个里程碑版本（例如，产品演示，演示版本），然后我们（定期）将我们目前的开发分支分支到：
- 发布分支
没有新function进入发布分支。 只有重要的bug在发布分支中被修复，并且修复这些bug的代码被重新集成到开发分支中。
这个由开发和稳定（发布）分支组成的分两部分的过程使我们的生活变得更加容易，我不相信我们可以通过引入更多的分支来改进它的任何部分。 每个分支也有自己的构build过程，这意味着每隔几分钟就会产生一个新的构build过程，所以在代码签入之后，我们在大约半个小时内就有了所有构build版本和分支的新可执行文件。
有时我们也有单独的开发人员从事新的和未经证实的技术工作，或创build一个概念certificate。 但通常只有在更改影响到代码库的很多部分时才这样做。 这种情况平均每3-4个月发生一次，而这样一个分支通常会在一两个月内重新整合（或报废）。
一般来说，我不喜欢每个在自己的分支工作的开发人员的想法，因为你“跳过直接移动到集成地狱”。 我强烈build议不要这样做。 如果你有一个共同的代码库，你应该一起工作。 这使得开发人员对签入更加谨慎，而且每位编码人员都有经验知道哪些更改可能会破坏构build，因此在这种情况下testing更为严格。
在签入早期的问题：
如果您只需要检查PERFECT CODE ，那么实际上什么都不应该检入。没有代码是完美的，为了QAvalidation和testing，它需要在开发分支中，因此可以build立一个新的可执行文件。
对于我们来说，这意味着一旦某个function完成并由开发人员进行testing，它将被检入。甚至可以检查是否存在已知的（非致命的）错误，但是在这种情况下，受到该错误影响的人是通常通知。 不完整的工作进行中的代码也可以检查，但只有在它不会造成任何明显的负面影响，如崩溃或破坏现有的function。
无论如何，不可避免的组合代码和数据签入将使程序无法使用，直到新的代码被build立。 我们所做的至less是在签入评论中添加“等待build设”和/或发送电子邮件。
为了什么是值得的，这是我们如何做到的。
大多数的开发是在树干中进行的，尽pipe实验性的function或者可能会破坏系统的东西显然倾向于获得自己的分支。 这样做很好，因为这意味着每个开发人员在其工作副本中始终拥有最新的版本。
这确实意味着保持行李处于非常有效的状态是非常重要的，因为完全可以将其完全打破。 在实践中不经常发生，并且很less是一个重大的问题。
对于产品发行版，我们分支主干，停止添加新function，并在错误修复和testing分支（定期合并回主干）上工作，直到准备好发布。 在这一点上，我们做一个最后的合并到主干，以确保一切都在那里，然后释放。
然后可以根据需要在发布分支上执行维护，这些修复可以很容易地合并回主干。
我不认为这是一个完美的系统（它仍然有一些漏洞 – 我不认为我们的发布pipe理是一个足够紧密的过程呢），但它运作得很好。
为什么还没有人提到这个？ http://nvie.com/posts/a-successful-git-branching-model/
这对我来说是最终的分支模式！
如果你的项目很小，不要一直使用所有不同的分支（也许你可以跳过小function的function分支）。 但是，否则，这是做的方法！
在分支上的开发代码，在Trunk上标记的实时代码。
没有必要成为一个“只提交完美的代码”的规则 – 任何开发者错失的东西都应该在四个地方find：代码审查，分支testing，回归testing和最终的质量保证testing。
以下是一个更详细的分步说明：
- 做一个分支的所有发展，定期承诺。
- 独立代码审查一旦所有的开发完成后的变化。
- 然后将分支传递给Testing。
- 分支testing完成后，将代码合并到Release Candidate分支中。
- 发布候选分支在每次合并之后进行回归testing。
- 所有开发分支合并后，在RC上进行的最终QA和UAtesting。
- 一旦QA和UAT通过，将发布分支合并到MAIN / TRUNK分支。
- 最后，在这一点上标记中继，并将该标记部署到Live。
dev进入主干（svn风格），并释放（生产代码）得到自己的分支机构
这是“分支模式”（ 分支模型 /！\ pdf 的重要性中的图3）
我们将生产代码（主干）与开发代码（每个开发人员都有自己的分支）完全分开来解决这个问题。
生产代码在被彻底检查之前（质量保证和代码审查人员）不得进入代码。
这种方式不会混淆哪些代码工作，它总是主要的分支。
我使用混帐，我有2个分支： 主和主要
- 掌握 – 开发代码
- 生产代码
当我将代码发布到生产环境时，我将其标记并将主人合并到maint分支。 我总是从maint分支部署。 开发分支的修补程序我select他们支持分支和部署补丁。
哦，是的 – 另一件事 – 我们保留在CVS HEAD非生产代码（即永远不会被释放 – 例如工具脚本，testing工具）。 通常需要明确标记，以免“意外”发布。
我们在干线上发展，然后每两周分支并投入生产。 只有重要的bug在分支中被修复，其余的可以再等两个星期。
对于主干，唯一的规则是提交不应该破坏任何东西。 要pipe理wip代码和未经testing的代码，我们只需添加适当的语句以便轻松切换即可。
基本上可以随时分支干，投入生产。
我们有一个“发布”分支，其中包含目前正在生产的产品或即将部署的产品（已经通过了大多数质量保证）
每个项目，或在某些情况下，其他单位，都有自己的分支，从分支分支。
项目中的开发人员将变更提交到项目自己的分支中。 定期地，版本被合并回开发分支。
一旦分支机构的工作包都进行了质量检查（unit testing，系统testing，代码审查，质量保证审查等），分支就被合并到发布分支中。 新版本是从发布版本构build的，最终validation发生在该版本上。
这个过程基本上是确定的，直到合并完成后发现问题。 如果一个WP在被合并之后被“卡住”，它会阻止它后面的所有东西，直到它被修复（我们不能在被释放之前再次发布）。
它也有一定的灵活性 – 如果发行版在很短的时间内（如1-2天左右）发布，发行版上可能会发生一些微不足道的变化。
如果由于某种原因直接将生产中的变更（生产关键客户的生产问题需要立即修改代码），那么这些变更将被放回到BRANCH_RELEASE中。 那几乎没有发生过。
这取决于项目。 我们的网页代码是相当一致的检查，而我们的应用程序代码只有在编译时检查。 我注意到这和我们发布的东西非常相似。 Web应用程序在应用程序达到严格的最后期限的时候会随时上升。 两种方法的质量都没有下降。
