SVN到GIT的迁移或：如何用不同的语言组织大型回购

我知道这个话题已经在这里讨论过好几次了，但和我现在的情况不完全一样

我们希望使用Atlassian Stash/Bitbucket服务器从SVN迁移到GIT。我们的SVN回购是一种“上帝客体”回购，它不是那么小。大约有9年的历史，20000次提交

由于历史原因（…）结构类似于

svn:/url/trunk1
-| C# Libs (Visual Studio solutions + dll files)
--| Hardware related
---| Products
----| a lot of different solutions here...
---| non products
----| different other solutiosn here
-| Equipment (VS solutions, no Libs)
--| Equipment A
---| Project A1 
----| trunk
----| branches
----| tags
---| Project A2
----| trunk
--| Equipment B
---| Project B1
----| trunk
----| branches
----| tags
---| Project B2
---| no trunk but VS solution directly
-| Products
--| Product group A
---| Product A1
----| trunk
-----| matlab code
-----| documentation
-----| embedded c code
----| branches
----| tags
---| Product A2
----| trunk
-----| matlab code
-----| documentation
-----| embedded c code
----| branches
----| tags
-| Schematic/pcb
--| again some subfolders followed by products 

所以这真是一团糟。有一个巨大的主干1，我们在产品->项目中混合了matlab+c代码（每个项目都有自己的主干/分支）。然后，pcb原理图和c#dll libs有完全独立的文件夹，尽管与products文件夹有一些连接

两大问题： 1） 你会尝试将整个事情迁移到（很多）GIT回购协议中，还是重新组织它？ 2） 如何用不同的语言组织repo，比如matlab代码、嵌入式c固件代码和（松散耦合的）c#代码？您是否将其划分为每种语言，当某个项目需要其他回购协议的一部分时，您会怎么做

---

多谢各位

如何处理这种情况最终需要在利益相关者之间达成某种共识。好消息是，每个迁移到git的团队都必须处理这类事情。没有一个正确的答案，但我可以提供一些实际的事情来思考，并在帮助团队完成这一过程时提供建议

1.Git要么全是，要么什么都不是 与subversion不同，git克隆（如果您希望它可用）是一个全有或全无的命题。虽然您可以浅层克隆或签出repo的子集，但这些功能用于部署目的，而不是一般工作

因此，使用一个大型回购协议意味着每个克隆回购协议的人都需要为您曾经版本化过的每个项目下载9年的历史

虽然git与旧版本控制系统相比速度惊人，但如果将数百万个对象扔进它的数据库，它的性能确实会下降

这意味着某种形式的分手将不得不发生，以允许正确使用

2.你在哪里划界？ 首先考虑你现在在哪里画线。看起来你已经把回购协议分成了更小的部分，因为我在你展示给我们的内容中看到了多个主干和分支文件夹

这可能是一个好的开始。到团队的各个成员那里去，看看他们实际签出了什么，这将非常有启发性

其他考虑因素包括一起部署什么、更改某些内容的频率，以及组件之间的紧密耦合程度。有些项目可能最好分开，有些项目可能更好地合并

就组织而言，BitBucket允许您创建项目来组织存储库，其行为非常类似于文件夹。您最终会得到名称空间如下的回购：

bitbucket.mysite.com/equipment-a/project-a1.git

3.这对于项目来说很好，但是依赖性呢？ 看起来您还需要担心很多库和依赖项。有几种方法可以解决这个问题

您可以在解决方案中处理这些问题，方法是签出依赖关系repo并使用符号链接将它们导入到项目中，或者通过IDE导入它们。但是要小心，您的构建过程稍后会找到依赖项

一个更现代、更优雅的解决方案是设置内部包服务器（例如，NuGet for c#），并使用它们存储可以拉入项目的依赖项的版本化版本。这种方法不仅可以让您以熟悉的方式轻松访问库，而且在许多情况下还可以让您在项目之间逐步引入新版本。更不用说它让所有那些讨厌的二进制工件远离你的回购协议

4.这是不是太多的回购协议？ 是的，不，可能，也可能不是。这里没有一个神奇的数字。显然，1在你的情况下太低了（可能是10），但太高并不是由某个任意数字决定的（不管你的老板有多害怕），而是要在真实和理想之间取得神奇的平衡，让你完成工作。我有一个数据库架构师，他曾经说过“规范化直到它受伤，非规范化直到它工作。”同样的道理也适用于这里，找到一个平衡点，让您在不妨碍流程的情况下工作

我曾为单个项目和大型单一电子商务网站工作过100多个回购协议的微服务栈，只有1个。两者对各自的环境都同样有效

另一个好消息是，你现在所做的决定并不是永远的。如果你发现回购规模太大或者你把东西拆得太多，那么将回购拆分或合并是相对简单的，或者至少是可行的。所以，现在就尽你所能做出最好的决定，要有信心，不要被生活束缚

总之

---

你们已经提出了很多正确的问题，并且似乎直觉到了各种方法的许多风险和回报，所以我相信你们会为你们的团队找到一个很好的平衡点。最重要的是，让你的团队参与进来，确保他们对这些决策有意见。您可能需要订购一大罐肘部润滑脂。

如何处理这种情况最终需要您在利益相关者之间达成某种共识。好消息是，每个迁移到git的团队都必须处理这类事情。没有一个正确的答案，但我可以提供一些实际的事情来思考，并在帮助团队完成这一过程时提供建议

1.Git要么全是，要么什么都不是 与subversion不同，git克隆（如果您希望它可用）是一个全有或全无的命题。虽然您可以浅层克隆或签出repo的子集，但这些功能用于部署和维护