30

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

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

  1. 你如何处理 N 路合并？这甚至是一种常见的情况吗？Mercurial 仅通过执行 (N-1) 2 路合并来支持 N 路合并（并且读到这是其他 DVCS 中的首选解决方案），这对于即使是相对较小的 N 来说也是一个非常费力的过程。
  2. 您使用单一的中央权威存储库，还是真正的 P2P？
  3. 开发人员是否经常相互推拉代码，或者一切都通过中央存储库进行？
4

6 回答 6

13

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

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

Git 对我们来说是一件非常棒的事情，因为它具有高度的灵活性。但是，我们确实必须建立一些约定（分支和标签名称、repo 位置、脚本等，流程），否则可能会有点混乱。一旦我们建立了约定，我们所拥有的灵活性就非常棒了。

更新：我们的约定基本上是这样的：

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

随着您的团队经验丰富并学会相互合作，您还可以学到其他东西，但这足以让我们开始。

更新：到目前为止，任何关注此类事情的人都已经知道了，但是 Vincent Dreissen 使用 Git 编写了一个可靠且非常全面（但不详尽）的分支和发布工程。我强烈鼓励以他的过程为起点，因为有两个原因：

  • 很多团队这样做或正在使用一些相近的变体（包括 Linux、Git 和许多其他 OSS 项目团队），这意味着这种方法已经过测试和调整，在大多数情况下都能成功。在此模型的约束下，您不太可能遇到尚未解决和解决的问题。
  • 由于上述原因，几乎所有具有 Git 经验的工程师都会明白发生了什么。您不必编写有关发布过程基本性质的详细文档；您只需要记录特定于您的项目或团队的内容。
于 2009-04-25T04:23:23.307 回答
7

来自Whygitisbetterthanx的工作流程模式：

带有集成管理器的 alt git 工作流程
（来源：whygitisbetterthanx.com）

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

于 2009-04-26T00:35:45.873 回答
5

我已经使用Darcs在Glasgow Haskell Compiler团队工作了几年。我最近（几个月）开始将 git 用于我自己的 repo 副本，以提高性能和提高我的教育水平。

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

    没有 N 路合并。每个开发人员都发起一个补丁流，并在每个 repo 中一次合并一个流。因此，如果 N 个开发人员同时进行更改，他们将成对合并。

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

    绝对地。这是分辨什么是 GHC 什么不是的唯一方法。

  3. 开发人员是否经常相互推拉代码，或者一切都通过中央存储库进行？

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

    有了git，当我与其他开发人员密切合作时，我会经常创建一个新分支，只是为了与其他人共享它。该分支永远不会命中中央回购。

于 2009-04-25T22:59:55.323 回答
2

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

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

“Linux：使用 'git' 管理内核源”也对此进行了解释，尽管这又不是一个简明的解释。

于 2009-04-25T23:37:20.397 回答
1

这是一个示例（绝不是“通用”示例）

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

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

由于Windows 上的 Git 运行良好（MSysGit），我们设法在这种方式下快速完成小的初始开发。

尽管如此，我们仍在评估 Git 以进行全面的项目开发。

于 2009-04-24T22:02:00.727 回答
1

最好研究一下 linux 内核开发人员的工作方式。他们有一个相当复杂的工作流程，其中从许多来源提交更改，然后每个子系统的受信任开发人员（称为副手）拉入更改，当他们满意时将它们提交给 Linus，Linus 最终要么将它们拉入他的树中，要么拒绝他们。当然它比这更复杂，但这是一个总体概述。

于 2009-04-25T04:02:46.757 回答