git - 从 svn 迁移到 git。哪个选项最好 : giant trunk, 子模块、子树

Question

我知道关于同一件事有很多问题，但我仍然需要更多信息。
我正在研究将我们的 SVN 存储库迁移到 git 的可能性，并试图了解哪种方法(单体主干、子模块、子树等)最适合我们的存储库。

以下是有关我们的项目和 SVN 存储库的一些信息:

项目是java web 应用程序，打包是war。

模块化应用。每个模块由单独的团队开发
然后打包成jar。

war 取决于这个 jar 。

基本上我们的结构看起来像:

repo
|-application(war)
|-module1 (for example, ui stuff)
|--module1Submodule1
|--module1Submodule2
|-module2 (for example, database access stuff)
|-...

每个模块都有自己的标签和分支。

我的本地机器上的 svn repo 大小与所有分支、标签等是:

超过 250 万个文件

超过 20Gb 空间

有 311615 次修订

文件多为源代码，无大二进制对象

典型用例:

200+ 整个团队的开发和 QA

不同的团队提交他们的模块/子模块。 (它可以是一个
单体 git repo 的问题，因为 git 需要提取所有更改
在推送之前，svn 只警告过时的更改)

分支模块

分支申请

future 用例:

格里特

开发人员提交，提交被审查，针对提交运行测试，
如果是绿色，则提交被批准 merge 到“master”分支

问题是:

我们可以将这样的 repo 视为 git 的大型仓库吗(我的意思是有很多帖子指出 git 对于大型仓库的扩展性很差，但什么是“大型”？)

每种方法的优缺点是什么:

Monolith repo(只是作为 svn 的 git，反模式？)

子模块

子树(我对模块中的每个更改都需要在子树存储库中提交，然后将更改 pull 到聚合子树存储库中吗？)

每个模块的单独存储库

任何其他..

SVN 的历史记录可以为他们每个人保留吗？

我需要尽可能多的链接(我没有找到任何关于“大型 repo 缓慢”的官方链接)

先感谢您!

Answer 1

历史

可以使用 git svn 为所有提到的方法保留历史记录:http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git
甚至可以切换回之前的提交。

但是，有人建议不要保留历史记录，而将 svn 存储库卡住大约 6 个月，而所有历史记录都将在 git 存储库中更改。我不同意这些建议，因为历史对我们的项目至关重要。我打赌没有人接受这样的解决方案。

巨型树干接近

你必须克隆整个大树，即使你只是计划
处理一个子目录(主要用例)

一些 git 命令会很慢(例如:git status，因为它需要
检查整棵树)

即使您调整 jenkins 以仅针对特定部分触发构建
repo (这可以使用 jenkins git 的“include”属性来完成
插入)。仍然需要 pull 所有 repo 来执行构建。
这几乎不会影响所有工作，因为“干净”的结帐会
即使构建小模块也需要花费很多时间。

关注点:整个团队有 200 多个 Dev 和 QA，我怀疑最终 push 更改会很不安。

只有在审核通过后才会将更改推送到主分支
gerrit 和测试都通过了，所以我们不会有连续的流
pull 推失败 pull 推

但是如果主分支被更改，gerrit 可能会拒绝 merge
由于提交已推送到 gerrit，因此需要单击“rebase”
按钮并重新运行测试。

Linux kernel有monolith repo，因为c/c++没有依赖
像 java 一样的管理:用 jar 构建像 war 一样的内核 tar
依赖关系不是这样。

测验

使用这种方法进行迁移的步骤、成本和总成本是什么？

git svn 克隆 SVN_URL REPO_NAME

Jenkins 的东西

它如何支持代码门控？从 VCS/工具的角度来看，需要进行哪些更改？假设这里完整的 CI 运行需要 15 分钟。

Jenkins 应该在 scm 触发器中有“包含”过滤器来过滤更改
对于项目的特定部分。不是那么难，但仍然
需要一些努力来设置和验证它们。在“擦
构建之前的工作空间”构建，整个 repo 应该被克隆所有
时间。它可以增加从提交到“批准”的总时间
测试”，因为结帐会很慢。

什么是高效的开发人员工作流程？

开发者使用本地/远程功能分支

将更改推送到 gerrit

Gerrit 根据测试验证更改

变更 merge 到主分支

子模块

大多数注意事项在这里 http://git-scm.com/book/en/Git-Tools-Submodules 和这里 http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ 解释

