000 git區域的關系

幾個專用名詞的譯名如下。

• Workspace：工作區
• Index / Stage：暫存區
• Repository：倉庫區（或本地倉庫）
• Remote：遠程倉庫

上面的內容來自阮一峰的博客，這里還可以看下常用列表，自己再補充一下缺失的部分就可以成為自己的常用列表了。

001

初始化一個倉庫

git init

002

避免影響全局設置，設置為本地的用戶名和郵箱，非全局–global

git config --local user.name gitppp git config --local user.email 26huitailang@gmail.com

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 # 遷出HEAD@{0}指向的commit，用法類似stash git 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/master git 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 --interactiveMake 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 master git merge --squash bugfix git 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 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

總結

以上是生活随笔為你收集整理的githug关卡小游戏，练习git的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。