使用源代码控制时，我习惯使用的方法是在主干上进行开发，然后在进入QA之前对主干进行分支。
我正在与部门中的其他人交谈，显然对于不同的工作方式有一些激情的看法，即在开发周期的最初阶段创建新的分支，在该分支上进行开发工作，然后在最后将它合并回主干。这种方法的想法是保持树干原始。
虽然我对一个支持者声称后一种方法是“标准”方法（尽管很高兴另有说法）的说法高度持怀疑态度，但听到这种方法相当普遍，我也不会感到惊讶。我可以想象一些好处（更容易选择何时部署哪个功能或一组功能），但也有一些缺点（潜在的合并问题，因为每个分支必须合并回主干）。
进行了一些后续研究并发现了这一点：http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx
很想听听人们对这些方法的相对优势和劣势的看法，以及人们可能正在使用的任何其他方法。
答案 0 :(得分：2)
这与之前的SO项目非常相似：
Subversion - should anyone be developing off the trunk?
不完全相同，但答案中的很多概念是相同的。
我的个人意见？主干用于积极发展;您希望保留“原始”的旧版本的开发行应该保存在版本分支（以及版本的标记）中。即使主动开发在主干上，你仍然可以尝试维护“主干应该始终编译”的格言。
答案 1 :(得分：2)
有一个团队在处理相同的事情，这是一个非常好的方法在中继工作，并在发布之前创建一个分支。你最小化merge-hell，如果你必须做一个补丁，或者由于某种原因回去，你就会为每个版本分别设置一个分支。
但是，当与多个团队合作做单独的事情时，这将无法工作，因为他们肯定会在后备箱中发生碰撞。我没有太多关于此的经验，所以我期待着围绕这一点的一些想法。一种方法是拥有多个分支，或许每个团队一个分支，然后合并那些进入发布的分支。 （我只能想象挫折）:)）
答案 2 :(得分：2)
我赞成保持行李箱干净。这允许随时编译工作版本，发布修复版，测试版，创建演示版......
对分离的分支进行更改。这提供了更好的可追溯性，并且可以利用分支上的源控制并检入临时版本。在理想的世界中，合并问题由[自动]测试涵盖。您越早将更改集成到主干中越好。
不要将未经测试的代码放在主干上，因为这最终会减慢某人的速度。