为什么设置 git-svn 后会有多个同名分支
我刚刚使用 git svn 创建了一个由 Subversion 支持的新 Git 存储库。
检查创建的分支,有几个分支名称相似,后缀为@{number}
:
$ git branch -r
tags/project-0.0.1.0
tags/project-0.0.1.0@175525
tags/project-0.0.1.0@178802
tags/project-0.0.1.0@179205
trunk
trunk@175525
trunk@179205
这是什么意思?
I have just created a new Git repository backed by Subversion, using git svn.
On inspection of the branches created, there are several branches with a similar name, suffixed @{number}
:
$ git branch -r
tags/project-0.0.1.0
tags/project-0.0.1.0@175525
tags/project-0.0.1.0@178802
tags/project-0.0.1.0@179205
trunk
trunk@175525
trunk@179205
What do these mean?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
发生这些情况是因为 svn 将分支和标签作为单独的目录而不是内部表示来跟踪,从而允许发生在 git 宇宙中无法充分表示的事情。
例如,如果您重命名
branches/
下的目录,则实际上已重命名此版本的分支;如果您稍后将其重命名回来,那么 git-svn 无法确定这实际上是与之前相同的分支,因此它会创建一个新分支,并以发现重大更改的版本作为后缀。对于标签,只需更改文件就足够了,因为 git 不允许版本化标签(老实说,这个概念没有多大意义)。These happen because svn tracks branches and tags as separate directories rather than with an internal representation, allowing things to happen that cannot be adequately represented in the git universe.
For example, if you rename a directory below
branches/
, you have effectively renamed the branch at this version; if you later rename it back, then git-svn can not determine that this is in fact the same branch as before, and so it creates a new branch, suffixed with the version where it found the breaking change. For tags, simply changing a file is sufficient, as git does not allow versioned tags (and, honestly, the concept does not make a lot of sense).