svn - 源代码管理策略 - 分支、标记、 fork 等 - 适用于 Web 应用程序

Question

这篇文章 ( How do you manage database revisions on a medium sized project with branches?) 让我想知道如何使用分支和部署到开发、暂存和生产(以及本地副本)来最好地处理 Web 项目。

我们本身没有“发布”:如果一个功能大到足以引起注意，我们就会将其发布(在必要的测试等之后)，否则我们会分批发布一些，当它感觉“舒适”时”，推那些直播。我们的目标是每月部署一次或两次以上，因为不断变化的站点往往会让用户感到有些不安。

这是我们的做法，感觉有点脆弱(目前使用 svn 但正在考虑切换到 git):

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

现在，这些步骤中的一些步骤非常复杂，无需手动操作，而且在实践中很难做到(TRUNK -> DEV 总是中断)所以我不得不想象有更好的方法。

想法？

Answer 1

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

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

总的来说，更好意味着:更少的分支、更短的任务、更短的发布时间、更多的测试。