26

我使用以下命令将 svn repo 克隆到 git 中，执行后，我看到了一些虚假分支。

git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp

git branch -a

*(no branch)
  master
  remotes/abc-1.3.x
  remotes/abc-1.3.x@113346
  remotes/abc-1.3.x@541512
  remotes/branch_test_script
  remotes/tags/modules-1.2
  remotes/tags/modules-1.2@113346
  remotes/tags/modules-1.2@516265
  remotes/tags/release-1.1
  remotes/tags/release-1.1@113346
  remotes/tags/release-1.1@468862
  remotes/trunk

在 svn 中创建的实际分支是 abc、branch_test_script、modules 和 release。有人可以帮助了解 'abc-1.3.x@113346' 、 'abc-1.3.x@541512' ... 'release-1.1@468862' 等是什么吗？

我们怎样才能摆脱这些虚假的分支/它们意味着什么？

谢谢，
加亚瑟里

4

2 回答 2

21

tl;博士：

git svn如果为子目录（或为另一个未被 git-svn 跟踪的目录）创建了分支（或标签），则创建这些“@”分支。总会有一个同名的“常规”分支，但没有“@”后缀。“@”分支仅作为常规分支的分支点存在。

注意：我为此提交了一个补丁；这个解释的编辑版本现在是官方git svn手册页的一部分，作为一个新的部分“处理 SVN 分支”（从 Git 1.8.1 开始）。

在 Subversion 中，分支和标签只是目录树的副本，因此可以（尽管通常不鼓励）从本身不是分支（或树干）的目录创建分支。例如，通过将 /trunk/foo 复制到 /branches/bar，而不是复制 /trunk（可以说是“子目录分支”），或者通过复制位于 trunk/tags/branches 结构之外的目录（即可能在 SVN 中）。

然而，在 git 中，一个分支总是针对整个 repo，不存在子目录分支。 git svn因此使用一种解决方法。如果它检测到从目录复制的分支，该目录本身没有被 git-svn 跟踪为分支，它将创建一个新的历史记录。例如，对于 /trunk/foo 被复制到 r1234 中的 /branches/bar 的子目录分支，它将创建：

  • 从 r1233 向后的每个 SVN 修订版的新 git 提交（注意数字是创建分支之前的最后一个修订版）。这些提交的树将只包含分支的子目录。因此，对于从 r1233 向后的每个修订版，通常会有两个 git 提交，一个包含整个树（在 git-svn 处理 的历史时创建trunk）和新的提交。
  • 一个名为“bar@1233”（分支名称@revision）的虚拟分支，指向从上面的 r1233 创建的提交。
  • 来自 r1234 的提交，即创建分支的提交。这个提交将把上面的分支作为它的（唯一的）祖先。
  • 一个名为“bar”的分支，它指向第二次提交。

这样，对于子目录分支栏，你在 git 中得到两个分支

  • bar@1233 ，表示创建分支的存储库的状态
  • bar，代表分支

我不太确定为什么会创建这个虚拟分支。我认为这样做是为了表示有关分支从哪个版本分支出来的信息，并拥有该分支的完整历史记录。

请注意，可以使用 flag 关闭整个机制--no-follow-parent。在这种情况下，每个 SVN 分支都会生成一个 git 分支，其中仅包含来自 SVN 分支目录的提交。每个分支都将与历史的其余部分断开连接，并且将有自己的根提交，对应于分支中的第一个提交。

于 2012-11-15T08:54:48.327 回答
6

当我将我的 SVN 存储库克隆到 Git 存储库时，我也有这种奇怪的分支。

在查看了预期的分支（在您的情况下modules-1.2，abc-1.3.x和branch_test_script）之后，release-1.1我注意到这些@revisionnumber分支只不过是在其前缀分支中的提交。

如果您想手动执行此操作，请gitk在分支上打开abc-1.3.x并验证abc-1.3.x@113346并abc-1.3.x@541512显示在该分支的历史记录中。如果是这样，您可以删除相应的分支。

如果您有许多分支或许多提交要浏览，这可能会有点麻烦。

自动方式：让 git 为你做：

git branch -r --contains abc-1.3.x@113346

会回声（或至少应该）

abc-1.3.x
abc-1.3.x@113346
abc-1.3.x@541512

这意味着您可以安全地删除abc-1.3.x@113346它，因为它包含在abc-1.3.x：

git branch -r -d abc-1.3.x@113346

由于 SVN 的线性历史，它当然也包含在（较新的）提交541512中。

旁注：
您可能已经注意到您的 SVN 标签实际上并未转换为 Git 标签和本机 Git 分支。这可以使用svn2git将 SVN 存储库克隆到 Git 存储库中来实现。

于 2012-07-06T10:01:53.450 回答