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

Question

我最近开始在个人项目上进入Git，我可以看到DVCS如何让我们在工作中受益（这是一家大型企业软件公司，目前正在运行Perforce）。我的团队中的功能工作主要包括开发人员创建自己的分支;有时这些是由小型开发团队共享的。我认为在这种情况下使用DVCS会更有效率。

在更一般的情况下，我有兴趣听到在工作中使用DVCS的人，大中型团队。

1. 你如何处理N路合并？这甚至是一种常见的情况吗？ Mercurial仅通过执行（N-1）2路合并（以及read这是其他DVCS中的首选解决方案）来支持N路合并，这对于相对较小的N来说听起来是一个非常费力的过程。 / LI>
2. 您是使用单一的中央权威存储库，还是真正的P2P？
3. 开发人员经常会相互推送和拉取代码，还是通过中央存储库完成所有工作？

Answer 1

我以前雇主的团队使用Git，对我们来说效果很好。我们不是那么大（可能是16个左右，可能有8个真正活跃的提交者？），但我对你的问题有答案：

1. N-way合并并不常见。我们提出了一些关于分支命名的约定，这些约定允许我们编写简化“发布工程”过程的脚本（我使用恐慌报价，因为我们没有发布工程师），人们会创建私有功能分支，但我们很少合并两个以上的分支有问题（见下一个）。
2. （和＃3）。我们在开发服务器上有一个中央存储库有三个原因：（a）开发机器有RAID5（更容错）和夜间备份（开发工作站不是每晚），（b）生产版本是在开发服务器上构建的， （c）使中央存储库简化脚本。结果，N路合并根本就没发生过。我们对N-way最接近的是当有人横向合并然后垂直合并时。

Git对我们来说是一件非常棒的事情，因为它具有高度的灵活性;但是，我们确实必须建立一些约定（分支和标记名称，repo位置，脚本等，进程）或者它可能有点混乱。一旦我们设置了惯例，我们的灵活性就非常棒了。

更新：我们的惯例基本上是这样的：

• 我们的NFS服务器上的一个目录，其中包含所有中央存储库
• 我们有几个共享组件的项目，因此我们将它们分解为库，基本上是使用自己的存储库，而可交付项目只是将它们作为git子模块包含在内。
• 我们从上面强加了版本字符串和版本名称，所以我们只使用了那些作为分支名称的变体
• 同样，对于标签，它们遵循流程规定的版本名称
• 可交付项目包含一个属性文件，我将其读入shell脚本，这使我可以编写一个脚本来管理所有项目的发布过程，即使每个项目在过程中都有轻微的变化 - 变化在这些财产档案中计算了
• 我编写了可以从任何标记重建可交付包的脚本
• 使用git允许我们使用PAM和/或普通用户权限（ssh等）控制访问权限
• 还有一些其他约定更难以放入项目符号列表中，例如合并时应该发生。真的，我和另一个人都是内部的“git guru”，我们帮助每个人弄清楚如何使用分支以及何时合并。
• 让人们以小块的形式提交，而不是在主分支中丢弃差异炸弹是一个挑战。一个人将大约两个星期的工作投入到一次提交中，我们最终不得不解开它。 巨大浪费时间，令所有人感到沮丧。
• 提交内容的详细信息和详细评论

当你的团队经验丰富并且学会彼此合作时，你还会学到其他的东西，但这足以让我们开始。

更新：任何关注此类事情的人现在都已经知道了，但Vincent Dreissen撰写了一篇非常全面（但并非豁免）take on branching and release engineering using Git的文章。我强烈建议将他的过程作为起点，因为有两个原因：

• 很多团队都是这样做的，或者正在使用一些密切的变体（包括Linux，Git和许多其他OSS项目团队），这意味着这种方法已经过测试和调整，在大多数情况下都是成功的。您不太可能面对在此模型的约束下未遇到和解决的问题。
• 由于上述原因，几乎所有具有Git经验的工程师都会理解正在发生的事情。您不必撰写有关发布过程基本性质的详细文档;您只需要记录仅针对您的项目或团队的内容。

Answer 2

来自whygitisbetterthanx的工作流程架构：

_{（来源：whygitisbetterthanx.com）}

要将此扩展到更多开发人员，您只需在集成管理器和开发人员之间添加另一层“可信赖的副官”。

Answer 3

我使用Glasgow Haskell Compiler与Darcs团队一起工作了几年。我最近（几个月）开始使用git作为我自己的回购副本，无论是为了表现还是为了改善我的教育。

1. 您如何处理N路合并？

   没有N路合并。每个开发人员发起一个补丁流，并在每个回购中一次合并一个流。因此，如果N个开发人员同时进行更改，则会成对地合并。

2. 您是否使用单个中央权威存储库？

   绝对。这是告诉什么是GHC以及什么不是GHC的唯一方法。

3. 开发人员经常会相互推送代码，还是通过中央存储库完成所有工作？

   我认为这取决于您使用的开发人员和VCS。在GHC项目中，我看到几乎所有的拉动和推动都通过中央存储库。但是有一个重量级（自我管理的）看门人推送到中央回购，如果一个同事有错误修复我需要现在，我会直接从他或她的回购。使用darcs很容易只拉一个补丁（而不是像git那样整个状态），而且我知道我的同伴deveopers，他们对darcs有更多的经验，使用这个功能比我做的要多得多---他们非常喜欢它。

   使用git，当我与其他开发人员密切合作时，我会经常创建一个新分支，目的是与另一个人共享。那个分支永远不会打到中央回购。

Answer 4

相当着名的“技术讲座：Linus Torvalds on git”解释了它如何用于Linux（与我能想到的一样大）

如果我没记错的话，它的使用被比作军事指令链 - 每个模块都有一个维护者，处理来自开发人员的拉取请求，然后有一些“最值得信赖”的人处理从中提取数据模块维护者进入官方kernel.org git仓库。

"Linux: Managing the Kernel Source With 'git'"也解释了它，虽然它再次不是一个简洁的解释..

Answer 5

这是一个例子（绝不是“普遍的”）

我们有中央VCS（ClearCase或SubVersion，具体取决于不同的项目），我们正在将它们用于“官方”开发工作（开发，补丁，修复），其中分支的数量有限且识别良好。

但是，对于涉及大量中间状态的重构开发，其中没有任何工作，并且许多开发人员需要拥有自己的基于活动的分支或分支，在这些之间设置一些Git存储库开发人员，以P2P方式 一旦工作达到某种0.1稳定性，并且合并减少，它就会在VCS中重新导入，工作可以以“有序”的中心方式进行。

自Git on Windows works well（MSysGit）以来，我们设法在这方面快速完成了小的初始开发。

我们仍在评估Git的全面项目开发。

Answer 6

最好研究一下linux内核开发人员的工作方式。他们有一个非常复杂的工作流程，从多个来源提交更改，然后每个子系统（称为中尉）的可信开发人员提取变更，当他们感到高兴时，将他们提交给Linus，Linus最终将他们拉入他的树或拒绝他们。当然它比这更复杂，但这是一般概述。