我的开发环境：Windows 7、TortoiseHg、ASP.NET 4.0/MVC3
测试分支：测试服务器上的代码 Prod 分支：生产服务器上的代码
这是我当前的分支模型。分支出每个任务（功能）的原因是因为某些功能的运行速度较慢。所以在上图中，任务 1 较早完成（变更集 #5），并合并到测试分支进行测试。但是，由于原始请求的错误或修改，已进行了变更集 #10、#12。虽然任务 2 已经完成了 #8 的测试并已推送到 live #9。
我的问题是每次修改任务分支（如#10、#12）时，我都必须再次合并到测试分支（#11、#13），这使得图表非常混乱。
有什么办法可以解决这个问题吗？还是有更好的分支模型？
【问题讨论】：
听起来您确实在尝试实施功能分支策略。但是，根据您的图表，我认为您缺少一些步骤和/或正在合并错误的分支。从本质上讲，您可能应该有更多的 4 行开发，加上 1 代表所有功能分支。不幸的是，除了一个谈论 Git 和一个可行的分支策略here 之外，我还没有找到一个好的图表。不过，即使您使用的是不同的 DVCS，例如 Mercurial（我的最爱），该图也能更好地解释您要查找的内容。使用 Steve Losh 的 Guide to Branching in Mercurial 和 Hg Book，您应该能够实施适合您的良好功能分支策略。 Steve 对每种方法都有优点/缺点。
而且，不，您不需要克隆以正确分支。如果您经常处理多个未完成的项目和/或为其他开发人员执行代码审查/测试，Mercurial 已命名分支，使您可以轻松地在分支之间切换。使用 IIS 进行任何类型的基于 Web 的开发时，命名分支更易于使用，因为事物不会移动，并且不同版本可以继续在 IIS 下使用相同的配置。
不过，我必须说，功能分支或您给它起的任何名称几乎总是一个坏主意，因为运行时间过长的分支（例如，一年，我已经看到了灾难性的结果）几乎不可能合并除非您经常（每天）管理功能分支与其父级之间的同步，否则请返回。这种类型的维护开销不值得麻烦，您最好坚持基于主干的开发，使用发布分支进行错误修复，并将您的代码修复为生产使用和未完成工作的抽象代码。
【讨论】：
当您想开发新功能时，最好从测试存储库中克隆。 mercurial 中的分支应该保持不相关......想象一下，您发布了 v1.0 并准备在应用程序的 v2.0 上工作（默认分支）。您将创建分支 v1.0 以通过错误修复对其进行更新。
【讨论】：
您可以改为为每个分支使用单独的存储库。然后根据最新的变更集重新调整更改。这可以减少合并次数。
【讨论】：