这里的帖子（How do you manage database revisions on a medium sized project with branches?）让我想知道如何使用分支和部署到开发，登台和制作（以及本地副本）来最好地处理Web项目。
我们本身没有“发布”：如果某个功能足够醒目，我们会将其推送（在必要的测试/等之后），否则我们会批量处理，当感觉“舒服”时“，推动那些活着。我们的目标是永远不会每月进行一次或两次以上的部署，因为不断变化的网站往往会让用户感到有点不安。
这是我们如何做到这一点，它感觉有点脆弱（目前使用svn但考虑转换为git）：
现在，其中一些步骤有很大的复杂性，手动挥手，实际上很难做到（TRUNK - ＆gt; DEV总是打破）所以我不得不想象有更好的方法。
思想？
答案 0 :(得分：2)
如果您希望工作不能按时完成，并且您没有足够的测试来进行持续集成工作，则分支很方便。我倾向于在商店中看到分支疯狂的开发，其中编程任务太大而无法预测完成，因此管理层希望等到发布之前才确定应该发布哪些功能。如果你正在做这样的工作，那么你可以考虑使用分布式版本控制，其中每个工作目录自然是一个分支，你可以获得所有本地签到和本地历史，你可以吃而不会伤害任何人。您甚至可以与主干之外的其他开发人员交叉合并。
我的偏好是当我们在一个不稳定的主干中工作时，它有分支用于释放候选者，然后标记为释放，然后成为紧急补丁的流。在这样的系统中，你很少有三个以上的分支（最后发布，当前发布候选，不稳定主干）。如果您正在进行TDD并且在不稳定的主干上有CI，则此方法有效。如果您需要分解所有任务，那么您可以根据需要随时交付代码（通常任务应该只需要一到两天，并且可以在没有构成其功能的所有其他任务的情况下发布）。因此，程序员可以在所有测试通过的任何时候开始工作，检查主干，完成工作，同步和检查。不稳定的主干总是可以作为发布候选者进行分支（如果所有测试都通过），因此释放变为非事件。
总的来说，更好的意思是：更少的分支，更短的任务，更短的发布时间，更多的测试。
答案 1 :(得分：1)
一个明显的想法是更多“rebase”（更频繁地从“父”环境STAGE合并回“子”环境“DEV”到开发者分支），以便最小化TRUNK-＆gt; DEV的最终影响，将不再需要了。
即，在STAGE中完成的任何事情，一定要一次投入生产（TRUNK）应该尽早在DEV和私人开发分支中合并，否则那些后期改造合并总是很痛苦。
但是，上面的合并工作流程太不方便了，我会建议一个REBASE分支，基于发布后的最新DEV（新TRUNK）。 rebase TRUNK-＆gt; DEV将变为TRUNK-＆gt; REBASE，其中所有问题都得到解决，然后最终合并DEV-＆gt; REBASE以检查任何当前dev是否与新更新的系统兼容。从REBASE到DEV（以及私人开发分支机构）的最终琐碎合并将完成该过程 分支的重点是隔离不能与其他当前开发工作一起进行的开发工作。如果TRUNK-＆gt; DEV太复杂而无法与当前DEV一起使用，则需要将其隔离。因此'REBASE'分支主张。
答案 2 :(得分：1)
答案 3 :(得分：0)
我们在我工作的商店使用SVN。虽然我们进行C ++开发，但版本管理非常普遍。以下是我们的方法，您可以决定什么，如果有的话，对您的方法是合理的。
对我们来说，所有开发都发生在分支机构中。我们为每个bug和每个功能分支。理想情况下，该分支仅用于1个功能，但有时这并不意味着。
当工作完成，测试并“准备好”时，我们将更改合并到主干中。我们的规则是，干线在任何时候都不应该破坏代码。如果损坏的代码应该进入主干，修复它将成为优先级1.
在功能全部完成并合并时进行发布：创建发布的分支和标记一样。标签允许我们在需要时检索shapshot。该分支允许我们以前的版本支持。修复已发布版本中的错误是通过转到该版本的分支来完成的。当一切顺利时，更改将合并回发行版的分支，并且如果需要，将一直合并到主干。