此处的这篇文章(如何管理具有分支的中型项目的数据库修订？)使我想知道如何最好地使用分支并将其部署到开发，暂存和生产(以及本地副本)来处理Web项目。

我们本身没有"发布"：如果某个功能足够大到足以引起注意，则将其实时发布(在进行必要的测试等之后)，否则我们将其批量发布，并在感到"舒适"时进行推送那些活着。目标是每月进行一次或者两次以上部署，因为不断变化的站点往往会使用户感到不安。

这是我们的操作方式，感觉有点脆弱(当前使用svn，但考虑切换到git)：

• 开发人员在本地工作，经常签入代码(就像投票一样：尽早而频繁)
• 当开发人员感到满意时，它并没有完全损坏，请将分支与DEV合并并部署到开发站点。
• 根据需要重复3-4，直到"完成"更改
• 将变更分支与STAGING合并，部署到登台站点。做预期的最终测试。
• 一段时间后，将STAGE的给定版本标记为TRUNK，然后将后备箱推入
• 合并TRUNK更改回DEV以使其保持同步

现在，这些步骤中的某些步骤已被大量浪费，实际上很难做到(TRUNK-> DEV总是中断)，所以我必须想象有更好的方法。

有什么想法吗？

解决方案

为了减少TRUNK-> DEV的最终影响，一个明显的想法是更多的"重新设置"(从"父"环境STAGE到"子"环境" DEV"到开发人员分支的合并更多)不再。

也就是说，在STAGE中完成的所有必须一次投入生产(TRUNK)的操作都应尽早在DEV和private devs分支中合并，否则后期进行的合并总是很麻烦。

但是，如果上述合并工作流程太不方便，我建议在发布(新的TRUNK)之后基于最新的DEV创建一个REBASE分支。重新设置基础TRUNK-> DEV将变为TRUNK-> REBASE，在此解决了所有问题，然后进行最终合并DEV-> REBASE，以检查当前任何开发者是否与新的更新系统兼容。从REBASE到DEV(以及私有dev分支)的最后一次微不足道的合并将完成该过程。
分支机构的目的是隔离无法与其他当前开发工作一起进行的开发工作。如果TRUNK-> DEV太复杂而无法与当前DEV一起使用，则需要将其隔离。因此，" REBASE"分支命题。

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

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

当工作完成，经过测试并"准备就绪"时，我们会将更改合并到主干中。我们的规则是，中继线绝对不要在其中破损代码。如果发现破损的代码进入主干，则修复它成为优先级1.

当所有功能都完成并合并后就发布了版本：创建了发布的分支以及标签。标签可让我们根据需要检索快照。该分支允许我们提供以前的版本支持。要修复已发布版本中的错误，请转到该版本的分支，从该分支开始进行分支。当一切顺利时，更改将合并回发行版的分支，并在需要时一直合并到主干。

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

我的偏好是当我们在不稳定的主干中工作时，其分支中有一些候选发布版本，然后将这些分支标记为要发布，然后成为紧急补丁的流。在这样的系统中，很少会有三个以上的分支(最新发行版，当前发行候选版，不稳定主干)。如果我们正在执行TDD且不稳定中继上具有CI，则此方法有效。而且，如果我们需要分解所有任务，以便可以按需交付代码(通常，任务应该只有一到两天，并且可以在没有构成其功能的所有其他任务的情况下发布)。因此，程序员可以在所有测试通过后随时进行工作，签出主干，进行工作，同步并签入。不稳定的主干总是可以作为释放候选者分支(如果所有测试都通过了)，因此释放成为非事件。

总体而言，更好的方法是：减少分支，缩短任务，缩短发布时间，进行更多测试。

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