习惯了 Git 在工作过程结束后，您可以创建一些特征分支，完成相关的开发工作，然后合并它们。如果要用 git svn 向 Subversion 推送内容，最好每次用衍合并成单个分支，而不是直接合并。使用衍合物的原因是 Subversion 与线性历史不同，只有一个线性历史 Git 那样处理合并，所以 Git svn 将快照转换为 Subversion 的 commit 只能包括第一个祖先。

假设分支的历史如下：创一个 experiment 分支，提交两次，然后合并 master 。在 dcommit 输出如下：

$ git svn dcommit

Committing to file:///tmp/test-svn/trunk …

M CHANGES.txt

Committed r85

M CHANGES.txt

r85 = 4bfebeec434d156c36f2bcd18f4e3d97dc3269a2 (trunk)

No changes between current HEAD and refs/remotes/trunk

Resetting to the latest refs/remotes/trunk

COPYING.txt: locally modified

INSTALL.txt: locally modified

M COPYING.txt

M INSTALL.txt

Committed r86

M INSTALL.txt

M COPYING.txt

r86 = 2647f6b86ccfcaad4ec58c520e369ec81f7c283c (trunk)

No changes between current HEAD and refs/remotes/trunk

Resetting to the latest refs/remotes/trunk

在一个包含了合并历史的分支上使用 dcommit 可以成功运行，不过在 Git 在项目的历史中，它没有重写你 experiment 两个分支 commit ——另一方面，这些变化出现了 SVN 同一合并版本 commit 中。

当别人克隆项目时，他们只能看到合并 commit 包括所有已经发生的修改；他们不知道修改后的作者和时间。

Subversion 的分支和 Git 不同的；避免过度使用可能是最好的解决方案。但是，使用 git svn 不同的创建和提交 Subversion 分支机构仍然可行。

要在 Subversion 中建立一个新分支，需要运行 git svn branch [分支名] ：

$ git svn branch opera

Copying file:///tmp/test-svn/trunk at r87 to file:///tmp/test-svn/branches/opera…

Found possible branch point: file:///tmp/test-svn/trunk => \

file:///tmp/test-svn/branches/opera, 87

Found branch parent: (opera) 1f6bfe471083cbca06ac8d4176f7ad4de0d62e5f

Following parent with do_switch

Successfully followed parent

r89 = 9b6fe0b90c5c9adf9165f700897518dbc54a7cbf (opera)

这相当于在 Subversion 中的 svn copy trunk branches/opera 命令是对的 Subversion 相关操作服务器。值得注意的是，它没有检测到并转换到分支；如果现在提交，将提交到服务器上 trunk， 而非 opera。

Git 历史上通过搜索提交 Subversion 决定分支的头部 dcommit 目的地——应该只有一个，那就是最近一次包含在当前分支历史上 git-svn-id 的提交。

如果需要同时提交多个分支，可以导入 Subversion 其他分支 commit 以此分支为基础 dcommit 目的地本地分支。例如，你想要一个并行维护 opera 可运行的分支

$ git branch opera remotes/opera

然后，如果要把 opera 分支并入 trunk （本地的 master 分支），可以使用普通的 git merge。不过最好提供一条描述提交的信息（通过 -m），否则这次合并的记录是 Merge branch opera ，而不是任何有用的东西。

记住，虽然使用了 git merge 来进行这次操作，并且合并过程可能比使用 Subversion 简单一些（因为 Git 会自动找到适合的合并基础），这并不是一次普通的 Git 合并提交。最终它将被推送回 commit 无法包含多个祖先的 Subversion 服务器上；因而在推送之后，它将变成一个包含了所有在其他分支上做出的改变的单一 commit。把一个分支合并到另一个分支以后，你没法像在 Git 中那样轻易的回到那个分支上继续工作。提交时运行的 dcommit 命令擦除了全部有关哪个分支被并入的信息，因而以后的合并基础计算将是不正确的—— dcommit 让 git merge 的结果变得类似于 git merge --squash。不幸的是，我们没有什么好办法来避免该情况—— Subversion 无法储存这个信息，所以在使用它作为服务器的时候你将永远为这个缺陷所困。为了不出现这种问题，在把本地分支（本例中的 opera）并入 trunk 以后应该立即将其删除。

git svn 工具集合了若干个与 Subversion 类似的功能，对应的命令可以简化向 Git 的转化过程。下面这些命令能实现 Subversion 的这些功能。

习惯了 Subversion 的人可能想以 SVN 的风格显示历史，运行 git svn log 可以让提交历史显示为 SVN 格式：

$ git svn log

r87 | schacon | 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009) | 2 lines

autogen change

r86 | schacon | 2009-05-02 16:00:21 -0700 (Sat, 02 May 2009) | 2 lines

Merge branch ‘experiment’

