svn - SVN 中以开发人员为中心的分支

Question

我们的团队被要求从 CVS 升级到 SVN，虽然它不是我所希望的 Mercurial 或 Git，但它至少朝着正确的方向迈出了一步。

我知道对于开发团队来说，一个很大的问题——至少对于 SVN(或任何其他以分支为中心的 SCM)来说——是分支和合并的主题。

我读过文章宣扬“功能分支”(包含特定新功能开发的分支)是纯粹的邪恶。而且，在阅读它们之后，我倾向于同意。但这引出了 的问题。何时分支 , 和 何时合并 ?

我一直在玩弄让开发人员检查出主干/但每个人都有自己的(个人)开发人员分支并向这些分支提交新代码的想法。然后，每当开发人员完成他们的工作时，我们只需将与该工作相关的代码(位于他们自己的“私有(private)”分支内)与主干合并。这样他们就不会阻碍其他任何人，如果他们落后，他们也不会拖延发布。

只是想知道 SO 对以开发人员为中心的分支的想法是什么。如果这是一个糟糕的想法，为什么？ 有什么更好的方法？ 提前致谢!

Answer 1

我是那些认为特征分支是邪恶的类型之一。查看此相关问题以获取有关此主题的一些讨论(包括我自己的答案):Is using “feature branches” compatible with refactoring?

我不喜欢功能分支，因为它违背了持续集成的中心目的(实践，而不是工具)，即让开发人员在开发过程中尽早并经常将他们的工作集成在一起，并将其集成通过自动构建过程验证的工作。通过采用每个开发人员一个分支的工作流程，您在设计上使这种做法变得不可能，并且您回到开发人员进行独立的、未经验证的更改，然后需要在接近开发结束时以“大合并”的方式集成在一起过程。

DVCS 的追随者会说这纯粹是工具集的问题。现在，我同意有些版本控制系统在处理分支和合并方面比 subversion 好得多。这样的系统当然适用于为其设计的去中心化开源项目。然而，即使合并非常容易(即使使用理想的工具也永远不可能)，您仍然会遇到将集成延迟到流程后期的问题。这在一个开源项目中可能是可取的，因为主干只有几个受信任的看门人和许多(不太值得信任的)合作者。但是，在商业团队中，您确实应该能够信任每个人都致力于主干，因此不需要看门人。

总之，这是我对您粗体问题的回答:

什么时候分支？什么时候合并？ 我赞成发布分支，建立快照并使错误修复变得容易(在这种情况下合并是微不足道的，因为您正在谈论在主干和发布分支之间挑选一两个修订版)。我通常会避免使用特性分支，除非确实有必要对代码库进行广泛的更改。任何时候你使用分支，你都会在以后支付“大合并”的代价。

有什么更好的方法？ 在我的组织中，所有开发人员都直接 checkin 到主干。我们为每个应用程序持续构建(关闭主干)，并且我们定期(每周或两周)剪切一个新的发布分支(并为每个发布分支创建一个专用构建)。我们不是创建功能分支，而是尝试创建接口(interface)的新实现来实现新的或显着修改的功能。这些新的实现可以在生产中保持未使用，直到它们准备好，此时我们可以切换我们的应用程序来使用它们。使用 IoC 容器使这个过程变得非常简单。