我们经营一家网络开发商店，约有20名开发人员在任何特定时间在~30个不同的网站上工作，我们正在花费大量时间来管理我们的subversion存储库 - 必须有更好的方法。
我们的客户端站点通常有3个独立的部署环境：开发（主干），登台（分支）和生产（分支）。
新功能在开发时在内部进行审核，然后与分段合并以进行客户审核和批准，最后合并到生产中。
我们当前的工作流程：为客户端开发主要新功能的每个开发人员都将从主干创建分支，处理其功能，同时定期从主干更新，然后将更改合并回主干（开发）内部审查。处理细微更改或修复的开发人员将直接将其置于主干中。
内部注销后，更改将合并到暂存。如果需要进行更改，通常会在trunk中进行更改，然后合并到staging。获得批准后，更改将与生产合并，然后部署。
新功能不会在内部或客户端按顺序进行审核，整个过程会变得相当混乱。我们似乎正在使用错误的流程 - 必须有更好的方法来实现这一目标。我们对学习如何更好地利用版本控制非常感兴趣，但我们缺乏启动过程的经验。
这些方案的最佳做法是什么？除了这个论坛，我们还有兴趣聘请一位经验丰富的顾问，他可以帮助我们改进流程。
谢谢！
答案 0 :(得分：4)
您可以考虑更改为Git而不是Subversion。 Git非常好地支持这种分支模型并且非常轻量级。它需要一点点习惯，特别是如果你从Subversion迁移，但最终它会为你买很多。
新功能的建议Git工作流程可能是：
您实际上不需要为此工作流程设置暂存分支。合并后您也不需要保留功能分支--Git会记住更改历史记录。
此模型支持异步/无序功能开发和审核，因为每个功能分支基本上都是独立的。
分支在Git中非常便宜，合并通常非常简单。
答案 1 :(得分：3)
我认为branching by feature（或团队）比开发人员的分支更好。在通过Development（Trunk）和Staging分支合并之前，可以测试和预览该功能。
我的团队有一个类似的“质量/环境分支”结构，我花了几个月研究如何最佳转换，以便开发人员一起工作，我们可以减少合并税。我建议如下：
暂存修复程序直接在Staging分支（如果QA和/或风险任务隔离的Staging的短期子分支）中进行，然后在修复被接受后立即合并修复回Development（Trunk）。 注意：在暂存修复过程中，请密切关注开发中的任何合并。
从质量检查角度来看，我强烈希望最终的分阶段和测试版本是发布到生产的相同二进制文件/文件。唯一的变化应该是配置文件（在存储库中签入了不同的配置设置）。这意味着我通常在“Staging”中进行最终构建，而“Production”或ReleaseVersion分支是没有人构建的只读存档。 （如果所述标签是不可变的，则可以使用标签或标签代替此保管分支......这不是TFS 2010的情况： - （。）
请参阅2011年2月的Visual Studio TFS Branching and Merging Guidance MSDN文章中的酷图。 要进行扩展，请参阅Branching for Scrum和Parallel Feature Teams working on multiple releases in development. Monthly releases to production.。这些都带有一些适用于任何版本控制系统的优秀图表。
我还建议在同一位置查看TFS Branching Guide和讨论论坛，以获得更多良好的模式和指导。 （分支方法在很大程度上独立于工具，避免工具缺陷时例外。）
我发现原始分支过程中至少存在一个基本缺陷：
内部注销后，更改将合并到暂存。如果需要进行更改，通常会在主干中进行更改，然后合并到分段。
如果在开发中对Staging进行了更改，然后再次合并到Staging，那么您刚刚继承了自上次合并到Staging以来对Development branch所做的所有其他更改。或者如果你挑选更改（让所有其他更改稍后合并）。 SCM工具在处理这种情况方面越来越好，但是挑选合并仍然会带来很大的风险。
仅供参考：最初描述的模式类似于Jeff Levinson所描述的“按质量分支”。它可以工作，但您必须仔细查看如何管理修补程序/ qfe分支并将更改合并回Trunk。
答案 2 :(得分：2)
你并没有确切地说它是如何变得混乱，但我猜这是当每个人将他们的功能分支合并回主干时。我建议将其作为工作流程：
为下一次部署而努力的每个人都在主干上工作并定期提交;只有采用多个周期或可能不包含在下一次交付中的功能才应在单独的分支上进行。我们称之为开发分支，它们应该在开发周期的开始时合并 - 而不是在最后。
当您准备好登台时，请创建一个发布分支。继续作为下一个版本的主干，合并到针对下一个版本的任何开发分支。此时，错误修复可能必须从分支合并回主干，但是只应修复错误而不是功能开发应该添加到分支上，所以它不应该太糟糕。在实践中，为了减少不必要的合并，我们通常不会创建发布分支，直到我们真正准备开始使用新功能。
当需要将代码转移到生产环境中时，只需标记发布分支并继续使用它。使用此分支可以使用修补程序维护此版本的代码，直到所有客户端站点都将其替换为下一个版本。
您在主干上开发并且每个版本保留在一个分支上的这个模型在我们有时希望修复我们软件的旧版本的客户环境中非常适合我们。
答案 3 :(得分：1)
您可能需要考虑以下方法，而不是为分段和生产设置单独的分支：
每个开发人员总是在主干上工作，当需要将其放入暂存时，您可以创建一个标记，指示进入暂存环境的代码快照。
如果您的客户批准，那么您可以继续将相同的标签推送到生产中。
如果他们不批准（例如，他们发现了一个错误），那么你只需继续使用trunk并使用错误修复创建另一个标记。
注意：由于SVN没有强制执行“标记”的概念，因此“标记”本质上是一个分支，您仍然可以在其中提交代码。但是，您不得更改（即提交）您在主干上创建的标记。