我最近开始在一个个人项目中使用 Git，我可以看到 DVCS 如何使我们在工作中受益(这是一家大型企业软件公司，目前正在运行 Perforce)。例如，我团队中的功能工作主要由开发人员创建自己的分支组成；有时这些是在小型开发团队之间共享的。我认为在这种情况下使用 DVCS 会更有效。
不过，在更一般的情况下，我有兴趣听取在工作中使用 DVCS 的人的意见，在大中型团队中。
你如何处理 N 路 merge ？这甚至是一个常见的场景吗？ Mercurial 仅通过执行 (N-1) 次 2 路 merge 来支持 N 路 merge (以及 read，这是其他 DVCS 中的首选解决方案)，对于即使是相对较小的 N，这听起来也是一个非常费力的过程。您使用单个中央权威存储库，还是真正的 P2P？ 开发人员是否经常相互推送和 pull 代码，还是一切都通过中央存储库进行？
我之前雇主的团队使用 Git，它对我们很有效。我们并没有那么大(可能有 16 个左右，可能有 8 个真正活跃的提交者？)，但我对你的问题有答案:
N-Way merge 并不是很常见。我们提出了一些关于分支命名的约定，允许我们编写脚本来简化“发布工程”过程(我使用了恐吓引号，因为我们没有发布工程师)，人们会创建私有(private)功能分支，但我们很少 merge 两个以上的分支时遇到问题(请参阅下一个)。 (和#3)。我们在开发服务器上有一个中央存储库，原因有三个:(a) 开发机器有一个 RAID5(更容错)和每晚备份(开发工作站不是每晚)，(b) 在开发服务器上构建生产版本， (c) 拥有一个中央存储库简化脚本。结果，N 路 merge 根本没有发生。我们最接近 N 路的事情是有人横向 merge 然后垂直 merge 。 Git 对我们来说非常棒，因为它具有高度的灵活性；但是，我们确实必须建立一些约定(分支和标签名称、存储库位置、脚本等、流程)，否则可能会有点困惑。一旦我们建立了约定，我们所拥有的灵活性就非常棒了。
更新:我们的约定基本上是这样的:
我们 NFS 服务器上的一个目录，其中包含所有中央存储库 我们有几个共享组件的项目，所以我们将它们分解成库，本质上，有自己的存储库，可交付的项目只是将它们作为 git 子模块包含在内。 从上面强加给我们的版本字符串和发布名称，所以我们只是使用它们的变体作为分支名称 同样，对于标签，它们遵循流程指定的版本名称 可交付项目包含一个我读入 shell 脚本的属性文件，这允许我编写一个脚本来管理所有项目的发布过程，即使每个项目在过程中都有轻微的变化 - 这些变化被考虑在内在那些属性文件中 我编写了可以从任何标签重建可交付包的脚本 使用 git 允许我们使用 PAM 和/或普通用户权限(ssh 等)控制访问还有其他约定更难放在项目符号列表中，例如何时应该发生 merge 。真的，我和另一个人有点像内部的“git 大师”，我们帮助每个人弄清楚如何使用分支以及何时 merge 。 让人们以小块提交而不是在主分支中放置差异炸弹是一个挑战。一个人将大约两周的工作投入到一次提交中，我们最终不得不解开这一切。浪费了大量时间，让所有人都感到沮丧。 与提交一起使用的信息丰富且详细的评论 随着您的团队获得经验并学会彼此合作，您还可以学到其他东西，但这足以让我们开始。
更新 :现在任何关注这些事情的人都已经知道了，但是文森特·德赖森写了一篇扎实而全面的(但并不详尽)
take on branching and release engineering using Git .我强烈鼓励使用他的过程作为起点，因为有两个原因:
很多团队都是这样做的，或者正在使用一些接近的变体(包括 Linux、Git 和许多其他 OSS 项目团队)，这意味着这种方法已经过测试和调整，可以在大多数情况下成功。您不太可能遇到在此模型的约束范围内尚未面对和解决的问题。 由于上述原因，几乎任何有 Git 经验的工程师都会明白发生了什么。您不必编写有关发布过程基本性质的详细文档；您只需记录特定于您的项目或团队的内容。