这里的这篇文章（如何在带有分支的中型项目上管理数据库修订？）让我想知道如何最好地使用分支和部署到开发、暂存和生产（以及本地副本）来处理web项目。
我们本身没有"发布"：如果一个功能足够大，可以引起注意，我们会实时推送（在必要的测试等之后），否则我们会批量推送一些，当感觉"舒服"时，就会实时推送。我们的目标是每月部署一到两次，因为不断变化的网站往往会让用户有点不安。
以下是我们的操作方法，感觉有点脆弱（目前使用svn，但考虑改用git）：
- 两个"分支"-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和私有开发部门合并回来，否则那些后期改造的合并总是很痛苦的。
但是，如果上面的合并工作流程太不方便，我建议在发布后基于最新的DEV（新的TRUNK）建立一个REBASE分支。重新基础TRUNK->DEV将变成TRUNK->rebase，在那里所有问题都得到了解决，然后最后合并DEV->rebase，以检查任何当前的开发是否与新更新的系统兼容。从REBASE到DEV（以及到私有开发分支）的最后一个微不足道的合并将完成这个过程
分支的目的是隔离无法与当前其他开发工作一起进行的开发工作。如果TRUNK->DEV过于复杂，无法与当前的DEV配合使用，则需要将其隔离。因此提出了"REBASE"分支命题。
请阅读：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
我们在我工作的商店里使用SVN。当我们进行C++开发时，版本管理是非常通用的。以下是我们的方法，您可以决定什么（如果有的话）对您的方法是合理的。
对我们来说，所有的发展都发生在一个分支中。我们针对每一个bug和每一个功能进行分支。理想情况下，该分支只致力于一个功能，但有时这并不意味着。
当工作完成、测试并"准备就绪"时，我们将更改合并到主干中。我们的规则是，在任何时候，主干都不应该有损坏的代码。如果损坏的代码进入主干，修复它就成为首要任务。
发布是在功能全部完成并合并后进行的：发布的分支将作为标记创建。标记允许我们在需要时检索shapshot。分支允许我们支持以前的版本。修复已发布版本中的错误是通过转到该版本的分支，从中进行分支来完成的。当一切顺利时，更改将合并回该发布的分支，如果需要，则一直合并到主干。