-
1. 起步
-
2. Git 基础
-
3. Git 分支
-
4. 服务器上的 Git
- 4.1 协议
- 4.2 在服务器上部署 Git
- 4.3 生成 SSH 公钥
- 4.4 架设服务器
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 第三方托管服务
- 4.10 小结
-
5. 分布式 Git
-
A1. 附录 A: Git 在其他环境
- A1.1 图形界面
- A1.2 Visual Studio 中的 Git
- A1.3 Visual Studio Code 中的 Git
- A1.4 IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine 中的 Git
- A1.5 Sublime Text 中的 Git
- A1.6 Bash 中的 Git
- A1.7 Zsh 中的 Git
- A1.8 PowerShell 中的 Git
- A1.9 小结
-
A2. 附录 B: 在应用程序中嵌入 Git
-
A3. 附录 C: Git 命令
9.2 Git 与其他系统 - 迁移到 Git
迁移到 Git
如果你现有的代码库使用其他版本控制系统 (VCS),但决定开始使用 Git,那么无论如何你都必须迁移你的项目。本节将介绍一些常见系统的导入工具,然后演示如何开发自己的自定义导入工具。你将学习如何从几个主流的专业 SCM 系统导入数据,因为它们代表了转用 Git 的大多数用户,而且这些系统的高质量工具也随处可见。
Subversion
如果你阅读了上一节关于使用 git svn 的内容,你可以轻松地使用这些说明通过 git svn clone 克隆一个仓库;然后,停止使用 Subversion 服务器,推送到新的 Git 服务器,并开始使用它。如果你想保留历史记录,只要能从 Subversion 服务器中拉取数据,就能实现这一点(可能需要一些时间)。
然而,这种导入并不完美;由于过程非常漫长,你最好一次性做对。第一个问题是作者信息。在 Subversion 中,每个提交者在系统上都有一个用户,并记录在提交信息中。上一节的示例在 blame 输出和 git svn log 等地方显示了 schacon。如果你想将其映射为更完善的 Git 作者数据,你需要建立一份 Subversion 用户到 Git 作者的映射表。创建一个名为 users.txt 的文件,并按如下格式编写映射:
schacon = Scott Chacon <schacon@geemail.com>
selse = Someo Nelse <selse@geemail.com>
要获取 SVN 使用的作者姓名列表,你可以运行以下命令:
$ svn log --xml --quiet | grep author | sort -u | \
perl -pe 's/.*>(.*?)<.*/$1 = /'
这会生成 XML 格式的日志输出,然后仅保留包含作者信息的行,去除重复项,并剥离 XML 标签。显然,这只能在安装了 grep、sort 和 perl 的机器上运行。然后,将输出重定向到 users.txt 文件中,以便在每个条目旁添加对应的 Git 用户数据。
|
注意
|
如果你是在 Windows 机器上尝试此操作,这正是你会遇到麻烦的地方。微软在 https://learn.microsoft.com/en-us/azure/devops/repos/git/perform-migration-from-svn-to-git 提供了很好的建议和示例。 |
你可以将此文件提供给 git svn,以帮助其更准确地映射作者数据。你还可以通过向 clone 或 init 命令传递 --no-metadata 参数,告诉 git svn 不要包含 Subversion 通常导入的元数据。这些元数据包括 Git 在导入期间生成的每个提交信息中的 git-svn-id。这可能会使你的 Git 日志变得冗长且有些混乱。
|
注意
|
如果你希望将 Git 仓库中的提交同步回原始 SVN 仓库,则需要保留这些元数据。如果你不希望在提交日志中看到这些同步信息,可以随意省略 |
这会让你的 import 命令看起来像这样:
$ git svn clone http://my-project.googlecode.com/svn/ \
--authors-file=users.txt --no-metadata --prefix "" -s my_project
$ cd my_project
现在,你的 my_project 目录中应该有一个更好的 Subversion 导入结果。相比于原来看起来这样的提交:
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
不仅 Author 字段看起来好多了,而且 git-svn-id 也不见了。
你还应该在导入后进行一些清理工作。首先,你应该清理 git svn 设置的奇怪引用。先移动标签使其成为真正的标签而不是远程分支,然后移动其余的分支使其成为本地分支。
要将标签移动为标准的 Git 标签,请运行:
$ for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags\//} $t && git branch -D -r $t; done
这会将以 refs/remotes/tags/ 开头的远程分支引用转换为真实的(轻量级)标签。
接下来,将 refs/remotes 下的其余引用移动为本地分支:
$ for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git branch $b refs/remotes/$b && git branch -D -r $b; done
有时你可能会看到一些后缀为 @xxx(xxx 是数字)的额外分支,而在 Subversion 中你只能看到一个分支。这实际上是 Subversion 中称为“挂起修订版本 (peg-revisions)”的功能,Git 没有对应的语法。因此,git svn 只是简单地将 SVN 版本号添加到分支名称中,就像你在 SVN 中为了定位该分支的特定版本所写的那样。如果你不再关心这些版本,只需将它们删除:
$ for p in $(git for-each-ref --format='%(refname:short)' | grep @); do git branch -D $p; done
现在,所有旧分支都是真正的 Git 分支,所有旧标签也都是真正的 Git 标签。
最后还有一件事需要清理。不幸的是,git svn 会创建一个名为 trunk 的额外分支,它映射到 Subversion 的默认分支,但 trunk 引用指向与 master 相同的地方。由于 master 更符合 Git 的惯用法,删除额外分支的方法如下:
$ git branch -d trunk
最后一步是将你的新 Git 服务器添加为远程仓库并进行推送。以下是将服务器添加为远程仓库的示例:
$ git remote add origin git@my-git-server:myrepository.git
因为你希望所有的分支和标签都上传上去,现在可以运行:
$ git push origin --all
$ git push origin --tags
这样,所有的分支和标签都应该以整洁的方式导入到了你的新 Git 服务器上。
Mercurial
由于 Mercurial 和 Git 在版本表示模型上非常相似,且 Git 更具灵活性,因此使用名为 "hg-fast-export" 的工具将仓库从 Mercurial 转换为 Git 是相当直接的,你需要获取一份该工具的副本:
$ git clone https://github.com/frej/fast-export.git
转换的第一步是完整克隆你想要转换的 Mercurial 仓库:
$ hg clone <remote repo URL> /tmp/hg-repo
下一步是创建作者映射文件。对于变更集作者字段的内容,Mercurial 比 Git 更宽松,所以现在是一个整理的好时机。在 bash shell 中,可以使用一行命令生成此文件:
$ cd /tmp/hg-repo
$ hg log | grep user: | sort | uniq | sed 's/user: *//' > ../authors
根据你项目的历史长短,这可能需要几秒钟时间。完成后,/tmp/authors 文件看起来会像这样:
bob
bob@localhost
bob <bob@company.com>
bob jones <bob <AT> company <DOT> com>
Bob Jones <bob@company.com>
Joe Smith <joe@company.com>
在此示例中,同一个人(Bob)在四个不同的名字下创建了变更集,其中一个名字看起来是正确的,而另一个对于 Git 提交则是完全无效的。Hg-fast-export 允许我们将每一行转换为规则来修复此问题:"<input>"="<output>",将 <input> 映射为 <output>。在 <input> 和 <output> 字符串内部,支持所有 Python string_escape 编码所理解的转义序列。如果作者映射文件不包含匹配的 <input>,该作者将被原样传给 Git。如果所有用户名看起来都没问题,我们甚至不需要这个文件。在本例中,我们希望文件看起来像这样:
"bob"="Bob Jones <bob@company.com>"
"bob@localhost"="Bob Jones <bob@company.com>"
"bob <bob@company.com>"="Bob Jones <bob@company.com>"
"bob jones <bob <AT> company <DOT> com>"="Bob Jones <bob@company.com>"
当 Mercurial 的分支或标签名称在 Git 中不被允许时,可以使用同样的映射文件来重命名它们。
下一步是创建我们的新 Git 仓库,并运行导出脚本:
$ git init /tmp/converted
$ cd /tmp/converted
$ /tmp/fast-export/hg-fast-export.sh -r /tmp/hg-repo -A /tmp/authors
-r 标志告诉 hg-fast-export 在哪里找到要转换的 Mercurial 仓库,-A 标志告诉它去哪里找到作者映射文件(分支和标签映射文件分别由 -B 和 -T 标志指定)。该脚本会解析 Mercurial 变更集并将它们转换为 Git 的 "fast-import" 功能所需的脚本(我们稍后会详细讨论)。这需要一点时间(尽管比网络传输快得多),输出会相当详尽:
$ /tmp/fast-export/hg-fast-export.sh -r /tmp/hg-repo -A /tmp/authors
Loaded 4 authors
master: Exporting full revision 1/22208 with 13/0/0 added/changed/removed files
master: Exporting simple delta revision 2/22208 with 1/1/0 added/changed/removed files
master: Exporting simple delta revision 3/22208 with 0/1/0 added/changed/removed files
[…]
master: Exporting simple delta revision 22206/22208 with 0/4/0 added/changed/removed files
master: Exporting simple delta revision 22207/22208 with 0/2/0 added/changed/removed files
master: Exporting thorough delta revision 22208/22208 with 3/213/0 added/changed/removed files
Exporting tag [0.4c] at [hg r9] [git :10]
Exporting tag [0.4d] at [hg r16] [git :17]
[…]
Exporting tag [3.1-rc] at [hg r21926] [git :21927]
Exporting tag [3.1] at [hg r21973] [git :21974]
Issued 22315 commands
git-fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects: 120000
Total objects: 115032 ( 208171 duplicates )
blobs : 40504 ( 205320 duplicates 26117 deltas of 39602 attempts)
trees : 52320 ( 2851 duplicates 47467 deltas of 47599 attempts)
commits: 22208 ( 0 duplicates 0 deltas of 0 attempts)
tags : 0 ( 0 duplicates 0 deltas of 0 attempts)
Total branches: 109 ( 2 loads )
marks: 1048576 ( 22208 unique )
atoms: 1952
Memory total: 7860 KiB
pools: 2235 KiB
objects: 5625 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit = 8589934592
pack_report: pack_used_ctr = 90430
pack_report: pack_mmap_calls = 46771
pack_report: pack_open_windows = 1 / 1
pack_report: pack_mapped = 340852700 / 340852700
---------------------------------------------------------------------
$ git shortlog -sn
369 Bob Jones
365 Joe Smith
基本上就是这样了。所有的 Mercurial 标签已被转换为 Git 标签,Mercurial 分支和书签已被转换为 Git 分支。现在你已准备好将仓库推送到其新的服务器端主页。
$ git remote add origin git@my-git-server:myrepository.git
$ git push origin --all
Perforce
接下来要导入的系统是 Perforce。正如我们上面讨论的,有两种方式让 Git 和 Perforce 通信:git-p4 和 Perforce Git Fusion。
Perforce Git Fusion
Git Fusion 让这个过程相当轻松。只需使用配置文件配置你的项目设置、用户映射和分支(如 Git Fusion 中所讨论),然后克隆仓库即可。Git Fusion 留给你的就是一个看起来像原生的 Git 仓库,如果需要,它可以立即推送到原生的 Git 主机。如果你愿意,甚至可以使用 Perforce 作为你的 Git 主机。
Git-p4
Git-p4 也可以作为导入工具。例如,我们将从 Perforce 公共仓库导入 Jam 项目。要设置你的客户端,必须导出 P4PORT 环境变量以指向 Perforce 仓库:
$ export P4PORT=public.perforce.com:1666
|
注意
|
为了跟着操作,你需要一个可连接的 Perforce 仓库。我们在示例中使用 public.perforce.com 的公共仓库,但你可以使用任何你有权限访问的仓库。 |
运行 git p4 clone 命令从 Perforce 服务器导入 Jam 项目,提供仓库路径、项目路径以及你想要导入到的路径:
$ git-p4 clone //guest/perforce_software/jam@all p4import
Importing from //guest/perforce_software/jam@all into p4import
Initialized empty Git repository in /private/tmp/p4import/.git/
Import destination: refs/remotes/p4/master
Importing revision 9957 (100%)
这个特定的项目只有一个分支,但如果你有配置了分支视图(或仅仅是一组目录)的分支,可以使用 git p4 clone 的 --detect-branches 标志来同时导入项目的所有分支。有关此内容的更多详细信息,请参阅 分支 (Branching)。
此时你几乎完成了。如果你进入 p4import 目录并运行 git log,可以看到已导入的内容:
$ git log -2
commit e5da1c909e5db3036475419f6379f2c73710c4e6
Author: giles <giles@giles@perforce.com>
Date: Wed Feb 8 03:13:27 2012 -0800
Correction to line 355; change </UL> to </OL>.
[git-p4: depot-paths = "//public/jam/src/": change = 8068]
commit aa21359a0a135dda85c50a7f7cf249e4f7b8fd98
Author: kwirth <kwirth@perforce.com>
Date: Tue Jul 7 01:35:51 2009 -0800
Fix spelling error on Jam doc page (cummulative -> cumulative).
[git-p4: depot-paths = "//public/jam/src/": change = 7304]
你可以看到 git-p4 在每个提交信息中都留下了标识符。保留该标识符以便日后引用 Perforce 变更编号是可以的。然而,如果你想删除该标识符,现在是时候了——在你开始在新仓库工作之前。你可以使用 git filter-branch 批量删除标识字符串:
$ git filter-branch --msg-filter 'sed -e "/^\[git-p4:/d"'
Rewrite e5da1c909e5db3036475419f6379f2c73710c4e6 (125/125)
Ref 'refs/heads/master' was rewritten
如果你运行 git log,可以看到提交的所有 SHA-1 校验和都已经改变,但提交信息中不再有 git-p4 字符串了:
$ git log -2
commit b17341801ed838d97f7800a54a6f9b95750839b7
Author: giles <giles@giles@perforce.com>
Date: Wed Feb 8 03:13:27 2012 -0800
Correction to line 355; change </UL> to </OL>.
commit 3e68c2e26cd89cb983eb52c024ecdfba1d6b3fff
Author: kwirth <kwirth@perforce.com>
Date: Tue Jul 7 01:35:51 2009 -0800
Fix spelling error on Jam doc page (cummulative -> cumulative).
你的导入已准备好推送到新的 Git 服务器。
自定义导入器
如果你的系统不属于上述情况,你应该在网上搜索一下导入器——许多其他系统(包括 CVS、Clear Case、Visual Source Safe,甚至是归档目录)都有高质量的导入器。如果这些工具都不适合你,或者你使用的工具较为冷门,或者你需要更个性化的导入过程,你应该使用 git fast-import。此命令从标准输入读取简单的指令来写入具体的 Git 数据。通过这种方式创建 Git 对象比运行原生 Git 命令或尝试手动编写原始对象要容易得多(更多信息请参见 Git 内部原理)。通过这种方式,你可以编写一个导入脚本,从你正在导入的系统中读取必要的信息,并向标准输出打印简单的指令。然后,你可以运行该程序并通过管道将其输出传输给 git fast-import。
为了快速演示,我们将编写一个简单的导入器。假设你在 current 目录中工作,偶尔通过将目录复制到带时间戳的 back_YYYY_MM_DD 备份目录中来备份项目,并且你想将其导入 Git。你的目录结构如下所示:
$ ls /opt/import_from
back_2014_01_02
back_2014_01_04
back_2014_01_14
back_2014_02_03
current
为了导入一个 Git 目录,你需要回顾一下 Git 是如何存储数据的。你可能还记得,Git 本质上是一个提交对象的链表,这些对象指向内容的快照。你所要做的就是告诉 fast-import 内容快照是什么、指向它们的提交数据是什么、以及它们的顺序。你的策略是依次遍历快照,并用每个目录的内容创建提交,将每个提交链接回上一个。
正如我们在 Git 强制策略示例 中所做的那样,我们将用 Ruby 编写此脚本,因为我们通常使用它,而且它往往很容易阅读。你可以用你熟悉的任何语言轻易地编写此示例——它只需要将适当的信息打印到 stdout 即可。另外,如果你在 Windows 上运行,需要特别注意不要在行尾引入回车符——git fast-import 对只想要换行符 (LF) 而非 Windows 使用的回车换行符 (CRLF) 非常挑剔。
首先,你要进入目标目录并识别每个子目录,每一个都是你想作为提交导入的快照。你要进入每个子目录并打印导出它所需的命令。你的基本主循环看起来如下:
last_mark = nil
# loop through the directories
Dir.chdir(ARGV[0]) do
Dir.glob("*").each do |dir|
next if File.file?(dir)
# move into the target directory
Dir.chdir(dir) do
last_mark = print_export(dir, last_mark)
end
end
end
你在每个目录中运行 print_export,它接收上一个快照的清单和标记,并返回当前快照的清单和标记;这样你就可以正确地链接它们。“标记 (Mark)”是 git fast-import 中你给提交赋予的标识符;当你创建提交时,给每个提交一个标记,以便从其他提交中引用它。因此,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
现在你有了提交的整数表示,你需要为提交元数据提供日期。因为日期体现在目录名中,所以你需要解析它。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 = 'John Doe <john@example.com>'
现在你已准备好开始为你的导入器打印提交数据。初始信息说明你正在定义一个提交对象及其所在分支,随后是你生成的标记、提交者信息和提交消息,然后是前一个提交(如果有)。代码如下:
# print the import information
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)
该格式由单词 data、要读取的数据大小、换行符以及最终的数据组成。因为你需要使用相同的格式稍后指定文件内容,所以创建一个辅助方法 export_data:
def export_data(string)
print "data #{string.size}\n#{string}"
end
剩下的就是为每个快照指定文件内容。这很容易,因为每个快照都在一个目录中——你可以打印出 deleteall 命令,后跟目录中每个文件的内容。Git 随后会相应地记录每个快照:
puts 'deleteall'
Dir.glob("**/*").each do |file|
next if !File.file?(file)
inline_data(file)
end
注意:由于许多系统认为它们的修订版本是从一个提交到另一个提交的变更,fast-import 也可以在每个提交中接受命令来指定哪些文件已添加、删除或修改,以及新内容是什么。你可以计算快照之间的差异并仅提供这些数据,但这更复杂——你不如把所有数据给 Git,让它自己计算。如果这更适合你的数据,请查看 fast-import 的手册页,了解如何以这种方式提供数据。
列出新文件内容或使用新内容指定已修改文件的格式如下:
M 644 inline path/to/file
data (size)
(file contents)
这里,644 是模式(如果你有可执行文件,则需要检测并指定为 755),inline 表示你将在此行之后立即列出内容。你的 inline_data 方法看起来如下:
def inline_data(file, code = 'M', mode = '644')
content = File.read(file)
puts "#{code} #{mode} inline #{file}"
export_data(content)
end
你重用了之前定义的 export_data 方法,因为这和你指定提交消息数据的方式相同。
你需要做的最后一件事是返回当前标记,以便将其传递给下一次迭代:
return mark
|
注意
|
如果你在 Windows 上运行,则需要确保添加一个额外的步骤。如前所述,Windows 使用 CRLF 作为换行符,而
|
就是这样。以下是完整的脚本:
#!/usr/bin/env ruby
$stdout.binmode
$author = "John Doe <john@example.com>"
$marks = []
def convert_dir_to_mark(dir)
if !$marks.include?(dir)
$marks << dir
end
($marks.index(dir)+1).to_s
end
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
def export_data(string)
print "data #{string.size}\n#{string}"
end
def inline_data(file, code='M', mode='644')
content = File.read(file)
puts "#{code} #{mode} inline #{file}"
export_data(content)
end
def print_export(dir, last_mark)
date = convert_dir_to_date(dir)
mark = convert_dir_to_mark(dir)
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
puts 'deleteall'
Dir.glob("**/*").each do |file|
next if !File.file?(file)
inline_data(file)
end
mark
end
# Loop through the directories
last_mark = nil
Dir.chdir(ARGV[0]) do
Dir.glob("*").each do |dir|
next if File.file?(dir)
# move into the target directory
Dir.chdir(dir) do
last_mark = print_export(dir, last_mark)
end
end
end
如果你运行此脚本,将获得如下所示的内容:
$ ruby import.rb /opt/import_from
commit refs/heads/master
mark :1
committer John Doe <john@example.com> 1388649600 -0700
data 29
imported from back_2014_01_02deleteall
M 644 inline README.md
data 28
# Hello
This is my readme.
commit refs/heads/master
mark :2
committer John Doe <john@example.com> 1388822400 -0700
data 29
imported from back_2014_01_04from :1
deleteall
M 644 inline main.rb
data 34
#!/bin/env ruby
puts "Hey there"
M 644 inline README.md
(...)
要运行导入器,请在想要导入的 Git 目录中通过管道将此输出传给 git fast-import。你可以创建一个新目录,然后在其中运行 git init 作为起点,接着运行你的脚本:
$ git init
Initialized empty Git repository in /opt/import_to/.git/
$ ruby import.rb /opt/import_from | git fast-import
git-fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects: 5000
Total objects: 13 ( 6 duplicates )
blobs : 5 ( 4 duplicates 3 deltas of 5 attempts)
trees : 4 ( 1 duplicates 0 deltas of 4 attempts)
commits: 4 ( 1 duplicates 0 deltas of 0 attempts)
tags : 0 ( 0 duplicates 0 deltas of 0 attempts)
Total branches: 1 ( 1 loads )
marks: 1024 ( 5 unique )
atoms: 2
Memory total: 2344 KiB
pools: 2110 KiB
objects: 234 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit = 8589934592
pack_report: pack_used_ctr = 10
pack_report: pack_mmap_calls = 5
pack_report: pack_open_windows = 2 / 2
pack_report: pack_mapped = 1457 / 1457
---------------------------------------------------------------------
正如你所见,当它成功完成时,会给出关于它所完成工作的统计数据。在这种情况下,你为 1 个分支导入了 4 次提交,共计 13 个对象。现在,你可以运行 git log 查看你的新历史记录:
$ git log -2
commit 3caa046d4aac682a55867132ccdfbe0d3fdee498
Author: John Doe <john@example.com>
Date: Tue Jul 29 19:39:04 2014 -0700
imported from current
commit 4afc2b945d0d3c8cd00556fbe2e8224569dc9def
Author: John Doe <john@example.com>
Date: Mon Feb 3 01:00:00 2014 -0700
imported from back_2014_02_03
搞定——一个整洁的 Git 仓库。请注意,此时没有任何内容被检出——起初你的工作目录中没有任何文件。要获取它们,必须将你的分支重置到 master 现在所在的位置:
$ ls
$ git reset --hard master
HEAD is now at 3caa046 imported from current
$ ls
README.md main.rb
你可以使用 fast-import 工具做更多的事情——处理不同的模式、二进制数据、多个分支和合并、标签、进度指示器等等。Git 源代码的 contrib/fast-import 目录中有许多更复杂场景的示例。