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

13
投票

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

N路合并并不常见。我们提出了一些关于分支命名的约定，这些约定允许我们编写简化“发布工程”过程的脚本（我使用了恐慌报价，因为我们没有发布工程师），人们会创建私有功能分支，但我们很少合并两个以上的分支有问题（见下一个）。
（和＃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经验的工程师都会理解正在发生的事情。您不必撰写有关发布过程基本性质的详细文档;您只需要记录仅针对您的项目或团队的内容。

7
投票

来自whygitisbetterthanx的工作流程架构：

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

5
投票

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

你如何处理N路合并？没有N路合并。每个开发人员发起一个补丁流，并在每个回购中一次合并一个流。因此，如果N个开发人员同时进行更改，他们将成对合并。
您是否使用单一的中央权威存储库？绝对。这是告诉什么是GHC和什么不是GHC的唯一方法。
开发人员经常会相互推送和拉取代码，还是通过中央存储库完成所有工作？我认为这取决于您使用的开发人员和VCS。在GHC项目中，我看到几乎所有的拉动和推动都通过中央存储库。但是有一个重量级（自我管理的）看门人推送到中央回购，如果一个同事现在需要修复错误，我会直接从他或她的回购中提取。使用darcs很容易只拉一个补丁（而不是像git那样整个状态），而且我知道我的同伴deveopers，他们对darcs有更多的经验，比我更多地使用这个功能---他们非常喜欢它。有了git，当我与其他开发人员密切合作时，我会经常创建一个新的分支，只是为了与另一个人分享。那个分支永远不会打到中央回购。

2
投票

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

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

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

1
投票

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

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

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

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

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

1
投票

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