r85 | schacon | 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) | 2 lines

updated the changelog

关于 git svn log ，有两点需要注意。首先，它可以离线工作，不像 svn log 命令，需要向 Subversion 服务器索取数据。其次，它仅仅显示已经提交到 Subversion 服务器上的 commit。在本地尚未 dcommit 的 Git 数据不会出现在这里；其他人向 Subversion 服务器新提交的数据也不会显示。等于说是显示了最近已知 Subversion 服务器上的状态。

类似 git svn log 对 git log 的模拟，svn annotate 的等效命令是 git svn blame [文件名]。其输出如下：

$ git svn blame README.txt

2 temporal Protocol Buffers - Google’s data interchange format

2 temporal Copyright 2008 Google Inc.

2 temporal http://code.google.com/apis/protocolbuffers/

2 temporal

22 temporal C++ Installation - Unix

22 temporal =======================

2 temporal

79 schacon Committing in git-svn.

78 schacon

2 temporal To build and install the C++ Protocol Buffer runtime and the Protocol

2 temporal Buffer compiler (protoc) execute the following:

2 temporal

同样，它不显示本地的 Git 提交以及 Subversion 上后来更新的内容。

还可以使用 git svn info 来获取与运行 svn info 类似的信息：

$ git svn info

Path: .

URL: https://schacon-test.googlecode.com/svn/trunk

Repository Root: https://schacon-test.googlecode.com/svn

Repository UUID: 4c93b258-373f-11de-be05-5f7a86268029

Revision: 87

Node Kind: directory

Schedule: normal

Last Changed Author: schacon

Last Changed Rev: 87

Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009)

它与 blame 和 log 的相同点在于离线运行以及只更新到最后一次与 Subversion 服务器通信的状态。

假如克隆了一个包含了 svn:ignore 属性的 Subversion 仓库，就有必要建立对应的 .gitignore 文件来防止意外提交一些不应该提交的文件。git svn 有两个有益于改善该问题的命令。第一个是 git svn create-ignore，它自动建立对应的 .gitignore 文件，以便下次提交的时候可以包含它。

第二个命令是 git svn show-ignore，它把需要放进 .gitignore 文件中的内容打印到标准输出，方便我们把输出重定向到项目的黑名单文件：

$ git svn show-ignore > .git/info/exclude

这样一来，避免了 .gitignore 对项目的干扰。如果你是一个 Subversion 团队里唯一的 Git 用户，而其他队友不喜欢项目包含 .gitignore，该方法是你的不二之选。

git svn 工具集在当前不得不使用 Subversion 服务器或者开发环境要求使用 Subversion 服务器的时候格外有用。不妨把它看成一个跛脚的 Git，然而，你还是有可能在转换过程中碰到一些困惑你和合作者们的迷题。为了避免麻烦，试着遵守如下守则：

• 保持一个不包含由 git merge 生成的 commit 的线性提交历史。将在主线分支外进行的开发通通衍合回主线；避免直接合并。

• 不要单独建立和使用一个 Git 服务来搞合作。可以为了加速新开发者的克隆进程建立一个，但是不要向它提供任何不包含 git-svn-id 条目的内容。甚至可以添加一个 pre-receive 挂钩来在每一个提交信息中查找 git-svn-id 并拒绝提交那些不包含它的 commit。

如果遵循这些守则，在 Subversion 上工作还可以接受。然而，如果能迁徙到真正的 Git 服务器，则能为团队带来更多好处。

8.2 迁移到 Git

你将学习到如何从专业重量级的版本控制系统中导入数据—— Subversion 和 Perforce —— 因为据我所知这二者的用户是（向 Git）转换的主要群体，而且 Git 为此二者附带了高质量的转换工具。

读过前一节有关 git svn 的内容以后，你应该能轻而易举的根据其中的指导来 git svn clone 一个仓库了；然后，停止 Subversion 的使用，向一个新 Git server 推送，并开始使用它。想保留历史记录，所花的时间应该不过就是从 Subversion 服务器拉取数据的时间（可能要等上好一会就是了）。

然而，这样的导入并不完美；而且还要花那么多时间，不如干脆一次把它做对！首当其冲的任务是作者信息。在 Subversion，每个提交者在都在主机上有一个用户名，记录在提交信息中。上节例子中多处显示了 schacon ，比如 blame 的输出以及 git svn log。如果想让这条信息更好的映射到 Git 作者数据里，则需要 从 Subversion 用户名到 Git 作者的一个映射关系。建立一个叫做 user.txt 的文件，用如下格式表示映射关系：

schacon = Scott Chacon schacon@geemail.com

selse = Someo Nelse selse@geemail.com

通过该命令可以获得 SVN 作者的列表：

$ svn log --xml | grep -P “^<author” | sort -u | \

