4

我目前正在从 SVN 迁移到 Git。代码库是一个 10-15 个模块的大型 Maven 项目。我们曾经为每个模块都有一个 repo。

我想知道我的 Git 存储库应该使用什么架构来处理以下用例：

  • 用户可以签出 1..N 个模块。
  • John 提交并推入模块 M。Emma 从超级文件夹中提取更改。
  • John 从超级文件夹提交并推送模块 M 的更改。Emma 从模块文件夹中提取更改。
  • John 将（使用 git mv）文件 A 从 M1 移动到 M2，提交并推送。Emma 在提交前编辑文件 A 更新。该文件已随着 Emma 的更改而移动。

我想到了“单一存储库”架构，但没有处理 UC#1。'submodule'、' subtree ' 和以前的 'one-module-one-repo' 无法处理 UC#4。

此外，如果大多数用例都由“子模块”架构处理，我想引入尽可能少的复杂性。子模块引入了分离头之类的概念，并且在更频繁的错误后可能会导致痛苦的修复。

我进行了广泛的搜索，我不确定在不引入太多复杂性的情况下是否可能，但我希望你们中的一些人一定找到了解决方法。

备注：我们当前的 SVN 架构无法处理这种用例。

非常感谢，马克西姆。

4

2 回答 2

3

你的分析是正确的；没有明显的方法可以一次解决所有这些用例。我建议以下两种方法之一：

  1. 实际上可能不需要单独检查模块的第一个要求。使用 git，您在进行初始克隆时只需支付一次结帐费用，但之后增量更新非常快。
  2. 如果您正在处理 Maven 模块，也许每个模块都有自己的发布周期，那么模块真的需要源级关系吗？如果不是，那么模块依赖关系可以仅在 Maven 中表示。

确实，您可能应该从单个存储库开始，然后如果您发现有必要，稍后再将其拆分。但你可能不会。:)

于 2012-07-17T12:18:40.930 回答
1

你不能拥有这一切。不在 GIT 上，也不在 SVN 上。

您已经意识到您的需求相互冲突，甚至承认您当前的设置并未涵盖所有情况，因此您应该改变处理此问题的方式。

与其要求工具的某些功能，不如尝试解释需要解决的实际问题并允许人们提出解决问题的方法，这些可能不是您已经考虑过的事情。

我现在将尝试回答您在评论中显示的问题，并完全忽略您的初始请求，希望它对您所处的实际情况有所帮助。

我们无法承受每个（10-15）个模块的提交消息显示在同一个地方的时间线

与 SVN 不同，在 GIT 中，您有分支（真正的分支），并且每个分支都有自己的历史记录，因此只要您的开发人员使用分支并将它们合并而不是使用 rebase，您应该能够使用适当的命令隔离每个分支日志，看git log --graph明白了。

目前合并是焦虑的，因此开发人员尽量避免合并

对此没有真正的解决方案，但有办法缓解这个问题。

一种方法是在主副本中复制几个 repo，如果您的团队大约有 40 人并且您有 10-15 个模块，那么我猜您那里有专注于特定领域/模块的小团队；如果是这种情况，那么每个子团队都应该有自己的 repo 克隆并在本地合并，然后再合并回主副本。

这种方法有效地将合并过程（和职责）分为两个阶段，一个涉及子团队内部的更改，另一个处理与其余模块的交互。

但我必须保留用例 4（移动和编辑），以使 Git 在开发人员眼中具有明确的领先地位，并驯服对合并的恐惧

老实说，UC#4 是不可能的*。特别是在 GIT 上，mv操作实际上是rm和的组合add。

也许如果添加发生在运动之前，一些 (d)VCS 可以解决，但我不认为 GIT 就是这种情况，即使如此我认为你采取了错误的方式来“驯服对合并的恐惧”让我解释。

* @sleske 建议检查此线程以了解执行 UC#4 的方法

人们害怕合并的原因是因为他们不理解它并且 SVN 迫使您合并上游（即在服务器上）这增加了压力，您的方法的问题在于，通过尝试帮助他们避免它，您是强化合并是应避免的晦涩和危险的想法，不要那样做。

如果你想让他们克服恐惧，你需要训练他们，让他们拥有处理这种情况的工具，换句话说，不要帮助他们避免问题，强迫他们解决问题，教他们所有的合并和冲突风格，告诉他们rerere，甚至教他们章鱼合并，我从来没有用过，但他也教他们什么！然后让他们练习，让它成为他们知道并且可以处理的东西。

GIT 中的合并不像 SVN 那样压力大，因为它们也是本地的，因此您可以根据需要多次执行它们，而不必担心会破坏其他人的环境，只有在您完全确定它们时才会推动它们重新确定。

暂时就这些了，如果您还有其他问题，请添加评论，我会看看我是否有想法，祝您好运！

于 2012-07-18T02:40:37.927 回答