svn到git迁移后主干与主分支的差异

我执行了从svn到git的迁移。我看到我的分支+许多额外的主干分支。我该如何解释这些分支？我已经有了一个master（我用

--trunk dev

将其定义为主干）

当我展示我的分支时，我有这样的东西：

* master
  prod
  test
  trunk@123
  trunk@432
  trunk@892
  trunk@1023
  trunk@1134

---

虽然我的master是svn中的dev分支（我们将dev定义为我们的主干）。

git svn

创建带有

@

修订后缀的分支，但修订中的分支上的变更集不是修订+1中分支上的变更集的父级

也就是说，您得到

trunk@123

如果123之后对

/trunk

的下一次更改（不一定是124；因为这可能涉及不同的路径）将其删除并替换为新内容，很可能是从

/branchs/dev

（或

/dev

或您如何调用它）

---

在Subversion中，更改存在于分支上，因此您可以始终以

trunk@123

，但在Git中，提交仅在DAG中链接，因此由于这些提交没有后续提交（因为分支是从其他地方重写的），如果没有这些分支标签，提交将无法访问。

请尝试

git log--all--oneline--graph--decoration

检查这些分支之间的关系。此外，您还可以测试主干分支是否已经被

git分支（包含）合并到
master
trunk@123

。如果输出包含

master

，则

trunk@123

如果您不再需要它，可以将其删除。@ElpieKay谢谢，我似乎包含了master和其他一些内容trunk@revision每次都有分支。这意味着这些分支与主分支合并？但这是真正的分支吗？因为我们从来没有一个称为trunk的分支。@ElpieKay我可以删除本地和远程分支而不丢失提交吗？谢谢，现在我尝试了同样的方法并定义了--nobranches，但仍然得到了svn/remotes/trunk@revision在我的分支列表中。它们仍然存在，因为否则git将错过提交？@DenCowboy，与

--nobranches

一起，您只是告诉它不要为

/branchs

下的事情操心。但是，由于您仍然在导入

/trunk

，您仍然可以得到这些，因为这是在git中使提交可用的唯一方法，是的。请注意澄清：git svn在获取您要求它跟踪的分支的所有历史记录方面做了相当艰苦的尝试。。。这意味着尽可能回到历史。如果您将它设置为跟踪分支主干，并且在某个点上它看到不同的分支合并到主干中，但来自git svn未配置为跟踪的路径，那么它将创建一个类似于trunk@some-修订版（合并发生的修订版）。您可以尝试使用git branch-d（或-d）删除它们，但这还不够。git将重新创建它们，因为它们“隐藏”在元数据中（实际上，摆脱它们是一件痛苦的事情）。