源代码控制分支的不同方法答案

【问题标题】：Different approaches to source control branching源代码控制分支的不同方法
【发布时间】：2009-08-26 06:41:47
【问题描述】：

在使用源代码控制时，我习惯的工作方式是在主干上进行开发，然后在进入 QA 之前分支主干。

我正在与部门中的其他一些人交谈，显然对不同的工作方式有一些热情的看法，那就是在开发周期的一开始就创建新分支，在该分支上进行开发工作，然后在最后将其合并回主干。这种方法的想法是保持树干的原始状态。

虽然我对一位支持者声称后一种方法是“标准”方法的说法高度怀疑（尽管很高兴被告知并非如此），但听到它相当普遍，我不会感到惊讶。我可以想象这样做的一些好处（更容易挑选和选择何时部署哪个功能或一组功能）但也有一些缺点（潜在的合并问题，因为每个分支都必须合并回主干）。

很想听听人们对这些方法的相对优缺点的看法，以及人们可能正在使用的任何其他方法。

【问题讨论】：

【解决方案1】：

这是一个与之前的 SO 项目非常相似的问题：

不完全相同，但回复中的很多概念是相同的。

我的个人意见？主干用于积极开发；您希望保持“原始”的旧版本的开发线应保存在版本分支（和发布标签）中。即使在主干上进行积极开发，您仍然可以尝试保持“主干应始终编译”的格言。

【讨论】：

【解决方案2】：

如果有一个团队从事相同的工作，那么在主干中工作并在发布之前创建一个分支是一种很好的方法。您将合并地狱最小化，并且如果您必须打补丁或出于某种原因返回，则每个版本都有一个不同的分支。

但是，当与多个团队一起做不同的事情时，这是行不通的，因为他们肯定会在后备箱中发生冲突。我对此没有太多经验，所以我期待着一些想法。一种方法是拥有多个分支，也许每个团队一个分支，然后合并那些进入主干发布的分支。（我只能想象那种挫败感）:)

【讨论】：

【解决方案3】：

我喜欢保持行李箱清洁。这允许随时编译一个工作版本，发布一个修复，一个测试版，创建一个演示版本......

更改是在单独的分支上完成的。这提供了更好的可追溯性，并且可以利用分支上的源代码控制并签入临时版本。在理想的世界中，合并问题由 [自动] 测试覆盖。越早将更改集成到主干中越好。

不要将未经测试的代码放在主干上，因为这最终会减慢某人的速度。

【讨论】：