githug闯关记录(1-10)

githug闯关记录(11-20)

githug闯关记录(21-30)

githug闯关记录(31-40)

githug闯关记录(41-55)

第41关

Optimise how your repository is packaged ensuring that redundant packs are removed.

优化仓库,删除多余的冗余的包


第42关

Your new feature isn't worth the time and you're going to delete it. But it has one commit that fills in README file, and you want this commit to be on the master as well.

有时候你的写的功能需要改,本来准备删除,有个commit事对一个工具的修改,这是需要从特性分支上把这个commit摘下来。先看看分支名。

查了下log命令,可以指定分支。这就省去了checkout到特性分支了。


上图中最后的一次提交就是我们需要摘出来的,复制它的 Hash。


第43关

Your project's deadline approaches, you should evaluate how many TODOs are left in your code

我们在开发的过程中,为了不影响当前正在做的事情,会把一些不那么紧急的任务使用 TODO 注释在代码里,现代的 IDE 都能帮我们识别这些注释并在一个单独的窗口中罗列出来。

当然,不借助 IDE,光凭系统命令或 git 命令也是可以做到的。


显示有4行,输入4,过关!

第44关

Correct the typo in the message of your first (non-root) commit.

排错,查看log,git log --oneline,可以看到中间的commit拼写错了。


看一下提示,可以在rebase的时候指定 -i 参数。是interactive的意思。


在打开的 Vim 窗口中将第一行的 pick 改为 r,表示:使用 commit,并且修改 commit message。第一个vim窗口忘了截图了。第二个修正拼写错误的 coommit。



第45关

You have committed several times but would like all those changes to be one commit.

当进行非常频繁的提交时,会看起来缺乏完整性,也会增加后续维护成本。所以git让我可以在push到远程仓库之前,先commit历史进行修改合并,把多个commit合并成一个。

先用git log --oneline 看一下提交记录。


从提交记录可以看出,它提示我们将最后三个 commit 都合并到第二个 commit - Adding README 中。
接着执行 git rebase -i HEAD~4


第一个 commit 为 pick,后三个改为 s,意思是使用这个 commit,但将它合并到前一个 commit 中去。


保存退出,会提示我们编辑 commit message,再次保存退出后,查看一下提交记录:


第46关

Merge all commits from the long-feature-branch as a single commit.

题目要求在 merge 特性分支时,把所有的新提交合并成一个,先来看看 master 分支当成的状态:

git log --oneline


再看一下 git log long-feature-branch --oneline


完整过关命令如下:



第47关

You have committed several times but in the wrong order. Please reorder your commits.

提交顺序错乱时,也可以使用 git rebase -i 进行调整。

先看看 Log,最后两个提交颠倒了位置:


执行 git rebase -i HEAD~2,将两行 pick xxx 代码交换位置即可。




第48关

A bug was introduced somewhere along the way. You know that running ruby prog.rb 5 should output 15. You can also run make test. What are the first 7 chars of the hash of the commit that introduced the bug.

看一下历史


代码中不知道什么时候引入了 bug,不过没关系,我们有自动化测试。

我们可以不断手工 checkout 到某个 commit,结合二分法查找快速定位到引入 bug 的那一个 commit。

不过这种纯手工重复的事情,已经包含在 git 的命令中了,就是 bisect.


我们知道 HEAD 的代码是有问题的,而第一个 commit 的代码是没问题的。
通过 git log 获得第一个 commit 的 Hash,就可以执行 bisect 命令:


红线部分已经清楚地告诉我们是哪个 commit 引入的 bug 了。


这里重玩也不行,提交前七位字符还是不过关,可能是我的git没有安装make的原因,我就直接跳关了。。。

第49关

有时开发了一个特性没提交,接着又开发了另一个特性。

作为一个自律的程序员,应该是要分两次提交的,如果修改的是不同的文件,那可以轻松地通过 add 不同的文件进行两次提交。

但这次好巧不巧的是居然修改了同一个文件,怎么办?看看提示:


原来 git add 的最小粒度不是「文件」,而是 hunk(代码块)。

git help add 然后查找 hunk,发现-p参数。


Git 会让我们有机会选择对每一个 hunk 做什么样的操作。这里修改同一个位置,在一个 hunk 里,根据提示我们还要输入 e 手工编辑 hunk。


将第 5 行删除,保存退出,再看当前状态:





第50关

有时候分支太多,或者命名没有规律时,忘记了旧的分支名字,如何找到它们的,一般可以通过git branch看看,也能找到分支。

先看看帮助。


使用命令 git reflog看下,有点乱,可以加--all参数看看。


第二行就是我们之前工作的分支。


第51关

有时代码 push 到远程仓库后发现某一块代码有问题,我们可以通过 revert 命令将特定 commit 完全恢复。

首先我们要找到需要 revert 的 commit 的 hash:




第52关

刚刚把最新的一次提交给毫无保留的扔掉,马上就改了主意,怎么办?世界上有后悔药吗?

有的,只要进行 git 版本控制的一切都能找得回来。看下提示先:


还是使用git reflog --all



第53关

冲突合并是使用版本控制非常常见的了,居然在这么靠后的位置才出来。


编辑冲突的文件 poem.txt,删除 Git 添加的标识冲突的行。

修改前


修改后


最后别忘了还要 git add poem.txt 然后 git commit -m poem.txt



第54关

看看帮助。。


submodule 是 Git 组织大型项目的一种方式,通常可把第三方依赖作为 submodule 包含进来,这个 submodule 本身也是一个独立的 Git 项目。


第55关

最后这一关并非测试使用 GitHub 的能力,而是期望大家贡献代码,包括增加更多关卡,修复 Bug 或者完善文档。



## 总结

一共花费了十几天的时间玩这个游戏,主要是没有时间玩,最主要的是问题实在是太多了。

还要感谢@hkliya大大写的攻略,我是看着攻略过的,进步了好多很多,也学习到了很多

最后由 不一样的少年 编辑于2016年12月11日 15:23