perl -pe ‘s/(.*?)</author>/$1 = /’ > users.txt

它将输出 XML 格式的日志——你可以找到作者，建立一个单独的列表，然后从 XML 中抽取出需要的信息。（显而易见，本方法要求主机上安装了grep，sort 和 perl.）然后把输出重定向到 user.txt 文件，然后就可以在每一项的后面添加相应的 Git 用户数据。

为 git svn 提供该文件可以然它更精确的映射作者数据。你还可以在 clone 或者 init后面添加 --no-metadata 来阻止 git svn 包含那些 Subversion 的附加信息。这样 import 命令就变成了：

$ git-svn clone http://my-project.googlecode.com/svn/ \

–authors-file=users.txt --no-metadata -s my_project

现在 my_project 目录下导入的 Subversion 应该比原来整洁多了。原来的 commit 看上去是这样：

commit 37efa680e8473b615de980fa935944215428a35a

Author: schacon schacon@4c93b258-373f-11de-be05-5f7a86268029

Date: Sun May 3 00:12:22 2009 +0000

fixed install - go to trunk

git-svn-id: https://my-project.googlecode.com/svn/trunk@94 4c93b258-373f-11de-

be05-5f7a86268029

现在是这样：

commit 03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2

Author: Scott Chacon schacon@geemail.com

Date: Sun May 3 00:12:22 2009 +0000

fixed install - go to trunk

不仅作者一项干净了不少，git-svn-id 也就此消失了。

你将了解到的下一个被导入的系统是 Perforce. Git 发行的时候同时也附带了一个 Perforce 导入脚本，不过它是包含在源码的 contrib 部分——而不像 git svn 那样默认可用。运行它之前必须获取 Git 的源码，可以在 git.kernel.org 下载：

$ git clone git://git.kernel.org/pub/scm/git/git.git

$ cd git/contrib/fast-import

在这个 fast-import 目录下，应该有一个叫做 git-p4 的 Python 可执行脚本。主机上必须装有 Python 和 p4 工具该导入才能正常进行。例如，你要从 Perforce 公共代码仓库（译注： Perforce Public Depot，Perforce 官方提供的代码寄存服务）导入 Jam 工程。为了设定客户端，我们要把 P4PORT 环境变量 export 到 Perforce 仓库：

$ export P4PORT=public.perforce.com:1666

运行 git-p4 clone 命令将从 Perforce 服务器导入 Jam 项目，我们需要给出仓库和项目的路径以及导入的目标路径：

$ git-p4 clone //public/jam/src@all /opt/p4import

Importing from //public/jam/src@all into /opt/p4import

Reinitialized existing Git repository in /opt/p4import/.git/

Import destination: refs/remotes/p4/master

Importing revision 4409 (100%)

现在去 /opt/p4import 目录运行一下 git log ，就能看到导入的成果：

$ git log -2

commit 1fd4ec126171790efd2db83548b85b1bbbc07dc2

Author: Perforce staff support@perforce.com

Date: Thu Aug 19 10:18:45 2004 -0800

Drop ‘rc3’ moniker of jam-2.5. Folded rc2 and rc3 RELNOTES into

the main part of the document. Built new tar/zip balls.

Only 16 months later.

