使用源代码控制时，我习惯的工作方式是在主干上进行开发，然后在进入 QA 之前分支主干。
我正在与部门中的其他一些人交谈，显然对不同的工作方式有一些热情的看法，那就是在开发周期的一开始就创建新分支，在该分支上进行开发工作，然后最后将其合并回主干。这种方法的想法是保持树干的原始状态。
虽然我对一位支持者声称后一种方法是“标准”方法的说法高度怀疑（尽管很高兴被告知不是这样），但听到它相当普遍，我不会感到惊讶。我可以想象这样做的一些好处（更容易选择和选择何时部署哪个功能或一组功能）但也有一些缺点（潜在的合并问题，因为每个分支都必须合并回主干）。
做了一些后续研究，发现了这个：http ://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx
很想听听人们对这些方法的相对优势和劣势的看法，以及人们可能正在使用的任何其他方法。
这是一个与之前的 SO 项目非常相似的问题：
不完全相同，但响应中的许多概念是相同的。
我的个人意见？主干用于积极开发；您希望保持“原始”的旧版本的开发线应保存在版本分支（和发布标签）中。即使在主干上进行积极开发，您仍然可以尝试维护“主干应始终编译”的格言。
一个团队在做同样的事情，在主干中工作并在发布之前创建一个分支是一种很好的方法。您将合并地狱最小化，并且如果您必须打补丁或出于某种原因返回，则每个版本都有一个不同的分支。
但是，当与多个团队一起做不同的事情时，这是行不通的，因为他们肯定会在后备箱中发生碰撞。我对此没有太多经验，所以我期待着一些想法。一种方法是拥有多个分支，也许每个团队一个分支，然后合并那些进入主干发布的分支。（我只能想象那种挫败感）:)
我赞成保持后备箱清洁。这允许随时编译工作版本、发布修复程序、测试版、创建演示版......
更改是在单独的分支上完成的。这提供了更好的可追溯性，并且可以利用分支上的源代码控制并签入临时版本。在理想的世界中，合并问题由 [自动] 测试覆盖。越早将更改集成到主干中越好。
不要将未经测试的代码放在主干上，因为这最终会减慢某人的速度。