如何在大型团队中使用DVCS？

Question

最近，我开始在一个个人项目上使用Git，我可以看到DVCS如何使我们在工作中受益(这是一家大型企业软件公司，目前正在运行Perforce)。例如，我的团队中的特性工作主要由开发人员组成，他们创建自己的分支；有时，这些分支在小型开发团队之间共享。我认为在这种情况下使用DVCS会更有效。

不过，在更一般的情况下，我想听听在工作中使用DVCS的人的意见，他们是中、大型团队的。

1. 你是如何处理N路合并的？这是一种常见的情况吗？Mercurial只通过进行(N1)双向合并(和朗读表示这是其他DVCS的首选解决方案)来支持N向合并，这对于即使是相对较小的N也是一个非常困难的过程。
2. 您使用的是单一的中央权威存储库，还是真正的P2P？
3. 开发人员经常互相推拉代码，还是所有东西都经过中央存储库？

Answer 1

我前雇主的团队使用了Git，对我们来说效果很好。我们没有那么大(大概16岁左右，可能有8名真正活跃的提交者？)，但我对你的问题有了答案：

1. 正向合并并不是很普遍。我们想出了一些关于分支命名的约定，允许我们编写简化“发布工程”过程的脚本(我使用惊吓引号，因为我们没有发布工程师)，人们会创建私有特性分支，但是合并两个以上的分支很少有问题(参见下一个分支)。
2. (和3号)。我们在开发服务器上有一个中央存储库，原因有三个：(a)开发机器具有一个RAID5 (更具容错性)和夜间备份(开发工作站不是夜间备份)，(b)生产版本是在开发服务器上构建的，(c)简化了中央存储库脚本。因此，N路合并根本就没有发生过。我们对N路最接近的事情是，当有人横向合并，然后垂直合并。

对于我们来说，Git是一件非常棒的事情，因为它具有高度的灵活性；然而，我们确实需要建立一些约定(分支和标签名称、回购位置、脚本等)，否则可能会有点混乱。一旦我们设立了会议，我们的灵活性就太棒了。

更新:因此，我们的公约基本上是：

• NFS服务器上包含所有中央存储库的目录
• 我们有几个共享组件的项目，因此我们将它们分解为具有自己的存储库的库，而可交付的项目只是将它们作为git子模块来包含。
• 上面有版本字符串和发布名称强加给我们，所以我们只使用这些名称的变体作为分支名称。
• 类似地，对于标记，它们遵循流程指定的发布名称。
• 可交付的项目包含一个属性文件，我将该文件读入shell脚本中，这允许我编写一个脚本来管理所有项目的发布过程，即使每个项目在流程上都有细微的变化--这些变化在这些属性文件中得到了考虑。
• 我编写了脚本，可以从任何标记重新构建可交付的包。
• 使用git允许我们使用PAM和/或普通用户权限(ssh等)来控制访问。
• 还有其他更难列入项目列表的约定，比如何时应该合并。真的，我和另一个家伙是内部的"git专家“，我们帮助每个人弄清楚了如何使用分支和何时合并。
• 让人们在小块中投入，而不是在主分支中投下不同的炸弹是一项挑战。一个人放弃了整整两个星期的工作，完成了一项任务，最终我们不得不把这一切都解决了。这是对时间的巨大浪费，让所有人都感到沮丧。
• 提交内容丰富和详细的注释

当你的团队经验丰富，学会与他人合作时，你会学到其他的东西，但这足以让我们开始工作。

Update：任何关注这类事情的人现在都已经知道了，但是文森特·德莱森已经写了一个可靠且相当全面的(但不是令人激动的) 使用Git进行分支和发布工程。我高度鼓励以他的过程为起点，因为有两个原因：

• 许多团队都是这样做的，或者正在使用一些紧密的变体(包括Linux、Git和许多其他OSS项目团队)，这意味着这种方法已经过测试和调整，在大多数情况下都是成功的。在这个模型的约束下，您很难面对一个尚未面对和解决的问题。
• 由于以上所述，几乎所有具有Git经验的工程师都会理解发生了什么。您不必编写关于发布过程的基本性质的详细文档；您只需记录特定于您的项目或团队的内容。

Answer 2

我已经在格拉斯哥Haskell编译器团队使用暗黑族工作了好几年了。我最近(几个月)开始使用git作为我自己的回购版本，既为了性能，也为了提高我的教育水平。

1. 你是如何处理N路合并的？ 没有N路合并。每个开发人员都会创建一个补丁流，并在每次回购时合并一个流。因此，如果N名开发人员同时进行更改，他们就会成对合并。
2. 您是否使用单一的中央权威存储库？ 绝对一点儿没错。这是区分什么是GHC和什么不是GHC的唯一方法。
3. 开发人员经常互相推拉代码，还是所有东西都经过中央存储库？ 我认为这取决于开发人员和您正在使用的VCS。在GHC项目上，我看到的几乎所有的拉力和推动都通过中央存储库。但是有一个重量级的(自我管理的)看门人在推到中央回购，如果一个同事有我现在需要的bug修复，我会直接从他或她的回购。对于darcs，很容易只提取一个补丁(而不是git中的整个州)，而且我知道，我的同行开发人员，他们对darcs有更多的经验，比我更多地使用这个功能--而且他们非常喜欢它。 使用git时，当我与另一个开发人员密切合作时，我会经常创建一个新的分支，只为了与另一个人共享它。那条支路永远不会击中中央回购中心。

Answer 3

著名的“技术谈话: Linus Torvalds on git”解释了Linux是如何使用的(我所能想到的团队大小)。

如果我没记错的话，它的使用被比喻为军事指挥链--每个模块都有一个维护者，负责处理来自开发人员的请求，然后有几个“最受信任”的人负责将数据从模块维护人员中提取到官方的kernel.org git存储库中。

"Linux:用‘git’管理内核源“也解释了这一点，尽管这也不是一个简明的解释。