这就是我要做的。假设我的本地分支名为main。填补空白，因为我不记得确切的git svn命令，因为我已经有一段时间没有使用它了。

create in svn the branch that will be used for the project. use git svn to clone the svn repo you want (at least, the branch you want to use so that you do not have to fetch the other millions of revisions that we do not care about for this endeavor). checkout the svn branch in the new git repo. Add to this repository a remote that points to the original git repo you are using for the project. Let's say the remote is called the-real-stuff. git fetch the-real-stuff # so that we get to see what's in the real repo Given that this is the first time we will be pulling our code into the svn one, we have to trick git so that it can "merge" that code: git merge --allow-unrelated-histories the-real-stuff/main -m "Whatever comment I want in the svn revision". This will "merge" both branches locally. git svn dcommit so that you can push the content of the project as it is right now.

继续工作在原来的git回购。然后，当你想要推入svn时，去到git的svn clone，然后做:

git fetch the-real-stuff # get visibility to the changes in the original git repo
git merge the-real-stuff/main -m "Whatever comment I want to show on this svn revision"
git svn dcommit

这样就做完了。

我喜欢使用2个回购的想法，这样我们就不用用svn的东西来填充原始的回购，尽管有可能将整个东西保留在一个git回购中。

我想分享一个在WordPress社区中使用的很棒的工具，叫做Scatter

Git WordPress插件和一点理智的分散

这使得用户能够自动将他们的Git存储库发送到wordpress.org SVN。理论上，这段代码可以应用于任何SVN存储库。

直接使用git rebase将丢失第一次提交。Git以不同的方式对待它，并且不能对它进行重基。

有一个程序可以保存完整的历史记录:http://kerneltrap.org/mailarchive/git/2008/10/26/3815034

我将在这里转录解决方案，但学分是Björn。

初始化git-svn:

git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2

前缀为您提供了像“svn/trunk”这样的远程跟踪分支，这很好，因为如果您只将本地分支称为“trunk”，则不会得到模棱两可的名称。-s是标准trunk/tags/branches布局的快捷方式。

从SVN中获取初始的东西:

git svn fetch

现在查看你的根提交的散列(应该显示一个单独的提交):

git rev-list --parents master | grep '^.\{40\}$'

然后获取空trunk的哈希值commit:

git rev-parse svn/trunk

创建嫁接:

git replace --graft <root-commit-hash> <svn-trunk-commit-hash>

现在，“gitk”应该将svn/trunk显示为主分支所基于的第一个提交。

使移植物永久化:

git filter-branch -- ^svn/trunk --all

掉落移植物:

git replace -d <root-commit-hash>

Gitk应该仍然在master的祖先中显示svn/trunk。

在树干顶部线性化你的历史:

git svn rebase

现在"git svn dcommit -n"应该告诉你它将提交到trunk。

git svn dcommit

我只是想分享一些我的经验和公认的答案。我做了所有的步骤，在我运行最后一步之前，一切都很好:

git svn dcommit

$ git SVN dcommit 使用未初始化的值$u替换/usr/lib/perl5/vendor_perl/5.22/Git/SVN。下午101线。 在/usr/lib/perl5/vendor_perl/5.22/Git/SVN中使用未初始化的值$u(.)或字符串。下午101线。 refs/remotes/origin/HEAD:“https://192.168.2.101/svn/PROJECT_NAME”中没有找到

我找到了线程https://github.com/nirvdrum/svn2git/issues/50，最后我在101行下面的文件中应用了解决方案 /usr/lib/perl5/vendor_perl / 5.22 / Git / SVN.pm

我更换了

$u =~ s!^\Q$url\E(/|$)!! or die

with

if (!$u) {
    $u = $pathname;
} 
else {
       $u =~ s!^\Q$url\E(/|$)!! or die
      "$refname: '$url' not found in '$u'\n";
}

这解决了我的问题。

还有一个有效的序列(每个步骤都有一些注释):

Install git-svn and subversion toolkits: sudo apt-get install git-svn subversion Switch inside the PROJECT_FOLDER cd PROJECT_FOLDER Create the project path on the Subversion server (unfortunately the current git-svn plugin has a defect in comparison with TortoiseSVN). It is unable to store source code directly into the PROJECT_FOLDER. Instead, by default, it will upload all the code into PROJECT_FOLDER/trunk. svn mkdir --parents protocol:///path/to/repo/PROJECT_FOLDER/trunk -m "creating git repo placeholder"

在这里，中继在路径的末端是强制性的

Initialize the git-svn plugin context inside the .git folder git svn init -s protocol:///path/to/repo/PROJECT_FOLDER This is the place where trunk at the end of the path is unnecessary Fetch an empty Subversion repository information git svn fetch This step is helping to synchronize the Subversion server with the git-svn plugin. This is the moment when git-svn plugin establishes remotes/origin path and associates it with the trunk subfolder on the server side. Rebase old Git commits happened before the git-svn plugin became involved in the process (this step is optional) git rebase origin/trunk Add new/modified files to commit (this step is regular for Git activities and is optional) git add . Commit freshly added files into the local Git repository (this step is optional and is only applicable if step 7 has been used): git commit -m "Importing Git repository" Pushing all the project changes history into the Subversion server: git svn dcommit

我也需要这个，在Bombe的回答的帮助下，再加上一些摆弄，我让它工作了。下面是食谱:

导入Git -> Subversion

1. cd /path/to/git/localrepo
2. svn mkdir --parents protocol:///path/to/repo/PROJECT/trunk -m "Importing git repo"
3. git svn init protocol:///path/to/repo/PROJECT -s
4. git svn fetch
5. git rebase origin/trunk
5.1.  git status
5.2.  git add (conflicted-files)
5.3.  git rebase --continue
5.4.  (repeat 5.1.)
6. git svn dcommit

在第3条之后，你会收到这样一条神秘的消息:

使用更高级别的URL: protocol:///path/to/repo/PROJECT => protocol:///path/to/repo

忽略它。

当您运行#5时，您可能会遇到冲突。通过添加状态为“unmerged”的文件并恢复rebase来解决这些问题。最终，你会完成;然后使用dcommit同步回SVN存储库。这是所有。

保持存储库同步

您现在可以使用以下命令从SVN同步到Git:

git svn fetch
git rebase trunk

要从Git同步到SVN，请使用:

git svn dcommit

最后请注意

在应用到活动存储库之前，您可能希望在本地副本上尝试这一点。您可以将Git存储库复制到临时位置;只需使用cp -r，因为所有数据都在存储库本身中。然后你可以建立一个基于文件的测试存储库，使用:

svnadmin create /home/name/tmp/test-repo

并使用以下命令检查工作副本:

svn co file:///home/name/tmp/test-repo svn-working-copy

这样可以让你在做出任何持久的改变之前先玩一玩。

附录:如果你搞砸了git svn init

如果您不小心使用错误的URL运行了git svn init，并且您不够聪明，没有对您的工作进行备份(不要问…)，那么您不能再次运行相同的命令。但是，您可以通过发出以下命令来撤销更改:

rm -rf .git/svn
edit .git/config

删除section [svn-remote "svn"] section。

然后可以重新运行git svn init。