我目前正在从SVN迁移到Git。代码库是一个10-15模块的大型Maven项目。我们曾经为每个模块都有一个回购。
我想知道我的Git存储库应该用什么架构来处理以下用例：
我想到了'单一存储库'架构，但没有处理UC＃1。 'submodule'，'subtree'和前'one-module-one-repo'无法处理UC＃4。
此外，如果大多数用例由“子模块”架构处理，我想尽可能少地介绍复杂性。子模块引入了像分离头这样的概念，并且可能在更频繁的错误之后引起痛苦的修复。
我做了广泛的搜索，我不确定是否可以在不引入太多复杂性的情况下进行，但我希望你们中的一些人必须找到解决方法。
备注：我们当前的SVN架构无法处理此用例。
非常感谢，Maxime。
答案 0 :(得分：3)
您的分析是正确的;没有明显的方法可以同时解决所有这些用例。我建议采用以下两种方法之一：
实际上，您可能应该从单个存储库开始，然后在您认为有必要时将事情拆分出来。但你可能不会。 ：）
答案 1 :(得分：1)
你不可能拥有这一切。不是GIT而不是SVN。
您已经意识到您的要求相互冲突，甚至承认您当前的设置并未涵盖所有情况，因此您应该改变接近此问题的方式。
而不是要求工具的某些功能试图解释需要解决的实际问题是什么，并允许人们提出解决问题的方法，那些可能不会是你已经考虑过的事情。
我现在会尝试回答您在评论中显示的问题并完全忽略您的初始请求，我希望它可以帮助您更好地了解您所处的实际情况。
<>与SVN不同，在GIT中你有分支（真正的分支），每个分支都有自己的历史记录，所以只要你的开发人员使用分支并合并它们而不是使用rebase，你应该能够将每个分支日志与适当的命令，请参阅我们无法承担每个（10-15）模块的提交消息显示在同一位置的时间线
git log --graph以获得想法。
目前合并是焦虑的，因此开发人员尽量避免合并
没有真正的解决方案，但有办法缓解这个问题。
一种方法是将repo的几个克隆与主副本一起使用，如果你的团队大约有40个人并且你有10-15个模块，那么我猜你那里的小团队专注于特定领域/模块;如果是这种情况，那么每个子团队应该有自己的repo克隆并在那里合并到那里然后合并回主副本。
这种方法有效地将合并过程（和责任）分为两个阶段，一个涉及子团队内部的变化，另一个阶段涉及与其他模块的交互。
但是我必须保留用例4（移动和编辑），以便让Git在开发人员的眼中明确领先并驯服那种对合并的恐惧
我会说实话，UC＃4是不可能的*。特别是在GIT上，mv操作实际上是rm和add的组合。
也许如果在运动之前发生了加法，那么（d）VCS可以解决它但我不认为GIT就是这种情况，即使如此我认为你采取了错误的方式来“驯服那种对合并的恐惧“让我解释一下。
* @sleske建议检查this thread有关UC＃4的方法
人们担心合并的原因是因为他们不理解合并而SVN强迫你合并上游（即在服务器上）这会增加压力，你的方法的问题在于试图帮助他们避免合并你加强了合并是一种模糊和危险的想法，应该避免，不要这样做。
如果你想让他们克服你需要训练它们的恐惧，那么他们就有了处理情况的工具，换句话说就是不帮助他们避免问题迫使他们解决问题，教他们所有的合并和冲突风格，告诉他们rerere，甚至教他们章鱼合并，我从来没有用过，但他也教他们呢！然后让他们练习，这样他们知道并且可以处理。
这就是现在所有，如果你有其他问题添加评论，我会看看我是否有想法，祝你好运！