[git-p4: depot-paths = “//public/jam/src/”: change = 4409]

commit ca8870db541a23ed867f38847eda65bf4363371d

Author: Richard Geiger rmg@perforce.com

Date: Tue Apr 22 20:51:34 2003 -0800

Update derived jamgram.c

[git-p4: depot-paths = “//public/jam/src/”: change = 3108]

每一个 commit 里都有一个 git-p4 标识符。这个标识符可以保留，以防以后需要引用 Perforce 的修改版本号。然而，如果想删除这些标识符，现在正是时候——在开启新仓库之前。可以通过 git filter-branch 来批量删除这些标识符：

$ git filter-branch --msg-filter ’

sed -e “/^[git-p4:/d”

’

Rewrite 1fd4ec126171790efd2db83548b85b1bbbc07dc2 (123/123)

Ref ‘refs/heads/master’ was rewritten

现在运行一下 git log，你会发现这些 commit 的 SHA-1 校验值都发生了改变，而那些 git-p4 字串则从提交信息里消失了：

$ git log -2

commit 10a16d60cffca14d454a15c6164378f4082bc5b0

Author: Perforce staff support@perforce.com

Date: Thu Aug 19 10:18:45 2004 -0800

Drop ‘rc3’ moniker of jam-2.5. Folded rc2 and rc3 RELNOTES into

the main part of the document. 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 Built new tar/zip balls.

Only 16 months later.

commit 2b6c6db311dd76c34c66ec1c40a49405e6b527b2

Author: Richard Geiger rmg@perforce.com

Date: Tue Apr 22 20:51:34 2003 -0800

Update derived jamgram.c

至此导入已经完成，可以开始向新的 Git 服务器推送了。

如果先前的系统不是 Subversion 或 Perforce 之一，先上网找一下有没有与之对应的导入脚本——导入 CVS，Clear Case，Visual Source Safe，甚至存档目录的导入脚本已经存在。假如这些工具都不适用，或者使用的工具很少见，抑或你需要导入过程具有更多可制定性，则应该使用 git fast-import。该命令从标准输入读取简单的指令来写入具体的 Git 数据。这样创建 Git 对象比运行纯 Git 命令或者手动写对象要简单的多（更多相关内容见第九章）。通过它，你可以编写一个导入脚本来从导入源读取必要的信息，同时在标准输出直接输出相关指示。你可以运行该脚本并把它的输出管道连接到 git fast-import。

下面演示一下如何编写一个简单的导入脚本。假设你在进行一项工作，并且按时通过把工作目录复制为以时间戳 back_YY_MM_DD 命名的目录来进行备份，现在你需要把它们导入 Git 。目录结构如下：

$ ls /opt/import_from

back_2009_01_02

back_2009_01_04

back_2009_01_14

back_2009_02_03

current

为了导入到一个 Git 目录，我们首先回顾一下 Git 储存数据的方式。你可能还记得，Git 本质上是一个 commit 对象的链表，每一个对象指向一个内容的快照。而这里需要做的工作就是告诉 fast-import 内容快照的位置，什么样的 commit 数据指向它们，以及它们的顺序。我们采取一次处理一个快照的策略，为每一个内容目录建立对应的 commit ，每一个 commit 与之前的建立链接。

正如在第七章 “Git 执行策略一例” 一节中一样，我们将使用 Ruby 来编写这个脚本，因为它是我日常使用的语言而且阅读起来简单一些。你可以用任何其他熟悉的语言来重写这个例子——它仅需要把必要的信息打印到标准输出而已。同时，如果你在使用 Windows，这意味着你要特别留意不要在换行的时候引入回车符（译注：carriage returns，Windows 换行时加入的符号，通常说的 \r ）—— Git 的 fast-import 对仅使用换行符（LF）而非 Windows 的回车符（CRLF）要求非常严格。

首先，进入目标目录并且找到所有子目录，每一个子目录将作为一个快照被导入为一个 commit。我们将依次进入每一个子目录并打印所需的命令来导出它们。脚本的主循环大致是这样：

last_mark = nil

Dir.chdir(ARGV[0]) do

Dir.glob(“*”).each do |dir|

next if File.file?(dir)

Dir.chdir(dir) do

last_mark = print_export(dir, last_mark)

end

end

end

我们在每一个目录里运行 print_export ，它会取出上一个快照的索引和标记并返回本次快照的索引和标记；由此我们就可以正确的把二者连接起来。“标记（mark）” 是 fast-import 中对 commit 标识符的叫法；在创建 commit 的同时，我们逐一赋予一个标记以便以后在把它连接到其他 commit 时使用。因此，在 print_export 方法中要做的第一件事就是根据目录名生成一个标记：

mark = convert_dir_to_mark(dir)

实现该函数的方法是建立一个目录的数组序列并使用数组的索引值作为标记，因为标记必须是一个整数。这个方法大致是这样的：

$marks = []

def convert_dir_to_mark(dir)

if !$marks.include?(dir)

$marks << dir

end

($marks.index(dir) + 1).to_s

end

有了整数来代表每个 commit，我们现在需要提交附加信息中的日期。由于日期是用目录名表示的，我们就从中解析出来。print_export 文件的下一行将是：

date = convert_dir_to_date(dir)

而 convert_dir_to_date 则定义为

def convert_dir_to_date(dir)

if dir == ‘current’

return Time.now().to_i

else

dir = dir.gsub(‘back_’, ‘’)

(year, month, day) = dir.split(‘_’)

return Time.local(year, month, day).to_i

end

end

它为每个目录返回一个整型值。提交附加信息里最后一项所需的是提交者数据，我们在一个全局变量中直接定义之：

$author = ‘Scott Chacon schacon@example.com’

我们差不多可以开始为导入脚本输出提交数据了。第一项信息指明我们定义的是一个 commit 对象以及它所在的分支，随后是我们生成的标记，提交者信息以及提交备注，然后是前一个 commit 的索引，如果有的话。代码大致这样：

puts ‘commit refs/heads/master’

puts ‘mark :’ + mark

puts “committer #{$author} #{date} -0700”

export_data('imported from ’ + dir)

puts ‘from :’ + last_mark if last_mark

时区（-0700）处于简化目的使用硬编码。如果是从其他版本控制系统导入，则必须以变量的形式指明时区。 提交备注必须以特定格式给出：

data (size)\n(contents)