githug关卡小游戏，练习git

000 git区域的关系

几个专用名词的译名如下。

• Workspace：工作区
• Index / Stage：暂存区
• Repository：仓库区（或本地仓库）
• Remote：远程仓库

上面的内容来自阮一峰的博客，这里还可以看下常用列表，自己再补充一下缺失的部分就可以成为自己的常用列表了。

001

初始化一个仓库

git init

002

避免影响全局设置，设置为本地的用户名和邮箱，非全局–global

git config --local user.name gitpppgit config --local user.email [e-mail]

003

添加README到stage区

git add README

004

提交README，进入vim界面，点i输入内容，:wq保存并退出

git commit README

005

克隆到本地

git clone https://github.com/Gazler/cloneme

006

克隆到my_cloned_repo文件夹下

git clone https://github.com/Gazler/cloneme my_cloned_repo

007

在.gitignore下输入，忽略所有的后缀为.swp的文件

*.swp

008

查看gitignore的帮助，html页面，忽略所有后缀.a的文件除了lib.a

git gitignore --help

.gitignore文件内容

*.a!lib.a

009

查看stage状态，绿色为等待提交commit，红色为untracked，git rm –cached可以将待提交的文件变为unstage

git status

010

有多少个文件将要被提交

git status

011

一个文件在working tree中已经删除，但是repository中没有，请删除

git add deleteme.rbgit commit -m "delete"

012

一个文件在working tree中已经删除，但是repository中没有，请删除

git add deleteme.rbgit commit -m "delete"

013

修改了文件，想下次继续修改，保存但是不commit，加list可以查看进度列表，恢复使用git stash apply，支持多次提交，git用栈维护，WIP意思是work in progress。

git stashgit stash list

014

重命名文件，该文件已经处于staging状态，修改完后自动成为staging状态，git mv [source] [destination]。

lsgit statusgit mv oldfile.txt newfile.txtlsgit status

015

此题在powershell中执行

git mv *.html src、

会提示错误：

