Git 魔法 By Ben Lynn

Size: px

Start display at page:

Download "Git 魔法 By Ben Lynn"

躬蔚呼
7 years ago
Views:

1 Git 魔法 Ben Lynn 中文版 PDF 版本下载 :Git_Magic_CN.pdf 译自 :

2 Git 魔法 By Ben Lynn

3 前言致谢! 许可链接... 5 免费 Git 服务器入门游戏人生版本控制分布控制一个误区冲突合并基本技巧保存状态添加删除重命名进阶撤销重做还原下载文件前沿即时发布我们已经做了什么? 克隆进阶计算机间的同步典型源码控制项目分叉终极备份轻快多任务游击版本控制分支向导老板键脏活快速修订不间断工作流重组杂乱管理分支临时分支按你希望的方式工作关于历史改正标准在这之后本地变更最后部分重写历史制造历史哪儿错了?... 28

4 5.7. 谁让事情变糟了? 个人经验 Git 大师源码发布历史记录生成通过 SSH,HTTP 使用 Git 提交变更我的提交太大了! 别丢了你的 HEAD 猎捕 HEAD 在 Git 上编译大胆的绝技解密大象无形数据完整性智能索引裸资源库 Git 起源 Git 的缺点微软 Windows 无关的文件谁在编辑什么? 文件历史初始克隆不稳定的项目全局计数器空子目录初始提交... 42