主要问题是你必须提交两次

子模块本身

聚合 repo - 更新子模块 没有意义。为什么你需要
如果依赖项是通过工件存储库管理的，则聚合存储库？

实际上，子模块是为存在可以在不同项目中重用的库的情况下创建的，但您希望依赖库的特定标签，以便将来能够更新引用。但是，我们不会标记每个提交(仅在每次提交后发布)并且在 war 中更改依赖项版本(到已发布的版本)将比维护子模块方法更容易。 Java 依赖管理使事情变得更简单。

不建议指向子模块头，会导致子模块出现问题，所以这种方式去快照是死路一条。再次我们不需要它，因为 java 依赖管理会为我们做一切。

测验
使用这种方法进行迁移的步骤、成本和总成本是什么？

每个模块的 git svn clone SVN_URL REPO_NAME

创建聚合 git repo

将模块存储库作为子模块添加到聚合存储库

它如何支持代码门控？从 VCS/工具的角度来看，需要进行哪些更改？假设这里完整的 CI 运行需要 15 分钟。

Gerrit 支持 merge 和提交到子模块，所以它应该
没事。

Jenkins 的东西 - 在子模块更改和聚合 repo 上触发
变化(啊!有两个地方没有意义!)

什么是高效的开发人员工作流程？ (省略Gerrit过程)

开发人员提交到子模块

标记他的提交

开发人员进入聚合 repo

cd 进入子模块， check out 标签

使用更改的子模块哈希

提交聚合 repo

要么

开发人员更改子模块

将更改推送到子模块以不丢失更改

使用更改的子模块哈希

提交聚合 repo

如您所见，开发人员工作流程繁琐(需要始终更新两个位置)并且不适合我们的需求。

子树

主要问题是你必须提交两次
树 merge 子目录
将更改推送到原始存储库

子树是子模块的更好替代品，它更健壮，并将子模块的源代码 merge 到聚合 repo 中，而不是仅仅引用它。维护这种聚合存储库使事情变得更简单，但是子树的问题与子模块的问题相同，进行双重提交完全没有用。您不必对原始模块存储库提交更改，并且可以使用聚合存储库提交它，这可能导致存储库之间的不一致...

这些差异在这里得到了很好的解释: http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/

测验
使用这种方法进行迁移的步骤、成本和总成本是什么？

每个模块的 git svn clone SVN_URL REPO_NAME

创建聚合仓库

对每个模块进行子树 merge

它如何支持代码门控？从 VCS/工具的角度来看，需要进行哪些更改？假设这里完整的 CI 运行需要 15 分钟。

看起来 Gerrit 对子树 merge 的支持不是很好
( https://www.google.com/#q=Gerrit+subtrees )

但是我们不能确定直到尝试

Jenkins 的东西。触发子树 repo 和聚合 repo
变化(啊!有两个地方没有意义!)

什么是高效的开发人员工作流程？ (省略Gerrit过程)

开发人员更改了子树中的某些内容(在聚合存储库内)

开发人员提交聚合 repo

开发人员不会忘记将更改推送到原始存储库(没有
感觉!)

开发人员不要忘记不要将子树更改与聚合混合
一次提交中的 repo 更改

再次像子模块一样，有两个地方(repo)存在代码/更改是没有意义的。不适合我们的情况。

单独的存储库

单独的 repos 看起来是最好的解决方案，并遵循原始的 git 意图。 repo 的粒度可能会有所不同。最细粒度的情况是每个 Maven 发布组都有 repo，但是它可能导致太多的 repos。我们还需要考虑一个特定的 svn 提交影响多个模块或发布组的频率。如果我们看到，该提交通常会影响 3-4 个发布组，那么这些组应该形成一个 repo。

此外，我认为至少将 api 模块与实现模块分开是值得的。

测验
使用这种方法进行迁移的步骤、成本和总成本是什么？

git svn clone SVN_URL REPO_NAME 每个或多或少的细粒度
模块数

它如何支持代码门控？从 VCS/工具的角度来看，需要进行哪些更改？假设这里完整的 CI 运行需要 15 分钟。

Jenkins 分别为每个 repo 触发。没有“包含”过滤器。
只需结帐、构建、部署即可。

什么是高效的开发人员工作流程？

开发人员为每个 repo 使用本地/远程功能分支

将更改推送到 gerrit

Gerrit 根据测试验证更改

更改 merge 到主分支