fatal: bad source, source=src/*.html, destination=src/src

以下改用git bash客户端运行，没有问题。

016

询问最近的提交的hash。

git log --stat

黄色行，commit后面的值为该次提交的hash值。

017

给当前commit新建一个tag

git tag new_tag

018

将所有tag推送到远端，–tags参数表示所有tag。这里不用切换到那个C盘目录文件夹，直接运行即可。

git push --tags origin master

019

README已经提交，但是本次commit遗漏了forgotten_file.rb，重做上一次提交并增加forgotten_file.rb。完成提交后两个文件归属于同一次commit。

git commit --amend -m "message"

不带提交信息的话，会进入vim编辑模式，i插入，esc然后:wq保存退出。

020

为提交指定一个未来的时间。加入-m避免进入vim。时间是DDMMYY

git commit --date=10.01.2017T14:00:00 -m "add README"

021

两个文件被意外一同添加到staging area，但想要分别提交，重置暂存区的指定文件，与上一次commit保持一致，但工作区不变。（不要提交）

git reset to_commit_second.rb

022

撤销上一次提交。几个参数的区别。

• –soft参数把撤销的修改放入staging area
• –mixed 参数将上一次的修改放入 working directory
• –hard 参数直接将上一次的修改抛弃

下面是命令行：

git reset --soft HEAD^1

023 checkout_file

文件被更改，但是不想保留更改，使用上一次的提交。这里我看到有的答案分享没有指定[commit]这个参数，那么其实是使用的staging area的数据，而不是题目要求的last commit。

# 恢复暂存区的指定文件到工作区$ git checkout [file]  # 恢复某个commit的指定文件到工作区$ git checkout [commit] [file]

以下为命令行：

# 看下当前状态git status# 查看当前分支的最近几次提交git reflog# 迁出HEAD@{0}指向的commit，用法类似stashgit checkout HEAD@{0} config.rb# 再看下config.rb变为上次的提交状态git status

024 remote

查看远端仓库，-v参数可以直接给出仓库的URL，不带则只有仓库名。命令已经在图上了。

025 remote_url

就是上一题带-v参数的结果。

026 pull

将远程仓库拉取到本地，pull命令相当于fetch和merge结果。

# 取回远程仓库的变化，并与本地分支合并$ git pull [remote] [branch]

027 remote_add

增加一个远程仓库。

# 增加一个新的远程仓库，并命名$ git remote add [shortname] [url]

028 push，其实重点是rebase

针对分支分叉的问题，两个分支都各自往前有几次提交，git pull可以拉取并merge，git rebase则是checkout并重定向。

git rebase origin/mastergit push origin master

如果本地有多个分支，记得先git branch查看一下是不是在需要rebase的分支上。先checkout远端的master分支，再将本地分支重定向到该分支的最新提交上，本地的提交也存在，和merge的区别是，merge看起来有一次新的提交指向合并，而rebase像没有发生合并一样。

• rebase图文讲解，非常好
• 这篇文章也比较清晰

029 diff

查看app.rb文件workspace部分与Stage部分的区别。

• 比较的是a版本app.rb(变动前)和b版本app.rb(变动后）的对比。
• index区域的hash短码为4f703ca的文件和workspace的3bfa839的文件，100644（对象模式：普通文件，644权限）
• —表示变动前的版本，+++表示变动后的版本
• 重点来了，@@ -23,7 +23,7 @@表示从第23行起连续显示的7行，内容是erb :success到最后的end后面的一行空白处，注意中间的内容-表示删除，+表示增加，所以这儿应该是一行，这个可以自己建文件多试试。同时了解下Unix下diff的几种不同显示方式。读懂diff，来自阮一峰博客
• 所以这题的答案应该是顺着数下去，23,24,25,26到了，26！。

git diff的几个常用命令

# 显示暂存区和工作区的差异$ git diff# 显示暂存区和上一个commit的差异$ git diff --cached [file]# 显示工作区与当前分支最新commit之间的差异$ git diff HEAD

030 blame -.-命令很excited

看看谁放入了password到代码中。Spider Man。

$ git blame config.rb

031 branch

想做一点微小的贡献在一段代码上，但是有破话其他东西的潜在危险，所以，新建一个名叫test_code的分支。

$ git branch test_code$ git branch

032 checkout

新建并切换到一个新的名叫my_branch的分支。

033 checkout_tag

切换到指定的tag v1.2。

可以看到通过git show [tag]的指令得到的hash信息，与checkout之后，HEAD指向的信息是一致的bb8be11…。提示如果要切换到一个新的分支可以使用git checkout -b new_branch_name tag

# 显示所有tag$ git tag# 切换到v1.2tag$ git checkout v1.2

034 checkout_tag_over_branch

和上题的要求一样，只不过这次恰好有一个分支也叫v1.2。利用githug hint获取的提示。

$ git checkout tags/v1.2

035 branch_at

忘记在前一次提交是创建分支，现在要在前一次commit上创建一个分支。同理，适用于任何一次提交。只需修改为对应的commit即可。

$ git branch test_branch HEAD^

036 delete_branch

删除指定的branch。

$ git branch -d delete_me

037 push_branch

在一个分支上做了改变但是不想merge到master分支，而只是将该分支推送到远端同名的分支。我的解法是先切换再push：

git branch test_branch# 官方解释，A handy way to push the current branch to the same name on the remote.git push origin HEAD

网上其他答案：

$ git push origin test_branch:test_branch

其他解释：

# 提交本地test分支 作为远程的master分支$ git push origin test:master  # 提交本地test分支作为远程的test分支$ git push origin test:test              

如果想删除远程的分支呢？类似于上面，如果:左边的分支为空，那么将删除:右边的远程的分支。

# 刚提交到远程的test将被删除，但是本地还会保存的$ git push origin :test  

038 merge

将feature分支合并到master分支。命令git merge [branch]是将[branch]这个分支合并到当前分支，所以要先checkout到正确的分支上。

039 fetch

将远端分支的修改下载到本地，但是并不合并到本地，pull = fetch + merge，所以用git fetch [branch]就可以了。

$ git fetch origin

040 rebase 28题已经用过了

feature rebase on to master，则先checkout feature分支，再git rebase master。
根据其他答案可以用git log –graph –all以图形化的方式查看分支，会用符号比较分支，rebase前后可以看看区别。

041 rebase_onto

题目：本来打算从master新建一个readme-update分支，结果错误的从wrong_branch新建了分支，并且已经有了一些提交。现在要将当前分支重新定位到master上，并且不保留wrong_branch的提交。

查看官方文档得到的答案，官方文档相关内容如下：
Here is how you would transplant a topic branch based on one branch to another, to pretend that you forked the topic branch from the latter branch, using rebase –onto.

First let’s assume your topic is based on branch next. For example, a feature developed in topic depends on some functionality which is found in next.

o---o---o---o---o  master     \      o---o---o---o---o  next                       \                        o---o---o  topic

We want to make topic forked from branch master; for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:

o---o---o---o---o  master    |            \    |             o'--o'--o'  topic     \      o---o---o---o---o  next

We can get this using the following command:

git rebase –onto master next topic

Another example of –onto option is to rebase part of a branch. If we have the following situation:

                        H---I---J topicB                       /              E---F---G  topicA             /A---B---C---D  master

then the command

git rebase --onto master topicA topicB

would result in:

             H'--I'--J'  topicB            /            | E---F---G  topicA            |/A---B---C---D  master

This is useful when topicB does not depend on topicA.

042 repack

优化仓库并清理冗余的packs。查看的官方文档。使用参数-d，解释如下：

After packing, if the newly created packs make some existing packs redundant, remove the redundant packs. Also run git prune-packed to remove redundant loose object files.

官方对于这个命令的描述：

This command is used to combine all objects that do not currently reside in a "pack", into a pack. It can also be used to re-organize existing packs into a single, more efficient pack.A pack is a collection of objects, individually compressed, with delta compression applied, stored in a single file, with an associated index file.Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc.

043 cherry-pick

新的特性不值得浪费时间了，准备删掉它，但是有一个README上的commit想要合并到master上。这个命令感觉挺实用的。

reflog可以看HEAD@{}来cherry-pick，而不用去复制完整的hash。

044 grep

项目快到期了，检查一下还有多少个TODO没有完成。
grep的官方指南参数很多，还可以匹配正则，感觉应该是个很强大的命令。
下面是官方对这个指令的描述。

DESCRIPTIONLook for specified patterns in the tracked files in the work tree, blobs registered in the index file, or blobs in given tree objects. Patterns are lists of one or more search expressions separated by newline characters. An empty string as search expression matches all lines.

045 rename_commit

重命名commit中的typo。
githug hint 提示使用rebase的-i参数。查询官方文档：

-i--interactive    Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).    The commit list format can be changed by setting the configuration option rebase.instructionFormat. A customized instruction format will automatically have the long commit hash prepended to the format.

先用git reflog查看最近的几次变动。

需要修改的是HEAD@{1}那一次commit。则用git rebase -i HEAD@{2}定位到这次commit之后的所有提交。这里可以接受修改选择。


将First coommit前的pick改为reword，表示使用commit但是要编辑其信息。:wq保存并退出。
下面的图是最后修改commit msg的地方，和提交是填写msg的画面是类似的，不过下面有interactive rebase的信息。

:wq保存并退出完成提交。系统就会执行rebase，并提示成功。

046 squash 挤压

将多个commit合并为1个。和前一题一样也是用rebase的交互模式，不过是用的squash而非reword。过程都类似就不一一贴图了，就是最后重写commit的时候，它初始是几个commit msg的合并，不要的话记得dd删掉。

047 merge_squash

将分支上的所有提交合并为一个。合并后的修改默认在Stage区，所以别忘了自己commit。
参考自SO上的答案：

Say your bug fix branch is called bugfix and you want to merge it into master:git checkout mastergit merge --squash bugfixgit commitThis will take all the commits from the bugfix branch, squash them into 1 commit and then merge it with your master branch.

048 reorder

多次提交顺序错误，重新排序提交。同样也是万能的rebase -i交互模式，这次是直接在该模式下编辑顺序即可，注意系统提示默认顺序是top to bottom，也就是最后一行才是最近的提交，dd剪切一行然后P到需要的位置，:wq保存退出就可以了。

049 bisect

这题的bisect命令暂时不太明白，题目意思是不知道从哪个版本开始引入了一个bug，文件里面包含了测试代码，找出引入bug的commit hash的前7位字符。
确认范围和测试：

$ git bisect master f608824888b83bbedc1f658be7496ffea467a8fb$ git bisect run make test

通过git bisect log查看对比的结果，可以看到哪些是bad，哪些是good，以及哪个commit是first bad commit。

答案：18ed2ac1，按照这个操作其他人有这个结果，我有一个make command not found的错误，所以答案始终有问题。

050 stage_lines

对单个文件做了修改，涉及了两个不同的特性，都没有add到Stage区，想要只stage第一个特性的修改。选e进入编辑模式后，删掉不想stage的行，留下first feature那行，保存退出会自动分期进入stage区，git status可以看到一个feature.rb在stage区，一个在workspace，git diff可以查看两个的差别。

-p--patchInteractively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.This effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand. See “Interactive mode” for details.y - stage this hunkn - do not stage this hunkq - quit; do not stage this hunk or any of the remaining onesa - stage this hunk and all later hunks in the filed - do not stage this hunk or any of the later hunks in the fileg - select a hunk to go to/ - search for a hunk matching the given regexj - leave this hunk undecided, see next undecided hunkJ - leave this hunk undecided, see next hunkk - leave this hunk undecided, see previous undecided hunkK - leave this hunk undecided, see previous hunks - split the current hunk into smaller hunkse - manually edit the current hunk? - print help

051 find_old_branch

之前多次使用的git reflog命令，可以查看最近多次操作，不限于commit。回到之前工作的分支，但是忘了名字，可以看看最近的checkout操作记录。

052 revert

revert只会影响指定的commit，但是reset会影响后续的commit。

053 restore

删掉了最近一次commit，想要恢复，可以用reflog查看最近的操作记录，找到要恢复的那次commit操作记录，然后checkout。

054 conflict

将分支合并到master时有冲突，找到冲突文件修改后，文件在工作区，需要stage和commit。

055 submodule

以下为引用内容：
开发过程中，经常会有一些通用的部分希望抽取出来做成一个公共库来提供给别的工程来使用，而公共代码库的版本管理是个麻烦的事情。今天无意中发现了git的git submodule命令，之前的问题迎刃而解了。
添加
为当前工程添加submodule，命令如下：

git submodule add 仓库地址 路径

其中，仓库地址是指子模块仓库地址，路径指将子模块放置在当前工程下的路径。
注意：路径不能以 / 结尾（会造成修改不生效）、不能是现有工程已有的目录（不能順利 Clone）.
命令执行完成，会在当前工程根路径下生成一个名为“.gitmodules”的文件，其中记录了子模块的信息。添加完成以后，再将子模块所在的文件夹添加到工程中即可。
删除
submodule的删除稍微麻烦点：首先，要在“.gitmodules”文件中删除相应配置信息。然后，执行“git rm –cached ”命令将子模块所在的文件从git中删除。
下载的工程带有submodule
当使用git clone下来的工程中带有submodule时，初始的时候，submodule的内容并不会自动下载下来的，此时，只需执行如下命令：

git submodule update --init --recursive

即可将子模块内容下载下来后工程才不会缺少相应的文件。

056 contribute

注意这关不是在测试你创建pull request的能力，而是真的邀请大家去github上为这个项目共享有用的代码和文档。

最后

通过这56关的练习，大致对git各方面的能力有了初步了解，日常解决一些问题应该足够了，从解决问题的过程中也发现了，官方文档真的是一份很重要的资料，一定要学会阅读官方文档。git这么强大的功能也难怪《git权威指南》是一本那么厚的书。

所有关卡名字：

#1: init#2: config#3: add#4: commit#5: clone#6: clone_to_folder#7: ignore#8: include#9: status#10: number_of_files_committed#11: rm#12: rm_cached#13: stash#14: rename#15: restructure#16: log#17: tag#18: push_tags#19: commit_amend#20: commit_in_future#21: reset#22: reset_soft#23: checkout_file#24: remote#25: remote_url#26: pull#27: remote_add#28: push#29: diff#30: blame#31: branch#32: checkout#33: checkout_tag#34: checkout_tag_over_branch#35: branch_at#36: delete_branch#37: push_branch#38: merge#39: fetch#40: rebase#41: rebase_onto#42: repack#43: cherry-pick#44: grep#45: rename_commit#46: squash#47: merge_squash#48: reorder#49: bisect#50: stage_lines#51: find_old_branch#52: revert#53: restore#54: conflict#55: submodule#56: contribute