5 前言 Git( 是一个版本控制的瑞士军刀一个可靠通用多用途版本控制工具, 它超强的灵活性使得一般人学着使用它没那么直白, 更别说掌握它了我把到目前为止弄明白的记下来, 因为在我试图理解 Git 用户手册 ( scm/git/docs/user-manual.html) 的时候也是困难重重 ; 希望对别人有用正如 Arthur C. Clarke 所发现的, 所有称得上先进的技术都和魔法难以区分这是接近 Git 的一个很不错的办法 : 新手们可以忽略它内部机理, 只把 Git 看作一个小发明, 用它强大的功能让朋友吃惊, 让敌人发狂我们提供大面上的指导, 而不是陷入细节在重复使用之后, 慢慢地你会明白每个小技巧是如何工作的, 并且还会知道如何合理剪裁以适应您的需要 1. 致谢! 感谢 Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan 和 Derek Mahar 提出的建议和改进 [ 如果我漏掉了谁请告诉我因为我经常忘记更新这一节 ] 2. 许可本指南在 GNU General Public License 版本 3 之下发布 ( gpl-3.0.html) 3. 链接我曾经罗列了一些参考文献, 但这维护起来太费时了除此之外, 也可以简单地使用搜索引擎 ( 来获得一些 Git 指导 ( search?q=git+tutorial), 指南 ( 以及比较 ( 附带 Subversion( 或者 Mercurial( 以及其他的版本控制系统

6 免费 Git 服务器提供自由项目伺服服务, 包括本文档 ( gitmatic.git) 是另一个支持 Git 的开源项目伺服器提供免费的开源项目伺服服务, 包括本文档也在其中 ( 也包括一些私有的付费项目

7 1. 入门我将用类比的方式来介绍版本控制更严谨些的解释可以参见 Wikipedia 版本修订控制条目 ( 游戏人生我几乎一生下来就开始玩电脑游戏, 直到现在然而, 我仅在我长大之后才开始使用版本控制系统我想我的情况并非是极个别的, 比较这两者也许可以使得一些概念更容易解释和理解把编辑代码或文档, 或无论什么, 当作玩游戏一旦你已经取得了很多进展, 你会想到保存你会点击值得信赖的编辑器的保存按钮来进行保存但这将覆盖旧版本就像那些在学校里玩的老游戏那样, 只有一个保存条 : 你确实可以保存, 但一旦保存就不能回到原来的状态这太不应该了, 因为可能你之前的存档恰好在这个游戏特别有意思一关, 也许某天你想重新回顾一下或者更糟糕的, 你当前的存档是个败局, 你不得不重玩 1.2. 版本控制在编辑的时候, 如果想保留旧版本, 你可以将文件另存为一个不同的文件, 或在保存之前将文件拷贝到别处或许还会把这些文件进行压缩, 来节省空间这是一个原始的费功夫的版本控制形式计算机游戏很久以前就改良了这块, 很多都提供了多个基于时间戳的自动保存记录功能让我们看一些更复杂的情况比如你有很多在一起的文件, 比如项目的源代码, 或网站的文件现在如果你想保留旧版本你不得不存储拷贝整个目录手工保存很多个版本不方便, 并且很快会变得高昂对一些电脑游戏而言, 一个保存的游戏记录实际上是包括一个充满文件的目录这些游戏对玩家屏蔽了具体细节, 并提供一个方便的界面来管理目录里的不同版本版本控制系统也没有两样两者都有友好的界面来管理目录里的内容你频繁保存目录的状态, 也可以在之后加载任一旧状态不像大多计算机游戏, 版本控制系统通常精于节省空间比如说, 如果两个版本间只有少数文件的改变, 那就只存储差异的部分以节省存储空间, 而不是把所有的都保存下来

8 1.3. 分布控制现在设想有一个非常难的计算机游戏太难打了, 以至于全世界很多高级玩家决定组队, 分享他们保存的游戏记录以攻克它 Speedrun 们就是真实生活中的例子 : 在同一个游戏里, 玩家们专注攻克不同的等级, 这样的协同工作创造了惊人的战绩如何搭建一个系统, 使得他们可以很容易得到其他人的保存记录? 并且很容易上载新的记录? 在过去, 每个项目都使用中心式版本控制一个服务器存放所有保存的游戏记录其他人都不用每个玩家在他们机器上最多保留几个游戏记录当一个玩家想更新进度时候, 他们需要把最新进度从主服务器下载下来, 玩一会儿, 保存并上载到主服务器以供其他人使用假如一个玩家由于某种原因, 想得到一个较旧版本的游戏进度怎么样? 或许当前保存的游戏是一个败局, 因为某人在第三级忘记捡某个物品, 并且他们希望能找到最后一个可以完成游戏的记录或者他们想比较两个旧版本间的差异, 来估算某个特定玩家干了多少活查看旧版本的理由有很多, 但检查的办法都是一样的他们必须去问中心服务器要那个旧版本的记录需要的旧版本越多, 需要和服务器的交互就越多新一代的版本控制系统,Git 就是其中之一, 是分布式系统, 可以被认作广义上的中心式系统一个玩家从主服务器下载所有保存的记录, 不仅是最新版这看起来好像他们把中心服务器做了个镜像最初的克隆操作可能比较费时, 特别历史记录很长的时候, 但最终这个本地镜像备份会带来很多优势一个显而易见的好处是, 当查看一个旧版本时, 不再需要和中心服务器通讯了一个误区一个很常见的错误观念是, 分布式系统不太适合需要正式中心存储的项目这与事实并不相符给某人照相并不会导致他们的灵魂被偷走类似地, 对主存储进行克隆并不降低它的重要性一般来说, 一个中心版本控制能做的任何事, 一个良好设计的分布式系统会做得更好网络资源总要比本地资源耗费更多资源不过我们应该在稍后分析分布式方案的缺点, 这样人们才不会按照习惯做出错误的比较一个小项目或许只需要这种系统提供的一小部分功能但你在计算较小数目的时候会使用罗马数字吗? 而且, 你的项目的增长可能会超出你最初的预期从一开始就使用 Git 好似

9 带着一把瑞士军刀, 尽管你很多时候只是用它来开瓶盖到你迫切需要一把改锥的那一天, 你就会庆幸你有的不单单是一个启瓶器 1.4. 冲突合并对于这个话题, 我们计算机游戏的类比显得太单薄了那么让我们再来看看文档编辑的情况吧假设 Alice 在文件开头插入一行, 并且 Bob 在文件末尾添加一行他们都上传了他们的改动大多数系统将自动给出一个合理的处理方式 : 接受且合并他们的改动, 这样 Alice 和 Bob 两人的改动都会生效现在假设 Alice 和 Bob 对文件的同一行做了不同的改动如果没有人工参与的话, 这个冲突是无法解决的第二个人在上载文件时, 会收到合并冲突的通知, 并且他们必须选择要么用一个人的改动覆盖另一个的, 要么完全修订这一行更复杂的情况也可能出现版本控制系统自己处理相对简单的情况, 把困难的情况留给人来处理他们的行为通常都是可配置的

10 2. 基本技巧与其一头扎进 Git 命令的海洋中, 不如使用一些基本的例子, 湿湿脚例子尽管很简单但都很有用实际上, 我开始使用 Git 的头几个月, 从来没觉得本章介绍的命令不够用 2.1. 保存状态要不要来点猛的? 在做之前, 先为当前目录所有文件做个快照, 使用下列命令 : $ git init $ git add. $ git commit -m "My first backup" 上面的这组命令应该牢记, 或放到脚本里, 因为他们会常常被用到现在如果你的文件编辑乱了, 运行 : $ git reset --hard 可以回到你原来编辑的地方再次保存状态 : $ git commit -a -m "Another backup" 添加删除重命名以上的命令将只对在你第一次运行 git add 命令时就已经存在的文件有用如果要添加新文件或子目录, 你需要告诉 Git: $ git add NEWFILES... 类似地, 如果你想让 Git 忘记某些文件 ( 或许是由于你已经删除了他们 ): $ git rm OLDFILES...

11 重命名一个文件和先删除旧文件, 再添加新文件的一样也有一个快捷方式 git mv, 这和 mv 命令的语法一样例如 : $ git mv OLDFILE NEWFILE 2.2. 进阶撤销重做有时候你只想把某个时间点之后的所有改动都回滚掉, 因为这些的改动是不正确的那么可以使用 : $ git log 显示最近提交列表, 以及他们的 SHA1 哈希值下面, 键入 : $ git reset --hard SHA1_HASH 来恢复到一个指定的提交状态, 并从记录里永久抹掉所有比该记录更新的提交另一些时候你想简单地跳到一个旧状态这种情况, 键入 : $ git checkout SHA1_HASH 这个操作将把你带回过去, 同时保存较新提交然而, 像科幻电影里时光旅行一样, 如果你这时编辑并提交的话, 你将身处另一个现实里, 因为你的动作与开始时相比是完全不同的这另一个现实叫作分支 (branch), 之后我们会对这点多讨论一些至于现在, 只要记住 : $ git checkout master 会把你带到当下来在你运行 checkout 命令时, 并不提交时光旅行中的改变

12 再次用计算机游戏做类比 : git reset -- hard: 加载一个旧的游戏存档, 并删除所有比它新的存档 git checkout: 加载旧游戏存档, 但如果你从这个存档开始玩, 游戏状态将有别于你之前保存的更新的记录此后任何记录都保存到另一个分支中, 代表你进入的另一个现实后面会详细讲你可以选择只恢复特定文件或子目录, 把这些加到该命令后面就可以了不喜欢剪切粘贴哈希值? 那么用 : $ git checkout "@{10 minutes ago}" 其他的时间格式也是可以的比如, 你可以要求倒数第五次保存状态 : $ git checkout "@{5}" 还原在法庭上, 事件可以从法庭记录里追踪出来同样, 你可以选择还原特定的提交 $ git commit -a $ git revert SHA1_HASH 将还原特定哈希值的提交运行 git log 显示该还原记录为一个新的提交 2.3. 下载文件得到一个由 Git 管理的项目的拷贝, 键入 : $ git clone git://server/path/to/files 例如, 得到我用来创建该站的所有文件 :

13 $ git clone git://git.or.cz/gitmagic.git 我们很快会对 clone 命令谈的更多 2.4. 前沿如果你已经使用 git clone 命令得到了一个项目的一份拷贝, 你可以更新到最新版 : $ git pull 2.5. 即时发布假设你已经写了一个脚本, 你想和他人分享你可以只告诉他们从你的计算机下载, 但如果在你正在改进你的脚本, 或加入试验性质的改动时, 他们下载了你的脚本, 他们可能由此陷入困境当然, 这就是发布周期存在的原因开发人员可能频繁进行项目修改, 但他们只在他们觉得代码可以见人的时候才择时发布用 Git 来完成这项, 需要进入你的脚本所在目录 : $ git init $ git add. $ git commit -m "First release" 然后告诉你的用户去运行 : $ git clone your.computer:/path/to/script 来下载你的脚本这要假设他们有 ssh 访问权限如果他们没有, 你需要运行 git daemon 并告诉你的用户去运行 : $ git clone git://your.computer/path/to/script 从现在开始, 每次你的脚本准备好发布时, 就运行 : $ git commit -a -m "Next release" 并且你的用户可以通过进入包含你脚本的目录, 并键入下列命令, 来更新他们的版本 :

14 $ git pull 你的用户永远也不会取到你不想让他们看到的脚本版本显然这个技巧对所有的东西都是可以, 不仅是对脚本 2.6. 我们已经做了什么? 找出自从上次提交之后你已经做了什么改变 : $ git diff 或者自昨天 : $ git diff "@{yesterday}" 或者一个特定的版本和版本 2 之间 : $ git diff SHA1_HASH "@{2}" 除了直接运行 log 和 diff, 有时我也用 qgit 浏览历史 ( qgit), 因为它的图形界面很养眼, 或者用 tig( 一个文本界面东西, 在网速不快的情况下也工作的很好另外, 安装一个 Web 服务器, 运行 git instaweb, 那就可以用任意的浏览器浏览了

15 3. 克隆进阶在旧一代的版本控制系统里,checkout 是获取文件的标准操作你将获得一组期望状态下的文件在 Git 和其他分布式版本控制系统里, 克隆是标准的操作通过创建整个资源库的克隆来获得文件或者说, 你实际上把整个服务器做了个镜像主资源库上能做的是, 你都能做 3.1. 计算机间的同步这也是我第一次使用 Git 的原因我可以忍受制作 tar 包或利用 rsync 来作备份或者作简单的同步但我时而在我笔记本上编辑, 时而在台式机上, 而且这两台电脑之间也许不能交互在一个机器上初始化一个 Git 资源库并提交你的文件然后转到另一台机器上 : $ git clone other.computer:/path/to/files 创建这些文件和 Git 资源库的第二个拷贝从现在开始 : $ git commit -a $ git pull other.computer:/path/to/files 将从另一台机器拷贝文件到你正工作的机器上如果你最近对同一个文件做了有冲突的修改,Git 将通知你, 而你也应该在解决冲突之后再次提交 3.2. 典型源码控制为你的文件初始化 Git 资源库 : $ git init $ git add. $ git commit -m "Initial commit" 在中心服务器, 初始化一个空的 Git 资源库, 如果需要的话, 启动 Git 守护进程 :

16 $ GIT_DIR=proj.git git init $ git daemon --detach # it might already be running 一些公用主机, 比如 repo.or.cz( 通过不同于以上的方法来搭建最初空 Git 资源库, 比如在网页上填一个表单把你的项目推到中心服务器 : $ git push git://central.server/path/to/proj.git HEAD 这样我们准备好了一个开发人员可以这样 check out 源码 : $ git clone git://central.server/path/to/proj.git 在做了改动之后,check in 源码到主服务器 : $ git commit -a $ git push 如果主服务器已经更新了, 最新版在 push 之前需要 check out 同步到最新版 : $ git commit -a $ git pull 3.3. 项目分叉项目走歪了吗? 或者认为你可以做得更好? 那么在服务器上 : $ git clone git://main.server/path/to/files 之后告诉每个相关的人你服务器上项目的分支在之后的时间, 你可以合并来自原先项目的改变, 使用命令 : $ git pull

17 3.4. 终极备份会有很多禁止篡改的不同位置上的冗余存档吗? 如果你的项目有很多开发人员, 那干脆别想了你的每份代码克隆是一个有效备份不仅当前状态, 还包括你项目整个历史感谢哈希加密算法, 如果任何人的克隆被损坏, 只要他们与其他的交互, 这个克隆就会打上记号如果你的项目并不是那么流行, 那就找尽可能多的主服务器来放克隆真正的偏执狂应该总是把 HEAD 最近 20 字节的 SHA1 哈希值写到安全的地方应该保证安全, 而不是把它藏起来比如, 把它发布到报纸上就不错, 因为对攻击者而言, 更改每份报纸是很难的 3.5. 轻快多任务比如你想并行开发多个功能那么提交你的项目并运行 : $ git clone. /some/new/directory Git 使用硬链接和文件共享来尽可能安全地创建克隆, 因此它一眨眼就完成了, 因此你现在可以并行操作两个没有相互依赖的功能例如, 你可以编辑一个克隆, 同时编译另一个在任何时间, 你都可以从另一个克隆提交或拿下变更 $ git pull /the/other/clone 3.6. 游击版本控制你正做一个使用其他版本控制系统的项目, 而你非常怀念 Git? 那么在你的工作目录初始化一个 Git 资源库 : $ git init $ git add. $ git commit -m "Initial commit" 然后以很快的速度克隆它 :

18 $ git clone. /home/new/directory 现在转到新目录并在这个目录工作, 在你心里的内容上使用 Git 过一会, 一旦你想和其他每个人同步, 在这种情况下, 转到原来的目录, 用其他的版本控制工具同步, 并键入 : $ git add. $ git commit -m "Sync with everyone else" 然后转到新目录并运行 : $ git commit -a -m "Description of my changes" $ git pull 把你的变更提交给他人的过程依赖于其他版本控制系统这个新目录包含你的改动的文件需要运行其他版本控制系统的命令来上载这些变更到中心资源库命令 git svn 为 Subversion 资源库自动化了以上步骤, 并且也可以用作 Git 项目导出到一个 Subversion 资源库 ( 参见

19 4. 分支向导瞬间就能完成的分支和合并是 Git 最致命的杀手锏问题 : 外部因素不可避免地使场景切换成为必须在发布版本中没有任何前兆的突然出现了一个严重臭虫, 并且必须不惜一切代价尽快修复某个特性的截至日期就要来临写这个功能的家伙正打算离职, 因此你应该停下所有你正在做的, 抓住他帮你理解这个功能中断连贯的思维会降低你的生产力, 并且切换上下文也比较缓慢, 不方便, 中断的越长损失越大使用中心版本控制我们必须从中心服务器下载一个崭新的工作拷贝分布式系统的情况就好多了, 因为我们能够在本地克隆所需要的版本但是克隆仍然需要拷贝整个工作目录, 以及一直到指定点的整个历史记录尽管 Git 使用文件共享和硬链接减少了花费, 项目文件自身必须在新的工作目录里重新创建方案 : 针对这些情况,Git 有一个更好的工具, 比克隆更快速而且节省空间 :git branch 在这个神奇的世界里, 你目录里的文件突然从一个版本变到另一个版本除了只是在历史记录里前前后后的转变之外, 这个转换还可以做更多你的文件可以从上一个版本变到实验版本到当前开发版本到你朋友的版本等等 4.1. 老板键曾经玩过那样的游戏吗? 按一个键 ( 老板键 ), 屏幕立即显示一个电子表格或别的? 那么如果老板走进办公室, 而你正在玩游戏, 就可以用这个功能来遮掩一下在某个目录 : $ echo "I'm smarter than my boss" > myfile.txt $ git init $ git add. $ git commit -m "Initial commit" 我们已经创建了一个 Git 资源库, 该资源库记录一个包含特定信息的文件现在我们键入 : $ git checkout -b boss # 之后似乎没啥改变 $ echo "My boss is smarter than me" > myfile.txt

20 $ git commit -a -m "Another commit" 看起来我们刚刚只是覆盖了原来的文件并提交了它但这是个错觉键入 : $ git checkout master # 切到原来版本的文件嘿真快! 这个文件就恢复了并且如果老板决定窥视这个目录, 键入 : $ git checkout boss # 切到适合老板眼睛的版本你可以在两个版本之间相切多少次就切多少次, 而且每个版本都可以独立提交 4.2. 脏活比如你正在开发某个特性, 并且由于某种原因, 你需要回到一个旧版本, 临时加进几行打印语句来看看一些东西是如何工作的那么 : $ git commit -a $ git checkout SHA1_HASH 现在你可以满世界加丑陋的临时代码你甚至可以提交这些改动当你做完的时候, $ git checkout master 来返回到你原来的工作观察任何未提交变更都转结了如果你想之后保存临时变更怎么办? 简单 : $ git checkout -b dirty 并且在切换到主分支之前提交无论你什么时候想返回脏的变更, 只需键入 : $ git checkout dirty 当我们讨论加载旧状态的时候, 我们在较早章节曾接触过这个命令最终我们把故事说全 : 文件改变成请求的状态, 但我们必须离开主分支从现在开始任何提交都会将你的文

21 件提交到另一条不同的路, 这个路可以之后命名换一个说法, 在 checkout 一个旧状态之后,Git 自动把你放到一个新的, 未命名的分支, 这个分支可以使用 git checkout -b 来命名和保存 4.3. 快速修订你正在做某件事的当间, 被告知先停下来所有的事情去修理一个新近发现的臭虫 : $ git commit -a $ git checkout -b fixes SHA1_HASH 那么一旦你修正了这个臭虫 : $ git commit -a -m "Bug fixed" $ git push # 到中心资源库 $ git checkout master 并可以继续你原来的任务 4.4. 不间断工作流一些项目要求在你提交你的代码之前需要审批为了让审批代码的过程更简单, 如果你有一个大的改动, 你可能会将它分成两个或更多的部分, 进行单独的审批如果在第一部有获得准许并提交之前, 第二部分不能写怎么办? 在许多版本控制系统中, 你不得不先将第一部分发送给审批者, 然后等待, 直到这部分获得批准后, 才可以开始第二部分的工作实际上那并非全是真的, 但在这些系统中, 在第一部分提交前, 就编辑第二部分会引入很多痛苦和困难在 Git 里, 分支和合并是无痛的 ( 快速和本地的一个技术词汇 ) 因此在你提交第一部分内容并发送给审批者后 : $ git checkout -b part2 接下来, 为这个大变动的第二部分进行编码, 不必等待第一部分的接受在第一部分获得批准并提交后 :

22 $ git checkout master $ git merge part2 $ git branch -d part2 # 不在需要这个分支并且第二部分也准备好审批不过等等! 如果没那么简单怎么办? 比如你在第一部分犯了一个错误, 在你提交之前你不得不更正它没问题! 首先, 转到主分支 : $ git checkout master 修复第一部分变更里的这个问题, 并希望它得到批准如果没获得批准就简单重复这一步你或许希望将第一部分修改后的版本合并到第二部分 : $ git checkout part2 $ git merge master 现在它和以前一样了一旦第一部分获得批准并提交 : $ git checkout master $ git merge part2 $ git branch -d part2 并且再次, 第二部分也准备好审批了这个技巧可以很容易地被扩展, 来处理任意多数目的部分 4.5. 重组杂乱或许你喜欢在同一个分支下完成工作的方方面面你想为自己保留工作进度并希望其他人只能看到你仔细整理过后的提交开启一对分支 : $ git checkout -b sanitized $ git checkout -b medley 接下来, 可以做任何事情 : 修臭虫, 加特性, 加临时代码, 诸如此类, 经常按这种方式提交然后 :

23 $ git checkout sanitized $ git cherry-pick SHA1_HASH 在 sanitized 分支应用给定提交在分支上选择一个最合适的点, 你可以建设一个只包含永久代码, 有关提交组合在一起的分支 4.6. 管理分支键入 : $ git branch 来列出所有分支总有一个叫做 master, 并且你默认从这开始一些人主张别碰 master 分支, 而是创建你自己版本的新分支使用 -d -m 选项来删除移动 ( 重命名 ) 分支参见 git help branch 4.7. 临时分支很快你会发现你经常会因为一些相同的原因创建短期的分支或许有些时候你创建分支只是为了保存当前状态, 同时你方便在上一个保存状态执行一些操作, 诸如修复高优先级的臭虫之类可以和电视的换台做类比, 临时切到别的频道, 来看看那正演什么, 但并不是简单地按几个按钮, 你必须创建, 检出, 删除并提交临时分支幸运的是,Git 已经有了和电视机遥控器一样方便的功能 : $ git stash 这个命令保存当前状态到一个临时的地方 ( 一个隐藏的地方 ) 并且恢复之前状态你的工作目录看起来和你开始编辑之前一样, 并且你可以修复臭虫, 引入之前变更等当你想回到隐藏状态的时候, 键入 : $ git stash apply # 你可能需要解决一些冲突你可以有多个隐藏, 并用不同的方式来操作他们参见 git help slash

24 4.8. 按你希望的方式工作诸如 Mozzila Firefox( 允许你打开多个标签和多个窗口切换标签可以在同一个窗口展示不同内容 Git 的分支就像是你工作目录的标签继续这个类比,Git 克隆好似打开一个新的窗口这两种操作的易用性提高了用户体验在更高层, 几个 Linux 窗口管理器允许你有多个桌面 : 你可以立即切到一个显示器另一个相似的例子是 screen( 工具这个好东西允许你在同一个终端上创建, 销毁终端会话, 还可以在多个终端会话之间切换不是打开一个新的终端 ( 类似于克隆 ), 如果你使用 screen( 类似于分支 ), 你可以使用同一个终端实际上, 你还可以利用 screen 做更多的事, 不过这是另一个话题的内容了在 Git 里, 克隆分支和合并是本地操作, 很快促使你能使用最适合你的组合 Git 让你能按你确切想要的工作

25 5. 关于历史 Git 一系列的分布式特性使得历史可以很容易的被修改掉但如果你篡改了过去, 需要小心 : 只重写你独自拥有的那部分如同民族间会无休止的争论谁犯下了什么暴行一样, 如果在另一个人的克隆里, 历史版本与你的不同, 这时如果合并的话, 你会遇到一致性方面的问题当然, 如果你掌管所有分支的话, 那就没啥问题了, 既然你可以覆盖他们的一些开发人员强烈地感觉历史应该永远不变, 无论不好的部分或这所有的部分另一些觉得代码树在向外发布之前, 应该整得漂漂亮亮的 Git 支持两者的观点像克隆, 分支和合并一样, 重写历史只是 Git 给你的另一强大功能, 至于如何使用它, 那是你的事了 5.1. 改正标准已经提交了, 但你期望你已经输入了另外的信息? 那么键入 : $ git commit --amend 来改变上一条信息意识到你还忘记了加一个文件? 运行 git add 来加, 然后与性上面的命令希望在上次提交里包括多一点的改动? 那么就做这些改动并运行 : $ git commit --amend -a 5.2. 在这之后假设前面的问题还要糟糕十倍在很长一段时间里我们做了一系列的提交但你不太喜欢他们的组织方式, 而且一些提交信息需要重写那么键入 : $ git rebase -i HEAD~10 并且后 10 个提交会出现在你喜爱的 $EDITOR 一个例子 :

26 pick 5c6eb73 Added repo.or.cz link pick a311a64 Reordered analogies in "Work How You Want" pick f Added push target to Makefile 之后 : 通过删除行来移去提交通过为行重新排序来为提交重新排序用 edit 来替换 pick 来标志一个提交可修改用 squash 来替换 pick 来将一个提交和前一个合并如果你把一个提交标记为可编辑, 那么运行 $ git commit --amend 或者, 运行 : $ git rebase --continue 这样尽早提交, 经常提交都没关系 : 你可以之后使用 rebase 来梳理清楚 5.3. 本地变更最后部分你正在一个活跃的项目上工作随着时间推移, 你做了几个本地提交, 然后你使用合并与官方版本同步在你准备好提交到中心分支之前, 这个循环会重复几次但现在你本地 Git 克隆的变更历史与官方变更乱成了一锅粥你会更期望在变更列表里, 你所有的变更能够连续的这就是上面提到的 git rebase 的工作在很多情况下你可以使用 --onto 标记以避免交互另外参见 git help rebase, 以获取这个让人惊奇的命令更详细的例子你可以拆分提交你甚至可以重新组织一棵树的分支 5.4. 重写历史偶尔, 你需要做一些代码控制, 好比从正式的照片中去除一些人一样, 需要从历史记录里面彻底的抹掉他们例如, 假设我们要发布一个项目, 但由于一些原因, 项目中的某个文件不能公开或许我把我的信用卡号记录在了一个文本文件里, 而我又意外的把它加入到了这个项目中仅仅删除这个文件是不够的, 因为从别的提交记录中还是可以访问到这个

27 文件因此我们必须从所有的提交记录中彻底删除这个文件 $ git filter-branch --tree-filter `rm top/secret/file` HEAD 参见 git help filter-branch, 那讨论这个例子并给出一个更快的方法一般地,filterbranch 允许你使用一个单一命令来大范围地更改历史事后, 你必须使用你更改过的版本替换你项目的克隆, 如果你希望之后和他们交互的话 5.5. 制造历史想把一个项目迁移到 Git 吗? 如果这个项目是用一些比较有名的系统管理着, 那可以使用一些其他人已经写好的脚本, 把整个项目历史记录导出到 Git 里否则, 看一下 git fast-import, 这个命令会从一个特定格式的文本读入, 从头来创建 Git 历史记录通常可以很快地组织一个包含这个命令的脚本, 运行一次就可以一次迁移整个项目作为一个例子, 粘贴以下所列到临时文件, 比如 /tmp/history: commit refs/heads/master committer Alice <alice@example.com> Thu, 01 Jan :00: data <<EOT Initial commit. EOT M inline hello.c data <<EOT #include <stdio.h> int main() { printf("hello, world!\n"); return 0; } EOT commit refs/heads/master committer Bob <bob@example.com> Tue, 14 Mar :59: data <<EOT Replace printf() with write(). EOT

28 M inline hello.c data <<EOT #include <unistd.h> int main() { write(1, "Hello, world!\n", 14); return 0; } EOT 之后从这个临时文件创建一个 Git 资源库, 键入 : $ mkdir project; cd project; git init $ git fast-import < /tmp/history 你可以从这个项目 checkout 出最新的版本, 使用 : $ git checkout master 哪儿错了? 你刚刚发现程序里有一个功能出错了, 而你十分确定几个月以前它运行的很正常天啊! 这个臭虫是从哪里冒出来的? 要是那时候能按照开发的内容进行过测试该多好啊现在说这个已经太晚了然后即使你过去经常提交变更,Git 还是可以精确的找出问题所在 : $ git bisect start $ git bisect bad SHA1_OF_BAD_VERSION $ git bisect good SHA1_OF_GOOD_VERSION Git 从历史记录中检出一个中间的状态在这个状态上测试功能, 如果还是错误的 : $ git bisect bad

29 如果可以工作了, 则把 "bad" 替换成 "good" Git 会再次帮你找到一个以确定的好版本和坏版本之间的状态, 通过这种方式缩小范围经过一系列的迭代, 这种二进制查询会帮你找到导致这个错误的那次提交一旦完成了问题定位的调查, 你可以返回到原始状态, 键入 : $ git bisect reset 不需要手工测试每一次改动, 执行如下命令可以自动的完成上面的搜索 : $ git bisect run COMMAND Git 使用指定命令 ( 通常是一个一次性的脚本 ) 的返回值来决定一次改动是否是正确的 : 命令退出时的代码 0 代表改动是正确的,125 代表要跳过对这次改动的检查,1 到 127 之间的其他数值代表改动是错误的返回负数将会中断整个 bisect 的检查你还能做更多的事情 : 帮助文档解释了如何展示 bisects, 检查或重放 bisect 的日志, 并可以通过排除对已知正确改动的检查, 得到更好的搜索速度 5.7. 谁让事情变糟了? 和其他许多版本控制系统一样,Git 也有一个 "blame" 命令 : $ git blame FILE 这个命令可以标注出一个指定的文件里每一行内容的最后修改者, 和最后修改时间但不像其他版本控制系统,Git 的这个操作是在线下完成的, 它只需要从本地磁盘读取信息 5.8. 个人经验在一个中心版本控制系统里, 历史的更改是一个困难的操作, 并且只有管理员才有权这么做没有网络, 克隆, 分支和合并都没法做像一些基本的操作如浏览历史, 或提交变更也是如此在一些系统里, 用户使用网络连接仅仅是为了查看他们自己的变更, 或打开文件进行编辑中心系统排斥离线工作, 也需要更昂贵的网络设施, 特别是当开发人员增多的时候最重

30 要的是, 通常当用户试图避免使用那些能不用则不用的高级命令时, 所有操作都变得很慢在极端的情况下, 即使是最基本的命令也会变慢当用户必须运行慢的命令的时候, 由于工作流被打断, 生产力降低我有这些现象的一手经验 Git 是我使用的第一个版本控制系统我很快变得适应了它, 用了它提供的许多功能我简单地假设其他系统也是相似的 : 选择一个版本控制系统应该和选择一个编辑器或浏览器没啥两样在我之后被迫使用中心系统的时候, 我被震惊了我那有些脆弱的网络连接没给 Git 带来大麻烦, 但是当它需要像本地硬盘一样稳定的时候, 它使开发困难重重另外, 我发现我自己有选择地避免特定的命令, 以避免踏雷, 这极大地影响了我, 使我不能按照我喜欢的方式工作当我不得不运行一个慢的命令的时候, 这种等待极大地破坏了我思绪连续性在等待服务器通讯完成的时候, 我选择做其他的事情以度过这段时光, 比如查看邮件或写其他的文档当我返回我原先的工作场景的时候, 这个命令早已结束, 并且我还需要浪费时间试图记起我之前正在做什么人类不擅长场景间的切换还有一个有意思的大众悲剧效应 : 预料到网络拥挤, 为了减少将来的等待时间, 每个人将比以往消费更多的带宽在各种操作上共同的努力加剧了拥挤, 这等于是鼓励个人下次消费更多带宽以避免更长时间的等待

31 6. Git 大师这个有点自夸的标题下是我压箱底的 Git 不在编的技巧 6.1. 源码发布就我的项目而言,Git 确切跟踪了我想打包并发布给用户的文件创建一个源码包, 我运行 : $ git archive --format=tar --prefix=proj-1.2.3/ HEAD 6.2. 历史记录生成保留一份历史记录是一个好实践 ( 这甚至是一些项目所要求的如果你变更提交的很频繁, 这是应该的, 可以生成一份历史记录, 通过键入 : $ git log > Changelog 6.3. 通过 SSH,HTTP 使用 Git 假设你有一台 web 服务器的 ssh 访问权限, 但上面并没有安装 Git 没有比服务器上自带协议更省事的方法的,Git 可以通过 HTTP 来进行通信那么在你的帐户下下载, 编译并安装 Git 在你的 Web 目录里创建一个 Git 资源库 : $ GIT_DIR=proj.git git init 在目录 proj.git 目录, 运行 $ git --bare update-server-info $ chmod a+x hooks/post-update 从你的计算机通过 SSH 推送 : $ git push we.server:/path/to/proj.git master

32 别人可以通过如下命令, 得到你的项目 : $ git clone 提交变更对特定项目, 当你加入删除重命名一些文件时, 告诉 Git 这个操作是有困难的你可以键入 : $ git add. $ git add -u Git 会查看当前目录的这些文件, 并独立计算出所有细节如果你还试图同时提交的话, 可以不使用第二个添加命令, 而是运行 git commit -a 也可以用单独的一行完成以上的任务 : $ git ls-files -d -m -o -z xargs -0 git update-index --add --remove 这里 -z 和 -0 选项可以避免文件名中包含特殊字符带来的错误注意该命令也添加应该被忽略的文件这时你或许希望使用 -x 或 -X 选项 6.5. 我的提交太大了! 是不是太长时间忘记了提交? 痴迷地编码, 以至到现在才想起有源码控制工具这回事? 提交一系列不相关的变更, 因为那是你的风格? 别着急, 运行 : $ git add -p 为你做的每次修改,Git 将为你展示变动的代码, 并询问该变动是否应是下一次提交的一部分回答 y 或者 n 也有其他选项, 比如延迟决定 : 键入? 来学习更多一旦你满意, 键入

33 $ git commit 来精确地提交你所选择的变更 ( 阶段变更 ) 确信你没加上 -a 选项, 否则 Git 将提交所有修改如果你修改了许多地方的许多文件怎么办? 一个一个地查看变更令人沮丧, 心态麻木这种情况下, 使用 git add -i, 界面不是很直观, 但更灵活敲几个键, 你可以一次决定阶段提交几个文件, 或查看并检查特定文件的变更作为另一种选择, 你还可以运行 git commit --interactive, 这个命令会在你操作完后自动进行提交 6.6. 别丢了你的 HEAD HEAD 好似一个游标, 通常指向最新提交, 随最新提交向前移动 Git 提供了命令来移动它例如 : $ git reset HEAD~3 将立即向回移动 HEAD 三个提交这样所有 Git 命令都表现得好似你没有做那最后三个提交, 然而你的文件保持在现在的状态具体应用参见 git reset 手册页但如何回到将来呢? 过去的提交对将来一无所知如果你有原先 Head 的 SHA1 值, 那么 : $ git reset SHA1 但假设你从来没有记下呢? 别着急, 像这些命令,Git 保存原先的 Head 为一个叫 ORGI_HEAD 的标记, 你可以安全体面的返回 : $ git reset ORIG_HEAD 6.7. 猎捕 HEAD 或许 ORG_HEAD 不够或许你刚认识到你犯了个历史性的错误, 你需要回到一个早已忘记的分支上的一个远古的提交默认,Git 保存一个提交至少两星期, 即使你命令 Git 摧毁该提交所在的分支难点是找到相应的哈希值你可以查看在.git/objects 里所有的哈希值并尝试找到你期望的但有更容易的办法

34 Git 把算出的提交哈希值记录在.git/logs 这个子目录引用包括所有分支上所有活动的历史, 同时文件 HEAD 显示它曾经有过的所有哈希值后者可以被用来分支上一些不小心丢掉的提交的哈希值命令 reflog 为访问这些日志提供文件友好的接口, 试试 $ git reflog 更多信息参见其文档页你或许期望去为已删除的提交设置一个更长的保存周期例如 : $ git config gc.pruneexpire "30 days" 意思是一个被删除的提交会在删除 30 天后, 且运行 git gc 以后, 被永久丢弃你或许还想关掉 git gc 的自动运行 : $ git config gc.auto 0 在这种情况下提交将只在你手工运行 git gc 的情况下才永久删除 6.8. 在 Git 上编译依照真正的 UNIX 风格,Git 的设计允许其可以被很容易用作其他程序的底层组件有图形界面,Web 界面, 可选择的命令行界面, 并且或许很快你将有一个或两个你自己的脚本, 调用 Git 一个简单的技巧是, 用 Git 内建 alias 命令来缩短你最常用命令的长度 : $ git config --global alias.co checkout $ git config --global --get-regexp alias # 显示当前别名 alias.co checkout $ git co foo # 和 'git checkout foo' 一样另一个是在提示符或窗口标题上打印当前分支调用 :

35 $ git symbolic-ref HEAD 显示当前分支名在实际应用中, 你可能最想去掉 refs/heads/ 并忽略错误 : $ git symbolic-ref HEAD 2> /dev/null cut -b 12- 更多例子参见 Git 主页 ( 大胆的绝技最近版本的 Git 使得用户意外销毁数据变得更困难了这或许是升级的最令人瞩目的原因了虽然如此, 有时你的确想销毁数据我们展示如何覆盖为通用命令所设的防卫设施只在你知道你在做什么的时候使用他们 Checkout: 如果你有未提交的变更, 平常的 checkout 会失败销毁你的变更, 并无论如何都 checkout 一个指定的提交, 使用强制选项 : $ git checkout -f COMMIT 另外, 如果你为 checkout 指定的路径, 那就没有安全检查了提供的路径将被不加提示地覆盖如果你使用这种方式的 checkout, 一定要小心重置 : 在有未提交变更的情况下, 重置也会失败强制其通过, 运行 : $ git reset --hard [COMMIT] 分支 : 如果删除一个分支会导致变更丢失的, 删除操作会失败强制删除, 键入 : $ git branch -D BRANCH # 注意不是 -d 类似地, 试图通过移动覆盖一个分支也会失败, 如果数据确信会丢失的话强制移动分支, 键入 : $ git branch -M [SOURCE] TARGET # 注意不是 -m 不像 checkout 和重置, 这两个命令延迟数据销毁的时间这个变更仍然存储在.git 的子目录里, 并且可以通过恢复.git/logs 里的相应哈希值获取到 ( 参见上面猎捕 HEAD 一

36 节 ) 默认情况下, 这些数据会保存至少两星期

37 7. 解密我们揭开 Git 神秘面纱, 往里瞧瞧它是如何创造奇迹的我会跳过细节更深入的描述参见用户手册 ( 大象无形 Git 怎么这么谦逊寡言呢? 除了偶尔提交和合并外, 你可以如常工作, 就像不知道版本控制系统存在一样那是, 直到你需要它, 而且那时候你也很高兴 Git 一直默默注视着你整个的工作其他版本控制系统可不许你忘记他们在你显示地告诉服务器你打算编辑哪些文件前, 文件权限也许是只读的中心服务器可能正跟踪什么人, 什么时候 check out 了什么代码当网络连接断了的时候, 你就遭殃了开发人员不断地与这些版本控制系统的种种限制作斗争秘诀就在你工作目录里的.git 目录 Git 在这里记录你项目的历史最前面的. 使这个文件在 ls 的输出中不显示除了你的提交或同步变更以外, 所有版本控制操作都在这个目录里操作你对你文件的命运有完全的掌控, 因为 Git 根本不关心你对他们做了什么 Git 可以很容易地从.git 里重新创建出一个保存状态 7.2. 数据完整性很多人把加密和保持信息机密性关联起来, 但一个同等重要的目标是保证信息的安全性合理使用哈希加密功能可以防止意外地或恶意地数据损坏一个 SHA1 哈希值是一个 160 位的 ID 数, 用它可以唯一标识你一生中遇到的每个二进制字符串实际上不止如此 : 任何人几辈子用到的所有字符串都可以用它来唯一标识对一个文件而言, 其整体内容的哈希值可以被看作这个文件的唯一标识 ID 数一个重要的发现是, 一个 SHA1 哈希值本身也是一个二进制字符串, 因此我们可以为包含其他哈希值的字符串生成哈希值大略地讲, 所有 Git 处理的文件通过他们的唯一 ID 来引用, 而不是通过他们的文件名所有数据保存在.git/objects 子目录里, 那里你找不到任何标准的文件名文件内容都是我们叫做 blobs 的二进制字符串, 这些二进制字符串跟他们的文件名也是剥离的

38 而文件名会被记录在别的地方他们被存储在树对象里, 这里记录着文件名和他们内容的 ID 值对应关系列表既然树本身是一个二进制字符串, 它也有一个唯一 ID, 这也是它是如何被存储在.git/objects 子目录里的办法树可以出现在其他树的列表里, 因此一个目录树和其所有文件可以被表达为树和 blob 最终, 一个提交包含一条消息 : 一些树 ID 和他们之间如何关联的信息一个提交也是一个二进制字符串, 因为它也有一个唯一 ID 你可以自己看看 : 在.git/objects 目录里随便找一个哈希值, 然后键入 : $ git cat-file -p SHA1_HASH 现假设某人试图重写历史记录, 并准备更改一个古老版本里一个文件的内容那么这个文件的 ID 将被更改, 因为这个文件变成了另一个二进制字符串这会影响每一个引用这个文件的的树对象, 并导致所有与该树相关的已提交对象都需要被更改因为有多个文件中包含着错误的 ID, 当人们完成提交操作时, 就会发现这个遭到破坏的资源库我已经忽略了诸如文件权限和签名之类的细节但简单地讲, 只要 20 字节的长度就能代表最后的提交是安全的, 破坏 Git 资源库是不可能的 7.3. 智能 Git 是如何知道你重命名了一个文件, 即使你从来没有明确提及这个事实? 当然, 你或许是运行了 git mv, 但这个命令和 git add 紧接 git rm 是完全一致的 Git 启发式地找出相连版本之间的重命名和拷贝实际上, 它能检测文件之间代码块的移动或拷贝! 虽然它不能包揽所有的情况, 但它已经做的很好了, 并且这个功能也总在改进改进如果它在你那儿不工作的话, 可以尝试打开开销更高的拷贝检测选项, 并考虑升级 7.4. 索引为每个跟踪的文件,Git 在一个名为 index 的文件里记录其诸如大小, 创建时间和最后修改时间的信息 Git 比较其当前与在 index 里的统计资料, 以确定文件是否更改如果一致, 那 Git 就避免重新读取该文件因为调用统计资料比读文件内容的开销小很多, 如果你仅仅编辑了少数几个文件,Git 几乎不需要什么时间就能更新他们的状态

39 7.5. 裸资源库你或许想知道那些在线 Git 资源库用的是什么格式他们除了具有类似 proj.git 的名字以外, 和你的.git 目录一样, 是无格式的另一个不同点是他们没有关联任何工作目录大多数 Git 命令默认 Git 的索引是存放在.git 目录, 但在这些裸资源库上并不是这样, 所以会导致命令执行失败为了解决这个问题, 可以设置环境变量 GIT_DIR 来指定裸资源库所在路径, 或者在裸资源库的目录里运行 Git 时加上 --bare 选项 7.6. Git 起源 Linux 内核邮件列表上的一则帖子 ( 描述了形成 Git 的一系列事件对 Git 史学家而言, 整个的讨论是一个令人着迷的历史探索过程

40 8. Git 的缺点我避开了对一些 Git 现存问题的讨论有些可以通过脚本或回调方法轻易地解决, 有些需要重组或重定义项目, 还有少数无解问题, 只能暂时等待更好的办法是, 投入进来, 一起解决这些问题我对版本控制系统已经有了一些想法, 并基于 Git 写了一个实验性系统 ( 并解决了一部分问题 8.1. 微软 Windows Git 在微软 Windows 上可能有些繁琐 : Cygwin( 一个 Windows 下的类 Linux 的环境, 里面有一个 Windows 移植 Git( Git on MSys( 是另一个, 要求最小运行时支持, 不过一些命令不能马上工作 8.2. 无关的文件如果你的项目非常大, 包含很多无关的文件, 而且正在不断改变,Git 可能比其他系统更不管用, 因为独立的文件是不被跟踪的 Git 跟踪整个项目的变更, 这通常才是有益的一个方案是将你的项目拆成小块, 每个都由相关文件组成如果你仍然希望在同一个资源库里保存所有内容的话, 可以使用 git submodule 8.3. 谁在编辑什么? 一些版本控制系统在编辑前强迫你显示地用某个方法标记一个文件尽管这种要求很繁琐, 特别是这个动作需要和中心服务器通讯时它还是有以下两个好处的 : 1. 比较速度快, 因为只有被标记的文件需要检查 2. 通过查询在中心服务器上谁把某个文件标记为编辑状态, 人员可以获知还有谁正在编辑这个文件使用适当的脚本, 你也可以使用 Git 达到同样的效果这要求程序员协同工作, 当他编辑一个文件的时候还要运行特定的脚本 8.4. 文件历史因为 Git 记录的是项目范围的变更, 重造单一文件的变更历史比其他跟踪单一文件的版本控制系统要稍微麻烦些

41 好在麻烦还不大, 也是值得的, 因为 Git 其他的操作难以置信地高效例如,git checkout 比 cp -a 都快, 而且项目范围的 delta 压缩也比基于文件 delta 集合的做法好多了 8.5. 初始克隆当一个项目有相当长度的历史后, 与在其他版本系统里的检出代码相比, 创建一个克隆的开销会大的多从长时间使用看, 初始的代价还是值得付出的, 因为大多将来的操作将由此变得很快, 并可以离线完成然而, 在一些情况下, 使用 --depth 创建一个浅克隆比较划算些这种克隆初始化的更快, 但生成的克隆仅具有较少的功能 8.6. 不稳定的项目 Git 是变更的大小决定写入的速度快慢一般人做了小的改动就会提交新版本这里一行臭虫修改, 那里一个新功能, 修改掉的注释等等但如果你的文件在相邻版本之间存在极大的差异, 那每次提交时, 你的历史记录会以整个项目的大小增长任何版本控制系统对此都束手无策, 但标准的 Git 用户将遭受更多, 因为一般来说, 历史记录也会被克隆应该检查一下变更巨大的原因或许文件格式需要改变一下小修改应该仅仅导致几个文件的细小改动又或许, 数据库或备份 / 打包方案才是正选, 而不是版本控制系统例如, 版本控制就不适宜用来管理网络摄像头周期性拍下的照片如果这些文件实在需要持续更改, 实在需要版本控制, 一个可能的办法是以中心的方式使用 Git 可以创建浅克隆, 这样检出的较少, 也没有项目的历史记录当然, 很多 Git 工具就不能用了, 并且修复必须以补丁的形式提交这也许还不错, 因为似乎没人需要大幅度变化的不稳定文件历史另一个例子是基于固件的项目, 使用巨大的二进制文件形式用户对固件文件的变化历史没有兴趣, 更新的压缩比很低, 因此固件修订将使资源库无谓的变大这种情况, 源码应该保存在一个 Git 资源库里, 二进制文件应该单独保存为了简化问题, 应该发布一个脚本, 使用 Git 克隆源码, 对固件只做同步或 Git 浅克隆

42 8.7. 全局计数器一些中心版本控制系统维护一个正整数, 当一个新提交被接受的时候这个整数就增长 Git 则是通过哈希值来记录所有变更, 这在大多数情况下都工作的不错但一些人喜欢使用整数的方法幸运的是, 很容易就可以写个脚本, 这样每次更新, 中心 Git 资源库就增大这个整数, 或使用 tag 的方式, 把最新提交的哈希值与这个整数关联起来每个克隆都可以维护这么个计数器, 但这或许没什么用, 因为只有中心资源库以及它的计数器对每个人才有意义 8.8. 空子目录空子目录不可追踪可以通过创建一个空文件以绕过这个问题 Git 的当前实现, 而不是它的设计, 是造成这个缺陷的原因如果运气好, 一旦 Git 得到更多关注, 更多用户要求这个功能, 这个功能就会被实现 8.9. 初始提交传统的计算机系统从 0 计数, 而不是 1 不幸的是, 关于提交,Git 并不遵从这一约定很多命令在初始提交之前都不友好另外, 一些极少数的情况必须作特别地处理例如重订一个使用不同初始提交的分支 Git 将从定义零提交中受益 : 一旦一个资源库被创建起来,HEAD 将被设为包含 20 个零字节的字符串这个特别的提交代表一棵空的树, 没有父节点, 早于所有 Git 资源库然后运行 git log, 比如, 通知用户至今还没有提交过变更, 而不是报告致命错误并退出这与其他工具类似每个初始提交都隐式地成为这个零提交的后代例如, 重新修订一个不相关的分支将使得整个分支被加入到零提交里这样, 除了初始提交命令之外的所有命令都会被应用, 这会导致一个合并冲突一个绕过的办法是在初始提交上紧跟着 git commit -c, 再使用 git checkout, 之后继续重新修订剩下的不幸的是还有更糟糕的情况如果把几个具有不同初始提交的分支合并到一起, 之后的重新修订不可避免的需要人员的介入

Git 原理简介 Git 是一种分布式版本控制系统每个克隆的仓库都包含有整个仓库的所有数据任何修改先提交在本地, 再推送到服务器创建和切换分支合并修改相当方便而且快速本文档中第一次出现的术语将以蓝色斜体标出术语的含义是单一的明确的不可替代的 1

Git 原理简介 Git 是一种分布式版本控制系统每个克隆的仓库都包含有整个仓库的所有数据任何修改先提交在本地, 再推送到服务器创建和切换分支合并修改相当方便而且快速本文档中第一次出现的术语将以蓝色斜体标出术语的含义是单一的明确的不可替代的 1 Git 原理简介 Git 是一种分布式版本控制系统每个克隆的仓库都包含有整个仓库的所有数据任何修改先提交在本地, 再推送到服务器创建和切换分支合并修改相当方便而且快速本文档中第一次出现的术语将以蓝色斜体标出术语的含义是单一的明确的不可替代的 1 Git 仓库结构举例 git@my.server:bob/my.git master A B C 2 Git 仓库结构相对本地已克隆的仓库而言,