突然发觉,古人其实特别有趣,譬如有古语云:『常在河边走,哪有不湿鞋』,实在是富有生活气息的一句俗语,可古人又有言语:『光脚的不怕穿鞋的』,更是朴实无华的一句话。上周下班适逢天降大雨,我撑伞送一位同事到地铁站,结果走到半路人家来一句,“你快点走吧,我穿着凉鞋”,一时竟无语凝噎。常在河边走,固然会有湿鞋的顾虑,可真正的气度绝不是光着脚满地跑,如何做到湿了鞋子而不慌呢?答案是脚上无凉鞋而心中有凉鞋。今天,我将为大家我在使用Git过程中如何“湿鞋”、如何不怕“湿鞋”的一个故事(逃

蓝屏重启后Git居然坏了?

中国传统小说喜欢从神话讲起,端的是汪洋恣肆、纵横捭阖。而国外小说则喜欢从一片常青藤叶这种不显眼的事物写起,足可见二者见天地众生视角之不同。而我这个故事,是再普通不过的一次蓝屏。重启后Visual Studio提示恢复了未保存的代码,此时,我并未注意到Git仓库损坏的情况,就这样,我在一个“游离态”的版本上编写代码,直到我打开SourceTree的时候(作者注:我就是那个命令行和GUI混合使用的奇葩),发现左侧本地分支全部消失,在命令行里git status,发现根本没有这个分支,而.git/refs/对应分支指向了一个错误的Hash,我意识到我的Git仓库文件可能损坏了,这意味着我写的新feature可能丢失了,此时,Git中提示的类似的错误信息:

1
$ error: refs/remotes/origin/HEAD: invalid sha1 pointer 0000000000000000000000000000000000000000

在此之前,其实博主已经经历过类似的事情,在没有未提交的代码的情况下,其实可以暴力删除. git目录,然后在git init即可,这相当于重新初始化仓库啦,在这种情况下,本地的分支会被删掉,你需要重新建新分支。可是这次不一样啊,在做的是一个即将发版的新feature,不允许我出这样的选择啊!博主双掌合一,像夏洛克一样冷静思考,缓缓地在命令行下敲出git reflog,这条命令相当于你在Git 中的监控日志,你对Git所做的一切都会成为呈堂证供。此时,你会得到下面的信息——沉默是今晚的康桥……

1
$ fatal: You are on a branch yet to be born

这是什么意思呢?意思就是这个分支还是一个“新生儿“的状态,新生儿怎么可能又活动记录呢?所以,使用Git的准则之一,只要仓库没有坏,通过git reflog找到对应的Hash ,git checkout就可以找回代码,哪怕你刚刚手滑删除了一个未提交的分支,这种情况下都可以找回来。But 现在这种状况下,这条路显然是走不通啦。继续双掌合一,像夏洛克一样冷静思考,每个分支里其实是记录着一个hash ,对应着最后的一次提交,现在是这个hash不对,那就要找到正确的hash啊。命令行已经非常明确地告诉你,是因为某些object丢失或者损坏了,那不妨先用git fsck试试。

1
2
3
4
5
6
7
8
9
10
11
$ git fsck
notice: HEAD points to an unborn branch (master)
Checking object directories: 100% (256/256), done.
Checking objects: 100% (589/589), done.
error: refs/remotes/origin/HEAD: invalid sha1 pointer 0000000000000000000000000000000000000000
notice: No default references
dangling tag 92d0fe18f9a55177d955edf58048b49db7987d5b
dangling commit aa7856977e80d11833e97b4151f400a516316179
dangling commit 16e449da82ec8bb51aed56c0c4c05473442db90a
dangling commit 864c345397fcb3bdb902402e17148e19b3f263a8
dangling tag be9471e1263a78fd765d4c72925c0425c90d3d64

此时,我们就会得到这样的信息。我天,这简直太良心了好吧,连哪一个object丢了都明明白白地告诉你。既然是提示解包(unpack)的时候失败,不妨先手动解包看看呗,好吧,果然程序是不会欺骗人的。这个时候,我注意到这些里面有一些提交(commit),我在想这些有没有可能是残留的有效分支,于是使用下面的命令创建临时分支,一番折腾发现这些分支都离我的分支比较远,所以,基本可以排除了。

1
2
3
4
5
//尝试手动解包
$ mv .git/objects/pack/pack-0672bd01813664b80248dbe8330bf52da9c02b9f.pack .
$ git unpack-objects -r < pack-0672bd01813664b80248dbe8330bf52da9c02b9f.pack
//从某个commit新建临时分支
$ git update-ref refs/heads/recovery-1 aa7856977e80d11833e97b4151f400a516316179

我又不甘心地看了看git fsck命令,发现它居然有一个--lost-found的参数可以用,这样子,我居然就得到一个名为lost-found的文件夹,它里面有一些以hash命名的文件,我挑选了一个离我蓝屏时间最近的文件,直接git checkout过去,发现这正是我需要的内容,赶紧git checkout –b存档,这实在是太珍贵了!

1
2
3
4
5
6
7
8
9
10
11
12
13
$ git fsck --lost-found
error: inflate: data stream error (unknown compression method)
error: unable to unpack header of .git/objects/67/781ba4991aee01c0bc0d640ae9ee8b674b2f47
error: 67781ba4991aee01c0bc0d640ae9ee8b674b2f47: object corrupt or missing: .git/objects/67/781ba4991aee01c0bc0d640ae9ee8b674b2f47
error: inflate: data stream error (unknown compression method)
error: unable to unpack header of .git/objects/6f/34f2bbde304619622f77f9ca159ed97b6ddafd
error: 6f34f2bbde304619622f77f9ca159ed97b6ddafd: object corrupt or missing: .git/objects/6f/34f2bbde304619622f77f9ca159ed97b6ddafd
error: inflate: data stream error (unknown compression method)
error: unable to unpack header of .git/objects/89/6e969a25c2238ebbb41e895753e82da1cdc7af
error: 896e969a25c2238ebbb41e895753e82da1cdc7af: object corrupt or missing: .git/objects/89/6e969a25c2238ebbb41e895753e82da1cdc7af
error: inflate: data stream error (unknown compression method)
error: unable to unpack header of .git/objects/d8/a180969f6cf8047def4b50c7c920dcd2b6f5cd
error: d8a180969f6cf8047def4b50c7c920dcd2b6f5cd: object corrupt or missing: .git/objects/d8/a180969f6cf8047def4b50c7c920dcd2b6f5cd

其实,接触Git的这些年里,使用命令行并没有让我觉得Git难以接近,相反它让我对GUI理解更深一点,就像好多人分不清pullfetch,因为你不看命令行的输出啊;有好多人每次SourceTree一报错就不知道该怎么办 ,其实Git给的提示真的相当清晰了;我之前一直不知道什么叫cherry-pick,后来发现这玩意儿就是我们所说的“补丁”。平时这种问题可能就放过去了,可这次“扶大厦于将顷”,让代码失而复得的经历,的确令人难忘,所以,我更想把它写下来,当你都能真正驾驭它了,是用命令行还是用GUI 就真的不在重要啦!这次的一个例外是索引没有坏,如果索引坏了,可以试试下面的命令:git reset --mixed。我还是坚持一个观点,Git仓库坏了,能修复尽量去修复,不到万不得已,千万不要去删. git目录

各种场景下的Git恢复/撤销

在这篇文章刚开始的时候,我问大家,如何做到湿了鞋子而不慌呢?答案是脚上无凉鞋而心中有凉鞋。虽然Git本身是一款非常复杂的软件,可我们依然有很多的策略去应对各种“失误”,正如这篇文章 Undoing all kinds of mistakes 所言,Git深知人类都是不完美的,面对平时使用Git过程中的各种失误,我们可以尝试使用下面的思路来解决。

更改未提交到暂存区

1
2
3
4
//放弃所有文件的更改
$ git reset --hard
//放弃指定文件的更新
$ git checkout -- <path/to/file>

更改已提交到暂存区

1
2
3
4
5
6
7
8
9
10
//回到最近的一次提交(改变指针)
$ git reset --hard HEAD^
//回到某一次提交(改变指针)
$ git reset --hard <commitId>
//全部放弃=回到最近的一次提交(改变指针)
$ git reset --hard 全部放弃
//放弃提交指定文件
$ git reset HEAD <path/to/file>
//修改提交信息
$ git commit --amend

更改已推送到远程服务器

1
2
3
4
5
6
//撤销前一次提交(产生新的提交)
$ git revert HEAD
//撤销前前一次提交(产生新的提交)
$ git revert HEAD^
//撤销某一个提交(产生新的提交)
$ git revert commit

万能公式

1
2
3
4
5
//万能公式
$ git reflog
$ git checkout <commitId>
//退而求其次
$ git fsck --lost-found

除了SourceTree,我想安利第二个Git GUI工具:Fork,大家感兴趣的话可以安装试用。

参考链接