处理分支和合并的更好方法是什么？

Question

我们运营着一个网络开发商店,大约有20名开发人员在任何特定的时间在~30个不同的网站上工作,我们正在花费大量的时间来管理我们的subversion存储库 - 必须有更好的方法.

我们的客户站点通常有3个独立的部署环境:开发(主干),登台(分支)和生产(分支).

新功能在开发时在内部进行审核,然后与分段合并以进行客户审核和批准,最后合并到生产中.

我们当前的工作流程:为客户开发主要新功能的每个开发人员都将从主干创建分支,处理其功能,同时定期从主干更新,然后将更改合并回主干(开发)以进行内部审核.处理微小更改或修复的开发人员将直接在主干中进行操作.

内部注销后,更改将合并到暂存.如果需要进行更改,通常会在trunk中进行更改,然后合并到staging.获得批准后,更改将与生产合并,然后进行部署.

内部或客户端不会按顺序审查新功能,整个过程会变得相当混乱.我们似乎正在使用错误的流程 - 必须有更好的方法来实现这一目标.我们对学习如何更好地利用版本控制非常感兴趣,但我们缺乏启动过程的经验.

这些方案的最佳做法是什么？除了这个论坛,我们还有兴趣聘请经验丰富的顾问,他们可以帮助我们改进流程.

谢谢!

Answer 1

我认为按功能（或按团队）进行分支比按开发人员进行分支更好。在通过开发（主干）合并到暂存分支之前，可以测试和预览该功能。

我的团队有一个类似的“按质量/环境划分”结构，我花了几个月的时间研究如何最好地进行转换，以便开发人员共同努力，我们可以减少合并税。我建议如下：

• 发展（主干/主干/根分支）
  • (FeatureName1[Version]) - 替换每个开发人员的分支。
  • 暂存（如果您将所有版本保留在单个分支中）
  • 生产
  • (ReleaseName)(MajorVersion)Staging - 即使发布到相同的环境，我也倾向于隔离不同的版本
  • （发布名称）（版本）生产

暂存修复直接在暂存分支（如果 QA 和/或风险任务隔离，则为暂存分支的短期子分支）进行，然后在修复被接受后立即将修复合并回开发（主干）。注意：在暂存修复过程中，请密切注意开发中的任何合并。

从质量保证的角度来看，我强烈希望最终的分阶段和测试版本与发布到生产环境的相同二进制文件/文件相同。唯一的更改应该是配置文件（将不同的配置设置签入存储库）。这意味着我通常在“Staging”中进行最终构建，而“Production”或 ReleaseVersion 分支是一个无人构建的只读存档。（如果所述标签是不可变的，则可以使用标签或标记来代替此保管分支......但 TFS 2010 的情况并非如此:-(。)

请参阅 2011 年 2 月的Visual Studio TFS 分支和合并指南 MSDN 文章中的酷图。要扩展此功能，请参阅致力于开发中的多个版本的Scrum和并行功能团队的分支。每月发布到生产环境。。这两个都附带了一些适用于任何版本控制系统的优秀图表。

我还建议查看同一位置的TFS 分支指南和讨论论坛，以获取其他好的模式和指导。（分支方法在很大程度上独立于工具，但避免工具弱点时除外。）

我发现原始分支过程中至少有一个根本缺陷：

内部签核后，更改将合并到暂存中。如果需要进行更改，通常会在主干中进行更改，然后合并到暂存中。

如果在开发中对暂存进行了更改，然后再次合并到暂存，那么您刚刚继承了自上次合并到暂存以来对开发分支所做的所有其他更改。或者，如果您选择更改（留下所有其他更改稍后合并）。SCM 工具在处理这种情况方面越来越好，但选择性合并仍然会带来重大风险。

仅供参考：最初描述的模式类似于 Jeff Levinson 描述的“按质量分支”。它可以工作，但您必须仔细查看如何管理修补程序/qfe 分支并将更改合并回主干。