源代码管理策略 - 分支、标记、分叉等。- 对于网络应用程序

StackOverflow https://stackoverflow.com/questions/156120

题

这篇文章在这里（如何管理具有分支机构的中型项目的数据库修订？）让我想知道如何最好地使用分支和部署到开发、登台和生产（以及本地副本）来处理 Web 项目。

我们本身没有“发布”：如果某个功能足够大而引人注目，我们就会将其上线（经过必要的测试等），否则我们会批量处理一些功能，当感觉“舒服”时，就会将其上线。我们的目标是每月部署一次或两次以上，因为不断变化的站点往往会让用户感到有点不安。

我们是这样做的，感觉有点脆弱（目前使用 svn 但考虑切换到 git）：

  1. 两个“分支” - DEV 和 STAGE，其中给定的 STAGE 版本标记为 TRUNK
    • 开发人员检查每次更改的 TRUNK 副本并为其创建一个分支
    • 开发人员在本地工作，经常检查代码（就像投票一样：早且经常）
    • 当开发人员觉得它没有完全损坏时，将分支与 DEV 合并并部署到开发站点。
    • 根据需要重复 3-4，直到更改“完成”
    • 将更改分支与 STAGING 合并，部署到暂存站点。进行预期的最终测试。
    • 一段时间后，将 STAGE 的给定修订版标记为 TRUNK，并实时推送 trunk
    • 合并 TRUNK 更改回 DEV 以保持同步

现在，其中一些步骤具有显着的复杂性，并且在实践中很难做到（TRUNK -> DEV 总是中断），所以我必须想象有更好的方法。

想法？

有帮助吗？

解决方案

如果您预计工作不会按时完成，并且您没有足够的测试来进行持续集成，那么分支会很方便。我倾向于在商店中看到分支疯狂的开发，其中编程任务太大而无法以可预测的方式完成，因此管理层希望等到发布之前才确定应该发布哪些功能。如果您正在进行此类工作，那么您可能会考虑使用分布式版本控制，其中每个工作目录自然都是一个分支，并且您可以获得所有本地签入和本地历史记录，而不会伤害任何人。您甚至可以与主干之外的其他开发人员交叉合并。

我的偏好是，当我们在一个不稳定的主干中工作时，其中的分支用于发布候选版本，然后将其标记为发布，然后成为紧急补丁的流。在这样的系统中，很少有超过三个分支（最后一个版本、当前候选版本、不稳定的主干）。如果您正在执行 TDD 并在不稳定的主干上使用 CI，则此方法有效。如果您需要分解所有任务，以便可以根据需要多次交付代码（通常一个任务应该只有一到两天，并且可以在没有组成其功能的所有其他任务的情况下发布）。因此，程序员开始工作，检查主干，完成工作，同步并在所有测试通过时随时检查。不稳定的主干始终可作为候选版本进行分支（如果所有测试都通过），因此发布不会发生。

总的来说，更好的意思是：更少的分支，更短的任务，更短的发布时间，更多的测试。

其他提示

一个明显的想法是更加“rebase”（更频繁地从“父”环境 STAGE 合并回“子”环境“DEV”再到开发人员分支），以尽量减少 TRUNK->DEV 的最终影响，这是不需要的不再了。

也就是说，在 STAGE 中完成的任何事情，必然会一次投入生产（TRUNK），应该尽早合并回 DEV 和私有开发分支，否则那些后期的改造合并总是很痛苦。

但是，如果上面的合并工作流程太不方便，我建议使用 REBASE 分支，基于发布后的最新 DEV（新 TRUNK）。rebase TRUNK->DEV 将变为 TRUNK->REBASE，所有问题都得到解决，然后最终合并 DEV->REBASE 以检查任何当前的 dev 是否​​与新更新的系统兼容。最后从 REBASE 到 DEV（以及私有开发分支）的简单合并将完成该过程。
分支的目的是隔离不能与其他当前开发工作一起进行的开发工作。如果TRUNK->DEV过于复杂，无法与当前的DEV兼容，则需要将其隔离。因此出现了“REBASE”分支命题。

我们在我工作的商店里使用SVN。当我们进行 C++ 开发时，版本管理非常普遍。以下是我们的方法，您可以决定什么（如果有的话）对您的方法来说是合理的。

对于我们来说，所有的开发都发生在一个分支中。我们针对每个错误和每个功能进行分支。理想情况下，该分支仅致力于 1 个功能，但有时并非如此。

当工作完成、测试并“准备好”后，我们将更改合并到主干中。我们的规则是行李箱中任何时候都不应该有损坏的代码。如果损坏的代码进入了主干，修复它就成为第一要务。

当功能全部完成并合并时发布：发布的分支按标签形式创建。如果需要，该标签允许我们检索快照。该分支允许我们支持以前的版本。修复已发布版本中的错误是通过转到该版本的分支并从中分支来完成的。当一切顺利时，更改将合并回发布的分支，如果需要，还会一直合并到主干。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top