2

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

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

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

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

现在，其中一些步骤非常复杂，而且在实践中很难做到（TRUNK -> DEV 总是中断），所以我不得不想象有更好的方法。

想法？

4

4 回答 4

2

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

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

总体而言，更好意味着：更少的分支、更短的任务、更短的发布时间、更多的测试。

于 2008-10-01T19:21:08.743 回答
1

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

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

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

于 2008-10-01T04:20:23.540 回答
1

阅读：http: //oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

于 2009-04-15T23:51:14.487 回答
0

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

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

当工作完成、测试并“准备好”时，我们将更改合并到主干中。我们的规则是，在任何时候，主干都不应该有损坏的代码。如果损坏的代码应该进入主干，修复它成为优先级 1。

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

于 2008-10-01T04:26:47.427 回答