如何将分支结构不一致的SVN导入Git？

如果以前有人问过这个问题，我很抱歉，但我的情况是相对具体的。我在我的公司已经有一段时间了，并且使用SVN，但最近出于各种原因，我希望转到Git

我现在面临的问题是，我的公司使用非标准分支结构，不幸的是，在过去，它甚至不是一个一致的非标准分支结构

我知道，自从加入公司以来，我们使用一个主干分支，从中创建发布分支和功能分支。然而，这些分支的结构并不是简单的标准主干/分支/标记结构。对于不同类型的分支，我们有几个子文件夹。例如，发布分支进入分支发布、功能分支进入分支功能等，如下所示：

branches_feature/featureA
branches_release/2.0

我通过修改Git repo的配置，找到了如何使这个克隆/获取正常工作的方法

branches = {branches_feature,branches_release}/*:refs/remotes/branches/*

这在获取适当的分支方面比较成功。我遇到的一个问题是，当我的公司刚成立时，它使用了一种更类似于：

branches_feature/username/branchname

不幸的是，为了找到这个答案（困难的方法），我不得不“git svn fetch”，并发现所有遵循旧分支约定的分支都已崩溃，因此在git中，每个用户都有一个分支，每个分支都存在于其中。所以

branches_feature/username/featureA
branches_feature/username/featureB

已崩溃为：

branches_feature/username

显然，这对于正确复制SVN repo历史来说是不够的，但是我不确定如何修改配置的分支行来封装所有这些分支，并且仍然正确地使用新的分支格式。我一直试图以各种方式操纵它，但最终我要么出错，要么就是尝试失败

如果有人能提出一个好方法，在从SVN导入Git时适当保存SVN回购的历史，我将不胜感激

---

<>谢谢。

你当然可以处理这个问题，但是你应该考虑与回报相比你愿意付出多少努力。 如果您只是将转换限制为发布分支和主干，那么缺少功能分支会是一个主要问题吗？您应该仍然拥有提交（因为它们将在合并时出现），因此唯一不存在的提交是那些尚未合并回主干的提交

---

如有必要，您可以在以后单独转换所需的特征分支，并使用

git replace

和

git filter branch

TL将它们移植到适当的位置；DR：除了最琐碎的存储库之外，您永远无法在

git svn

存储库中完全保留Subversion存储库的内容

我正在改编这部电影

根据我的理解，您的Subversion树看起来像这样，其中

*

表示一个文件夹，在Subversion历史中的某个点上，该文件夹可能是工作副本的根：

/
|--branches_feature/
|  |--featureA/       *
|  |--userB/          *
|  |  |--featureB/    * (Possibly now deleted, but existed previously)
|  |  `--featureC/    *
|  `--userC/          *
|--branches_release/
|  |--V1.0/           *
|  `--V2.0/           *
`trunk/               *

遗憾的是，

gitsvn

无法以特别明智的方式处理这样的存储库。你不会得到一个Git存储库，它拥有你的Subversion存储库的所有分支，并且没有一个不应该拥有的分支

因此，你的选择是：

• 将

  branchs\u功能

  和

  branchs\u功能/userB

  视为分支文件夹
  您将得到一些Git分支，如果您签出它们，这些分支将为您提供一组文件夹，每个文件夹包含一个Subversion分支文件夹，

  Git svn fetch

  对这些文件夹的操作可能需要更长的时间，因为需要对容器分支和真实分支执行fetch。因为Git很聪明，它至少会占用非常少的额外磁盘空间
  我希望您的

  .git/config

  具有如下行：

  branches = branches_feature/*:refs/remotes/branches/*
  branches = branches_feature/userB/*:refs/remotes/branches/*
  branches = branches_release/*:refs/remotes/branches/*
  

  fetch = branches_feature/featureA:refs/remotes/branches/featureA
  fetch = branches_feature/userB/featureB:refs/remotes/branches/featureB
  fetch = branches_feature/userC:refs/remotes/branches/userC
  

• 忽略某些分支文件夹。只是不要告诉git svn他们的事，继续保持无知

• 挑选出你感兴趣的分支，然后手动挑选它们。如果您想要

  userB

  文件夹，但是如果它的分支已被删除，并且您不想获取它们，那么仍然需要注意您获取的历史记录
  在这里，我希望您的

  .git/config

  包含一整行代码，如下所示：

  branches = branches_feature/*:refs/remotes/branches/*
  branches = branches_feature/userB/*:refs/remotes/branches/*
  branches = branches_release/*:refs/remotes/branches/*
  

  fetch = branches_feature/featureA:refs/remotes/branches/featureA
  fetch = branches_feature/userB/featureB:refs/remotes/branches/featureB
  fetch = branches_feature/userC:refs/remotes/branches/userC
  

• 修补您的

  git svn

  版本，使其能够以某种方式应对这种情况。如果您在将来的Git官方版本中包含它，您将获得额外的积分

---

这里的问题是，我正在尝试完全替换SVN存储库（如果可以的话）。对于个人工作流，甚至对于公司目前来说，发布分支和主干就足够了。然而，由于没有以前的历史，我们无法取消旧的SVN回购。不过，我肯定不会排除这一选择。非常感谢。非常理解，在以前的迁移中，我花了很多精力来迁移所有内容，但我几乎从未使用过它。您可能会发现现有回购的

svn sync

、tarballed（或使用

svnadmin dump

导出并压缩）并备份到某个地方，以保护您的历史，而无需随身携带所有功能分支包。您的另一个选择是单独拉取所需的功能分支，如@me_和建议。要记住的主要一点是，SVN不会去任何地方，所以只要你做备份，你就可以在以后返回导入你需要的内容。是的，我自己并不太关心（旧的）历史。我试图说服我的公司从SVN转向Git，我觉得对他们来说，更大的问题是将历史从现在分割开来。能够恰当地构建历史只会让我的论点更容易一些。管理者不会让事情变得比必须的更容易（或更简单），所以