git init

git config --local user.name gitppp
git config --local user.email [email protected]

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.rb
git commit -m "delete"

012

一個檔案在working tree中已經刪除，但是repository中沒有，請刪除

git add deleteme.rb
git commit -m "delete"

013

修改了檔案，想下次繼續修改，儲存但是不commit，加list可以檢視進度列表，恢復使用git stash apply，支援多次提交，git用棧維護，WIP意思是work in progress。

git stash
git stash list

014

重新命名檔案，該檔案已經處於staging狀態，修改完後自動成為staging狀態，git mv [source] [destination]。

ls
git status
git mv oldfile.txt newfile.txt
ls
git 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
# 遷出[email protected]{0}指向的commit，用法類似stash
git checkout [email protected]{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/master
git push origin master

如果本地有多個分支，記得先git branch檢視一下是不是在需要rebase的分支上。先checkout遠端的master分支，再將本地分支重定向到該分支的最新提交上，本地的提交也存在，和merge的區別是，merge看起來有一次新的提交指向合併，而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可以看[email protected]{}來cherry-pick，而不用去複製完整的hash。

044 grep

專案快到期了，檢查一下還有多少個TODO沒有完成。
grep的官方指南引數很多，還可以匹配正則，感覺應該是個很強大的命令。
下面是官方對這個指令的描述。

DESCRIPTION

Look 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檢視最近的幾次變動。

需要修改的是[email protected]{1}那一次commit。則用git rebase -i [email protected]{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 master
git merge --squash bugfix
git commit

This 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
--patch

Interactively 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 hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - 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