-
1. Getting Started (入门)
- 1.1 About Version Control (关于版本控制)
- 1.2 A Short History of Git (Git 简史)
- 1.3 What is Git? (什么是 Git?)
- 1.4 The Command Line (命令行)
- 1.5 Installing Git (安装 Git)
- 1.6 First-Time Git Setup (Git 初次配置)
- 1.7 Getting Help (获取帮助)
- 1.8 Summary (总结)
-
2. Git Basics (Git 基础)
- 2.1 Getting a Git Repository (获取 Git 仓库)
- 2.2 Recording Changes to the Repository (记录对仓库的修改)
- 2.3 Viewing the Commit History (查看提交历史)
- 2.4 Undoing Things (撤销操作)
- 2.5 Working with Remotes (使用远程仓库)
- 2.6 Tagging (打标签)
- 2.7 Git Aliases (Git 别名)
- 2.8 Summary (总结)
-
3. Git Branching (Git 分支)
- 3.1 Branches in a Nutshell (分支简介)
- 3.2 Basic Branching and Merging (分支的新建与合并)
- 3.3 Branch Management (分支管理)
- 3.4 Branching Workflows (分支工作流)
- 3.5 Remote Branches (远程分支)
- 3.6 Rebasing (变基)
- 3.7 Summary (总结)
-
4. Git on the Server (Git 服务器)
- 4.1 The Protocols (协议)
- 4.2 Getting Git on a Server (在服务器上部署 Git)
- 4.3 Generating Your SSH Public Key (生成 SSH 公钥)
- 4.4 Setting Up the Server (服务器的配置)
- 4.5 Git Daemon (Git Daemon)
- 4.6 Smart HTTP (智能 HTTP)
- 4.7 GitWeb (GitWeb)
- 4.8 GitLab (GitLab)
- 4.9 Third Party Hosted Options (第三方托管选项)
- 4.10 Summary (总结)
-
5. Distributed Git (分布式 Git)
- 5.1 Distributed Workflows (分布式工作流)
- 5.2 Contributing to a Project (参与项目)
- 5.3 Maintaining a Project (维护项目)
- 5.4 Summary (总结)
-
6. GitHub (GitHub)
- 6.1 Account Setup and Configuration (账号设置与配置)
- 6.2 Contributing to a Project (参与项目)
- 6.3 Maintaining a Project (维护项目)
- 6.4 Managing an organization (管理组织)
- 6.5 Scripting GitHub (GitHub 脚本)
- 6.6 Summary (总结)
-
7. Git Tools (Git 工具)
- 7.1 Revision Selection (版本选择)
- 7.2 Interactive Staging (交互式暂存)
- 7.3 Stashing and Cleaning (储藏与清理)
- 7.4 Signing Your Work (签署你的工作)
- 7.5 Searching (搜索)
- 7.6 Rewriting History (重写历史)
- 7.7 Reset Demystified (Reset 解密)
- 7.8 Advanced Merging (高级合并)
- 7.9 Rerere (Rerere)
- 7.10 Debugging with Git (使用 Git 调试)
- 7.11 Submodules (子模块)
- 7.12 Bundling (打包)
- 7.13 Replace (替换)
- 7.14 Credential Storage (凭证存储)
- 7.15 Summary (总结)
-
8. Customizing Git (自定义 Git)
- 8.1 Git Configuration (Git 配置)
- 8.2 Git Attributes (Git 属性)
- 8.3 Git Hooks (Git 钩子)
- 8.4 An Example Git-Enforced Policy (一个强制执行 Git 策略的例子)
- 8.5 Summary (总结)
-
9. Git and Other Systems (Git 与其他系统)
- 9.1 Git as a Client (Git 作为客户端)
- 9.2 Migrating to Git (迁移到 Git)
- 9.3 Summary (总结)
-
10. Git Internals (Git 内部原理)
- 10.1 Plumbing and Porcelain (底层命令与高层命令)
- 10.2 Git Objects (Git 对象)
- 10.3 Git References (Git 引用)
- 10.4 Packfiles (打包文件)
- 10.5 The Refspec (引用规格)
- 10.6 Transfer Protocols (传输协议)
- 10.7 Maintenance and Data Recovery (维护与数据恢复)
- 10.8 Environment Variables (环境变量)
- 10.9 Summary (总结)
-
A1. Appendix A: Git in Other Environments (附录 A:其他环境中的 Git)
- A1.1 Graphical Interfaces (图形界面)
- A1.2 Git in Visual Studio (Visual Studio 中的 Git)
- A1.3 Git in Visual Studio Code (Visual Studio Code 中的 Git)
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine (IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine 中的 Git)
- A1.5 Git in Sublime Text (Sublime Text 中的 Git)
- A1.6 Git in Bash (Bash 中的 Git)
- A1.7 Git in Zsh (Zsh 中的 Git)
- A1.8 Git in PowerShell (PowerShell 中的 Git)
- A1.9 Summary (总结)
-
A2. Appendix B: Embedding Git in your Applications (附录 B:在你的应用中嵌入 Git)
- A2.1 Command-line Git (命令行 Git)
- A2.2 Libgit2 (Libgit2)
- A2.3 JGit (JGit)
- A2.4 go-git (go-git)
- A2.5 Dulwich (Dulwich)
-
A3. Appendix C: Git Commands (附录 C:Git 命令)
- A3.1 Setup and Config (设置与配置)
- A3.2 Getting and Creating Projects (获取与创建项目)
- A3.3 Basic Snapshotting (基本快照)
- A3.4 Branching and Merging (分支与合并)
- A3.5 Sharing and Updating Projects (分享与更新项目)
- A3.6 Inspection and Comparison (检查与比较)
- A3.7 Debugging (调试)
- A3.8 Patching (打补丁)
- A3.9 Email (邮件)
- A3.10 External Systems (外部系统)
- A3.11 Administration (管理)
- A3.12 Plumbing Commands (底层命令)
10.4 Git Internals - Packfiles (10.4 Git 内部原理 - 打包文件)
Packfiles (打包文件)
If you followed all of the instructions in the example from the previous section, you should now have a test Git repository with 11 objects — four blobs, three trees, three commits, and one tag (如果你按照上一节示例中的所有指示进行操作,现在应该有一个包含 11 个对象的 Git 测试仓库——四个 blob、三个 tree、三个 commit 和一个 tag)
$ find .git/objects -type f
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1
.git/objects/95/85191f37f7b0fb9444f35a9bf50de191beadc2 # tag
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content'
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1
Git compresses the contents of these files with zlib, and you’re not storing much, so all these files collectively take up only 925 bytes. Now you’ll add some more sizable content to the repository to demonstrate an interesting feature of Git. To demonstrate, we’ll add the repo.rb
file from the Grit library — this is about a 22K source code file (Git 使用 zlib 压缩这些文件的内容,并且你没有存储太多内容,因此所有这些文件总共只占用 925 字节。现在你将向仓库添加更多更大的内容,以演示 Git 的一个有趣特性。为了演示,我们将添加 Grit 库中的 repo.rb
文件——这是一个大约 22K 的源代码文件)
$ curl https://raw.githubusercontent.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
$ git checkout master
$ git add repo.rb
$ git commit -m 'Create repo.rb'
[master 484a592] Create repo.rb
3 files changed, 709 insertions(+), 2 deletions(-)
delete mode 100644 bak/test.txt
create mode 100644 repo.rb
rewrite test.txt (100%)
If you look at the resulting tree, you can see the SHA-1 value that was calculated for your new repo.rb
blob object (如果你查看生成的 tree,可以看到为新的 repo.rb
blob 对象计算的 SHA-1 值)
$ git cat-file -p master^{tree}
100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
100644 blob 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 repo.rb
100644 blob e3f094f522629ae358806b17daf78246c27c007b test.txt
You can then use git cat-file
to see how large that object is (然后可以使用 git cat-file
来查看该对象有多大)
$ git cat-file -s 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5
22044
At this point, modify that file a little, and see what happens (此时,稍微修改一下该文件,看看会发生什么)
$ echo '# testing' >> repo.rb
$ git commit -am 'Modify repo.rb a bit'
[master 2431da6] Modify repo.rb a bit
1 file changed, 1 insertion(+)
Check the tree created by that last commit, and you see something interesting (检查由上次提交创建的 tree,你会看到一些有趣的事情)
$ git cat-file -p master^{tree}
100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
100644 blob b042a60ef7dff760008df33cee372b945b6e884e repo.rb
100644 blob e3f094f522629ae358806b17daf78246c27c007b test.txt
The blob is now a different blob, which means that although you added only a single line to the end of a 400-line file, Git stored that new content as a completely new object (blob 现在是一个不同的 blob,这意味着即使你只在 400 行文件的末尾添加了一行,Git 也会将新内容存储为一个全新的对象)
$ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e
22054
You have two nearly identical 22K objects on your disk (each compressed to approximately 7K). Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first? (你的磁盘上有两个几乎相同的 22K 对象(每个对象压缩后约为 7K)。 如果 Git 可以完整地存储其中一个对象,然后将第二个对象仅作为它和第一个对象之间的增量来存储,那岂不是很好?)
It turns out that it can. The initial format in which Git saves objects on disk is called a “loose” object format. However, occasionally Git packs up several of these objects into a single binary file called a “packfile” in order to save space and be more efficient. Git does this if you have too many loose objects around, if you run the git gc
command manually, or if you push to a remote server. To see what happens, you can manually ask Git to pack up the objects by calling the git gc
command (事实证明,它可以。 Git 最初将对象保存在磁盘上的格式称为“松散”对象格式。 但是,有时 Git 会将其中几个对象打包到一个名为“打包文件”的二进制文件中,以便节省空间并提高效率。 如果你有太多的松散对象,如果你手动运行 git gc
命令,或者如果你推送到远程服务器,Git 就会这样做。 要查看会发生什么,你可以通过调用 git gc
命令手动要求 Git 打包对象)
$ git gc
Counting objects: 18, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (18/18), done.
Total 18 (delta 3), reused 0 (delta 0)
If you look in your objects
directory, you’ll find that most of your objects are gone, and a new pair of files has appeared (如果你查看你的 objects
目录,你会发现你的大多数对象都消失了,并且出现了一对新文件)
$ find .git/objects -type f
.git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
.git/objects/info/packs
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack
剩余的对象是没有被任何提交指向的 blob — 在本例中,是你之前创建的 “what is up, doc?” 示例和 “test content” 示例 blob。因为你从未将它们添加到任何提交中,所以它们被认为是悬空的,并且不会被打包到你的新 packfile 中。
其他文件是你的新 packfile 和一个索引。packfile 是一个包含从你的文件系统中移除的所有对象内容的单个文件。索引是一个包含指向该 packfile 的偏移量的文件,以便你可以快速查找特定对象。很酷的是,尽管在你运行 gc
命令之前磁盘上的对象总共有大约 15K 大小,但新的 packfile 只有 7K。通过打包你的对象,你将磁盘使用量减少了一半。
Git 是如何做到这一点的?当 Git 打包对象时,它会查找名称和大小相似的文件,并只存储从文件的一个版本到下一个版本的增量。你可以查看 packfile 并了解 Git 为了节省空间做了什么。 git verify-pack
底层命令允许你查看打包的内容
$ git verify-pack -v .git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx
2431da676938450a4d72e260db3bf7b0f587bbc1 commit 223 155 12
69bcdaff5328278ab1c0812ce0e07fa7d26a96d7 commit 214 152 167
80d02664cb23ed55b226516648c7ad5d0a3deb90 commit 214 145 319
43168a18b7613d1281e5560855a83eb8fde3d687 commit 213 146 464
092917823486a802e94d727c820a9024e14a1fc2 commit 214 146 610
702470739ce72005e2edff522fde85d52a65df9b commit 165 118 756
d368d0ac0678cbe6cce505be58126d3526706e54 tag 130 122 874
fe879577cb8cffcdf25441725141e310dd7d239b tree 136 136 996
d8329fc1cc938780ffdd9f94e0d364e0ea74f579 tree 36 46 1132
deef2e1b793907545e50a2ea2ddb5ba6c58c4506 tree 136 136 1178
d982c7cb2c2a972ee391a85da481fc1f9127a01d tree 6 17 1314 1 \
deef2e1b793907545e50a2ea2ddb5ba6c58c4506
3c4e9cd789d88d8d89c1073707c3585e41b0e614 tree 8 19 1331 1 \
deef2e1b793907545e50a2ea2ddb5ba6c58c4506
0155eb4229851634a0f03eb265b69f5a2d56f341 tree 71 76 1350
83baae61804e65cc73a7201a7252750c76066a30 blob 10 19 1426
fa49b077972391ad58037050f2a75f74e3671e92 blob 9 18 1445
b042a60ef7dff760008df33cee372b945b6e884e blob 22054 5799 1463
033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob 9 20 7262 1 \
b042a60ef7dff760008df33cee372b945b6e884e
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a blob 10 19 7282
non delta: 15 objects
chain length = 1: 3 objects
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack: ok
在这里,033b4
blob,如果你还记得,它是你的 repo.rb
文件的第一个版本,它引用了 b042a
blob,它是该文件的第二个版本。输出中的第三列是对象在 pack 中的大小,因此你可以看到 b042a
占用了文件中的 22K,而 033b4
只占用了 9 字节。有趣的是,文件的第二个版本是完整存储的,而原始版本则存储为增量 — 这是因为你很可能需要更快地访问该文件的最新版本。
真正的好处是它可以随时重新打包。 Git 会偶尔自动重新打包你的数据库,总是尝试节省更多空间,但你也可以通过手动运行 git gc
随时手动重新打包。