如何将代码从 SVN 迁移到 GIT 而不丢失提交历史记录?
我想知道将我们的代码从 SVN 存储库移动到 GIT 存储库的推荐方法,以便我们将我们的开发团队和工作人员转移到 GIT 存储库。开始使用GIT。
我们可以进行转换并将所有提交保留在 SVN 存储库中吗?
另外,我们的团队目前对 SVN 很满意,但是,他们不知道 GIT 中的分支比 SVN 容易得多,我在哪里可以找到一个实际的例子来证明 GIT 在分支方面的强大功能?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
Eric Raymond (esr) 创建了 reposurgeon,“一个命令解释器,用于在版本上执行棘手的编辑操作 -控制历史。”该工具包含用于各种目的的脚本,包括清理 VCS 转换的结果。从https://gitlab.com/esr/reposurgeon查看。
从版本 2.0 开始,它支持读取 SVN 转储文件,以完整且惯用地转换为 Git、Mercurial 等。有关详细信息,请参阅 http://esr.ibiblio.org/?p=4071。 Reposurgeon 已被用来将多个大型项目转换为 Git,其中包括 Emacs,ESR 表示,其存储库“很大,分支结构复杂,而且历史悠久,足以作为 CVS 存储库开始使用。最后一部分很重要,因为潜伏在 Subversion 项目历史中的一些最丑陋的翻译问题是由 cvs2svn 生成的奇怪的 Subversion 操作序列(包括分支复制操作的组合)。”
(Git 附带的 git-svn 工具将处理许多 Subversion 存储库,包括分支。它非常常用,尤其是正在进行转换的团队,因为它允许 Git 充当 Subversion 客户端。但是请参阅 ESR 的不要使用 svn-to-git 存储库转换git-svn!,他在其中讨论了 git-svn 作为转换工具的缺点。)
关于你的第二个问题,它并不是 Git 的强大功能如此有用的分支(尽管 Git 是在这方面至少与 Subversion 一样强大); Git 在合并这些分支方面表现出色。通读 Git 社区书籍,尤其是第 3 章中标题为“基本分支和合并”以及第 7 章中标题为“高级合并”。
Eric Raymond (esr) has created reposurgeon, “a command interpreter for performing tricky editing operations on version-control histories.” The tool includes scripts for various purposes, including cleaning up the results of VCS conversions. Check it out from https://gitlab.com/esr/reposurgeon.
As of version 2.0 it includes support for reading SVN dumpfiles for complete and idiomatic translation to Git, Mercurial, etc.; see http://esr.ibiblio.org/?p=4071 for details. Reposurgeon has been used to convert several large projects to Git, including Emacs whose repository, ESR says, “is large, complex in branch structure, and old enough to have begun life as a CVS repo. That last part matters because some of the ugliest translation problems lurking in the back history of Subversion projects are strange Subversion operation sequences (including combinations of branch copy operations) generated by cvs2svn.”
(The git-svn tool included with Git will handle many Subversion repositories, including branches. It’s pretty commonly used, especially by teams that are in the process of doing a conversion, since it allows Git to behave as a Subversion client. But see ESR’s Don’t do svn-to-git repository conversions with git-svn!, where he discusses the drawbacks to git-svn as a conversion tool.)
Regarding your second question, it isn’t branching where the power of Git is so helpful (though Git is at least as powerful as Subversion in this regard); it’s when it comes to merging those branches that Git shines. Read through the Git Community Book, especially the section in chapter 3 titled “Basic Branching and Merging” and the section in chapter 7 titled “Advanced Merging”.
由于已经有很多人使用 git-svn,我想说这很有可能。以下命令是众所周知的:
根据手册(在本地验证),这将保留“主干、标签和分支”。
Since there are already lots of people working with git-svn, I'd say it's very much possible. The following command is pretty well known:
According to the manual (verified locally), this will keep the "trunk, tags and branches".
2014 年 4 月更新
有一个名为 Svn2Git 的工具,它可以很好地使此过程变得更容易一些。 Github 项目上的文档非常好。 (需要 Ruby)
值得注意的是,虽然 git-svn 默认只从您指定的路径拉取,而不是分支、标签和主干。 svn2git则相反。它将默认在路径下查找主干、分支和标签,您应该使用
--nobranches
或--notags
告诉它不要搜索这些(尽管这可能会抵消 svn2git 的优势)。一旦你迁移到 Git,我建议你迁移所有人并继续使用 Git。虽然比较复杂,但这种转变是值得的。 Github.com 支持使用 Subversion 客户端访问存储库(但您可能会失去 Git 分支的功能),这可能是一个很好的权宜之计。
我可以保留我的 Subversion 存储库吗?
当您使用以下方法进行移动时,所有当前提交都将保留在 Subversion 存储库中。您也许能够从 Subversion 存储库到 Git 存储库进行单向同步,但采用另一种方式会很快变得非常复杂。我不建议尝试以任何一种方式同步并一次性移动每个人。
Git 有何强大之处?
Git 分支很强大,但这并不是 Git 的全部。在本地拥有完整的历史记录意味着您可以使用 Subversion 执行所有操作,而无需联系服务器。查看和搜索历史记录、撤消更改、本地提交、本地分支变得非常快。 Git 还会压缩其数据,因此 Subversion 签出(仅包括最新版本)最终与 Git 签出(包括完整历史记录)的大小大致相同。此外,由于数据在传输时被压缩,因此推送和拉取的速度也更快。不要只推送 Git 分支,而是放置有关 Git 的所有内容。
如何使用 git svn 方法移动存储库。
首先,克隆 Subversion 存储库。这可能需要一段时间。
其中
http://www.example.com/svn-repo/
是 Subversion 存储库的 URL,projectA/trunk/
是您要复制到 Git 中的路径。如果您有标准布局,例如
projectA/trunk
、projectA/branches/
和projectA/tags/
,则可以添加- -stdlayout
并从这样的目录中克隆并且,如果您有一个与上面命名不同的主干、分支和标签文件夹,您可以为每个文件夹指定
git svn clone
自定义名称。完成后,您所要做的就是使用
--mirror
推送到远程 git 存储库。此时,您应该将 Subversion 存储库设置为只读,以防止人们尝试提交到过时的位置。
Update Apr 2014
There is a tool called Svn2Git that does a pretty good job of making this process a bit easier. The documentation on the Github project is pretty good. (Ruby required)
It's worth noting that while git-svn defaults to pulling from just the path you specify, not branches, tags and trunk. Svn2git is the opposite. It will default to looking for a trunk, branches and tags under the path and you should use
--nobranches
or--notags
to tell it not to search for those (though this may nullify the advantages of svn2git).Once you move to Git, I suggest you move everyone and stay using Git. It's more complicated but the transition will be worth it. Github.com supports accessing the repo using an Subversion client (but you may loose the power of Git branching) and that might be a good stop-gap.
Can I keep my Subversion repo?
When you use the below method to move, all the current commits will remain in the Subversion repo. You may be able to do a one-way sync from the Subversion repo to the Git repo, but going the other way gets very complicated very fast. I would not recommend trying to sync either way and just move everyone one-time.
What's powerful about Git?
Git branching is powerful but it's not all there is to Git. Having a complete history locally means you can do everything you can do with Subversion, but without having to contact the server. Reviewing and searching the history, undoing changes, committing locally, branching locally become immensely faster. Git also compresses it's data, so a Subversion checkout (that includes only the latest revision) ends up being about the same size as a Git checkout (that includes the full history). Also, because data is compressed when transferred, pushing and pulling are much faster as well. Don't just push Git branches, put everything about Git.
How to move a repo using the
git svn
method.First, clone the Subversion repo. This might take a while.
Where
http://www.example.com/svn-repo/
is the URL to the Subversion repo andprojectA/trunk/
is the path you want to copy into Git.If you have a standard layout such as
projectA/trunk
,projectA/branches/
andprojectA/tags/
than you can add--stdlayout
and clone from a directory up like thisAnd, if you have a trunk, branches and tags folder named differently then above, you an give
git svn clone
custom names for each.Once that completes all you have to do is push to the remote git repo with
--mirror
.At this point you should make your Subversion repo read-only to keep people from trying to commit to an out dated location.
可以使用 git svn clone 完全转换存储库,包括标签和所有分支。
为了使标签正确,需要进行一些调整,请参阅 此链接了解更多信息。
此主题之前已在 SO 中至少讨论过一次:
如何将 svn 分支和标签导入 git-svn?
The repo could be converted fully, including tags and all branches using
git svn clone
.There's some tweaking neccesary to get the tags correct, see this link for more information.
This topic has been covered here at SO at least once before:
How to import svn branches and tags into git-svn?
从Svn安全平滑地迁移到Git的方法是使用SubGit - 服务器端Git/Svn同步工具。人们可以将 SubGit 安装到 Subversion 存储库中,并在迁移过程持续期间继续同时使用 Subversion 和 Git。
免责声明:我是 SubGit 开发人员,已经愉快地使用 SubGit 半年了。
Safe and smooth migration approach from Svn to Git is to use SubGit - server-side Git/Svn synchronization tool. One may install SubGit into Subversion repository and continue to use both Subversion and Git simultaneously as long as migration process lasts.
Disclaimer: I'm SubGit developer who happily uses SubGit for half a year already.
我将 CVS 存储库迁移回 git,首先转换为 subversion,然后转换为 git。当使用正确的工具时,这种方法效果很好。
请参阅最强大的转换方法包含要 git 的 Eclipse 项目的 CVS 存储库?
此外,完成后,请严格测试。
关于 git 分支,这不是聪明的部分。当您需要合并分支时,优势就来了。
I migrated our CVS repository a while back to git, by first converting to subversion and then to git. This worked well when using the right tooling for it.
See Most robust way to convert a CVS repository containing Eclipse projects to git?
Also, when done, test rigoriously.
Regarding git branching, that is not the smart part. The advantage come when you need to merge branches.
John Albin 在此处和此处 将为您完成整个转换(包括作者转换)。这些脚本并不完美(我在多个分支上遇到了一些问题,尤其是在使用 svn 外部时)。
Atlassian 实际上写了一个关于 svn 到 git 迁移的指南(他们在这些页面上也有很好的教程) )。
git 非常强大,但有一个警告:到目前为止,git 还没有像 svn:externals 这样简单的东西。还有其他选择(git subtree 和 git submodules),但它们从来没有像 svn externals 那样直观地工作(但这是另一个问题:在 stackoverflow 上环顾四周,你会发现许多与此主题相关的问题)
John Albin wrote some good scripts here and here that will do the whole conversion for you (including author conversion). The scripts are not perfect (I had some hickups with multiple branches and especially with svn externals).
Atlassian actually wrote a guide on the svn to git migration (and they have good tutorials on those pages too).
git is very powerfull but there is one caveat: up till now git doens't have anything so easy as svn:externals. There are alternatives (git subtree and git submodules) but they never work as intuitively as svn externals (but that is for another question: look around on stackoverflow you will find many questions related to this topic)