000 git區(qū)域的關(guān)系

幾個(gè)專用名詞的譯名如下。

• Workspace：工作區(qū)
• Index / Stage：暫存區(qū)
• Repository：倉庫區(qū)（或本地倉庫）
• Remote：遠(yuǎn)程倉庫

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

001

初始化一個(gè)倉庫

git init

002

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

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

003

添加README到stage區(qū)

git add README

004

提交README，進(jìn)入vim界面，點(diǎn)i輸入內(nè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文件內(nèi)容

*.a !lib.a

009

查看stage狀態(tài)，綠色為等待提交commit，紅色為untracked，git rm –cached可以將待提交的文件變?yōu)閡nstage

git status

010

有多少個(gè)文件將要被提交

git status

011

一個(gè)文件在working tree中已經(jīng)刪除，但是repository中沒有，請(qǐng)刪除

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

012

一個(gè)文件在working tree中已經(jīng)刪除，但是repository中沒有，請(qǐng)刪除

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

013

修改了文件，想下次繼續(xù)修改，保存但是不commit，加list可以查看進(jìn)度列表，恢復(fù)使用git stash apply，支持多次提交，git用棧維護(hù)，WIP意思是work in progress。

git stash git stash list

014

重命名文件，該文件已經(jīng)處于staging狀態(tài)，修改完后自動(dòng)成為staging狀態(tài)，git mv [source] [destination]。

ls git status git mv oldfile.txt newfile.txt ls git status

015

此題在powershell中執(zhí)行

git mv *.html src、

會(huì)提示錯(cuò)誤：

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

以下改用git bash客戶端運(yùn)行，沒有問題。

016

詢問最近的提交的hash。

git log --stat

黃色行，commit后面的值為該次提交的hash值。

017

給當(dāng)前commit新建一個(gè)tag

git tag new_tag

018

將所有tag推送到遠(yuǎn)端，–tags參數(shù)表示所有tag。這里不用切換到那個(gè)C盤目錄文件夾，直接運(yùn)行即可。

git push --tags origin master

019

README已經(jīng)提交，但是本次commit遺漏了forgotten_file.rb，重做上一次提交并增加forgotten_file.rb。完成提交后兩個(gè)文件歸屬于同一次commit。

git commit --amend -m "message"

不帶提交信息的話，會(huì)進(jìn)入vim編輯模式，i插入，esc然后:wq保存退出。

020

為提交指定一個(gè)未來的時(shí)間。加入-m避免進(jìn)入vim。時(shí)間是DDMMYY

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

021

兩個(gè)文件被意外一同添加到staging area，但想要分別提交，重置暫存區(qū)的指定文件，與上一次commit保持一致，但工作區(qū)不變。（不要提交）

git reset to_commit_second.rb

022

撤銷上一次提交。幾個(gè)參數(shù)的區(qū)別。

• –soft參數(shù)把撤銷的修改放入staging area
• –mixed 參數(shù)將上一次的修改放入 working directory
• –hard 參數(shù)直接將上一次的修改拋棄

下面是命令行：

git reset --soft HEAD^1

023 checkout_file

文件被更改，但是不想保留更改，使用上一次的提交。這里我看到有的答案分享沒有指定[commit]這個(gè)參數(shù)，那么其實(shí)是使用的staging area的數(shù)據(jù)，而不是題目要求的last commit。

# 恢復(fù)暫存區(qū)的指定文件到工作區(qū) $ git checkout [file] # 恢復(fù)某個(gè)commit的指定文件到工作區(qū) $ git checkout [commit] [file]

以下為命令行：

# 看下當(dāng)前狀態(tài) git status # 查看當(dāng)前分支的最近幾次提交 git reflog # 遷出HEAD@{0}指向的commit，用法類似stash git checkout HEAD@{0} config.rb # 再看下config.rb變?yōu)樯洗蔚奶峤粻顟B(tài) git status

024 remote

查看遠(yuǎn)端倉庫，-v參數(shù)可以直接給出倉庫的URL，不帶則只有倉庫名。命令已經(jīng)在圖上了。

025 remote_url

就是上一題帶-v參數(shù)的結(jié)果。

026 pull

將遠(yuǎn)程倉庫拉取到本地，pull命令相當(dāng)于fetch和merge結(jié)果。

# 取回遠(yuǎn)程倉庫的變化，并與本地分支合并 $ git pull [remote] [branch]

027 remote_add

增加一個(gè)遠(yuǎn)程倉庫。

# 增加一個(gè)新的遠(yuǎn)程倉庫，并命名 $ git remote add [shortname] [url]

028 push，其實(shí)重點(diǎn)是rebase

針對(duì)分支分叉的問題，兩個(gè)分支都各自往前有幾次提交，git pull可以拉取并merge，git rebase則是checkout并重定向。

git rebase origin/master git push origin master

如果本地有多個(gè)分支，記得先git branch查看一下是不是在需要rebase的分支上。先checkout遠(yuǎn)端的master分支，再將本地分支重定向到該分支的最新提交上，本地的提交也存在，和merge的區(qū)別是，merge看起來有一次新的提交指向合并，而rebase像沒有發(fā)生合并一樣。

• rebase圖文講解，非常好
• 這篇文章也比較清晰

029 diff

查看app.rb文件workspace部分與Stage部分的區(qū)別。

• 比較的是a版本app.rb(變動(dòng)前)和b版本app.rb(變動(dòng)后）的對(duì)比。
• index區(qū)域的hash短碼為4f703ca的文件和workspace的3bfa839的文件，100644（對(duì)象模式：普通文件，644權(quán)限）
• —表示變動(dòng)前的版本，+++表示變動(dòng)后的版本
• 重點(diǎn)來了，@@ -23,7 +23,7 @@表示從第23行起連續(xù)顯示的7行，內(nèi)容是erb :success到最后的end后面的一行空白處，注意中間的內(nèi)容-表示刪除，+表示增加，所以這兒應(yīng)該是一行，這個(gè)可以自己建文件多試試。同時(shí)了解下Unix下diff的幾種不同顯示方式。讀懂diff，來自阮一峰博客
• 所以這題的答案應(yīng)該是順著數(shù)下去，23,24,25,26到了，26！。

git diff的幾個(gè)常用命令

# 顯示暫存區(qū)和工作區(qū)的差異 $ git diff # 顯示暫存區(qū)和上一個(gè)commit的差異 $ git diff --cached [file] # 顯示工作區(qū)與當(dāng)前分支最新commit之間的差異 $ git diff HEAD

030 blame -.-命令很excited

看看誰放入了password到代碼中。Spider Man。

$ git blame config.rb

031 branch

想做一點(diǎn)微小的貢獻(xiàn)在一段代碼上，但是有破話其他東西的潛在危險(xiǎn)，所以，新建一個(gè)名叫test_code的分支。

$ git branch test_code $ git branch

032 checkout

新建并切換到一個(gè)新的名叫my_branch的分支。

033 checkout_tag

切換到指定的tag v1.2。

可以看到通過git show [tag]的指令得到的hash信息，與checkout之后，HEAD指向的信息是一致的bb8be11…。提示如果要切換到一個(gè)新的分支可以使用git checkout -b new_branch_name tag

# 顯示所有tag $ git tag # 切換到v1.2tag $ git checkout v1.2

034 checkout_tag_over_branch

和上題的要求一樣，只不過這次恰好有一個(gè)分支也叫v1.2。利用githug hint獲取的提示。

$ git checkout tags/v1.2

035 branch_at

忘記在前一次提交是創(chuàng)建分支，現(xiàn)在要在前一次commit上創(chuàng)建一個(gè)分支。同理，適用于任何一次提交。只需修改為對(duì)應(yīng)的commit即可。

$ git branch test_branch HEAD^

036 delete_branch

刪除指定的branch。

$ git branch -d delete_me

037 push_branch

在一個(gè)分支上做了改變但是不想merge到master分支，而只是將該分支推送到遠(yuǎn)端同名的分支。我的解法是先切換再push：

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

網(wǎng)上其他答案：

$ git push origin test_branch:test_branch

其他解釋：

# 提交本地test分支 作為遠(yuǎn)程的master分支 $ git push origin test:master # 提交本地test分支作為遠(yuǎn)程的test分支 $ git push origin test:test

如果想刪除遠(yuǎn)程的分支呢？類似于上面，如果:左邊的分支為空，那么將刪除:右邊的遠(yuǎn)程的分支。

# 剛提交到遠(yuǎn)程的test將被刪除，但是本地還會(huì)保存的 $ git push origin :test

038 merge

將feature分支合并到master分支。命令git merge [branch]是將[branch]這個(gè)分支合并到當(dāng)前分支，所以要先checkout到正確的分支上。

039 fetch

將遠(yuǎn)端分支的修改下載到本地，但是并不合并到本地，pull = fetch + merge，所以用git fetch [branch]就可以了。

$ git fetch origin

040 rebase 28題已經(jīng)用過了

feature rebase on to master，則先checkout feature分支，再git rebase master。
根據(jù)其他答案可以用git log –graph –all以圖形化的方式查看分支，會(huì)用符號(hào)比較分支，rebase前后可以看看區(qū)別。

041 rebase_onto

題目：本來打算從master新建一個(gè)readme-update分支，結(jié)果錯(cuò)誤的從wrong_branch新建了分支，并且已經(jīng)有了一些提交。現(xiàn)在要將當(dāng)前分支重新定位到master上，并且不保留wrong_branch的提交。

查看官方文檔得到的答案，官方文檔相關(guān)內(nèi)容如下：
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

優(yōu)化倉庫并清理冗余的packs。查看的官方文檔。使用參數(shù)-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.

官方對(duì)于這個(gè)命令的描述：

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

新的特性不值得浪費(fèi)時(shí)間了，準(zhǔn)備刪掉它，但是有一個(gè)README上的commit想要合并到master上。這個(gè)命令感覺挺實(shí)用的。

reflog可以看HEAD@{}來cherry-pick，而不用去復(fù)制完整的hash。

044 grep

項(xiàng)目快到期了，檢查一下還有多少個(gè)TODO沒有完成。
grep的官方指南參數(shù)很多，還可以匹配正則，感覺應(yīng)該是個(gè)很強(qiáng)大的命令。
下面是官方對(duì)這個(gè)指令的描述。

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參數(shù)。查詢官方文檔：

-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查看最近的幾次變動(dòng)。

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


將First coommit前的pick改為reword，表示使用commit但是要編輯其信息。:wq保存并退出。
下面的圖是最后修改commit msg的地方，和提交是填寫msg的畫面是類似的，不過下面有interactive rebase的信息。

:wq保存并退出完成提交。系統(tǒng)就會(huì)執(zhí)行rebase，并提示成功。

046 squash 擠壓

將多個(gè)commit合并為1個(gè)。和前一題一樣也是用rebase的交互模式，不過是用的squash而非reword。過程都類似就不一一貼圖了，就是最后重寫commit的時(shí)候，它初始是幾個(gè)commit msg的合并，不要的話記得dd刪掉。

047 merge_squash

將分支上的所有提交合并為一個(gè)。合并后的修改默認(rèn)在Stage區(qū)，所以別忘了自己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

多次提交順序錯(cuò)誤，重新排序提交。同樣也是萬能的rebase -i交互模式，這次是直接在該模式下編輯順序即可，注意系統(tǒng)提示默認(rèn)順序是top to bottom，也就是最后一行才是最近的提交，dd剪切一行然后P到需要的位置，:wq保存退出就可以了。

049 bisect

這題的bisect命令暫時(shí)不太明白，題目意思是不知道從哪個(gè)版本開始引入了一個(gè)bug，文件里面包含了測(cè)試代碼，找出引入bug的commit hash的前7位字符。
確認(rèn)范圍和測(cè)試：

$ git bisect master f608824888b83bbedc1f658be7496ffea467a8fb $ git bisect run make test

通過git bisect log查看對(duì)比的結(jié)果，可以看到哪些是bad，哪些是good，以及哪個(gè)commit是first bad commit。

答案：18ed2ac1，按照這個(gè)操作其他人有這個(gè)結(jié)果，我有一個(gè)make command not found的錯(cuò)誤，所以答案始終有問題。

050 stage_lines

對(duì)單個(gè)文件做了修改，涉及了兩個(gè)不同的特性，都沒有add到Stage區(qū)，想要只stage第一個(gè)特性的修改。選e進(jìn)入編輯模式后，刪掉不想stage的行，留下first feature那行，保存退出會(huì)自動(dòng)分期進(jìn)入stage區(qū)，git status可以看到一個(gè)feature.rb在stage區(qū)，一個(gè)在workspace，git diff可以查看兩個(gè)的差別。

-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只會(huì)影響指定的commit，但是reset會(huì)影響后續(xù)的commit。

053 restore

刪掉了最近一次commit，想要恢復(fù)，可以用reflog查看最近的操作記錄，找到要恢復(fù)的那次commit操作記錄，然后checkout。

054 conflict

將分支合并到master時(shí)有沖突，找到?jīng)_突文件修改后，文件在工作區(qū)，需要stage和commit。

055 submodule

以下為引用內(nèi)容：
開發(fā)過程中，經(jīng)常會(huì)有一些通用的部分希望抽取出來做成一個(gè)公共庫來提供給別的工程來使用，而公共代碼庫的版本管理是個(gè)麻煩的事情。今天無意中發(fā)現(xiàn)了git的git submodule命令，之前的問題迎刃而解了。
添加
為當(dāng)前工程添加submodule，命令如下：

git submodule add 倉庫地址 路徑

其中，倉庫地址是指子模塊倉庫地址，路徑指將子模塊放置在當(dāng)前工程下的路徑。
注意：路徑不能以 / 結(jié)尾（會(huì)造成修改不生效）、不能是現(xiàn)有工程已有的目錄（不能順利 Clone）.
命令執(zhí)行完成，會(huì)在當(dāng)前工程根路徑下生成一個(gè)名為“.gitmodules”的文件，其中記錄了子模塊的信息。添加完成以后，再將子模塊所在的文件夾添加到工程中即可。
刪除
submodule的刪除稍微麻煩點(diǎn)：首先，要在“.gitmodules”文件中刪除相應(yīng)配置信息。然后，執(zhí)行“git rm –cached ”命令將子模塊所在的文件從git中刪除。
下載的工程帶有submodule
當(dāng)使用git clone下來的工程中帶有submodule時(shí)，初始的時(shí)候，submodule的內(nèi)容并不會(huì)自動(dòng)下載下來的，此時(shí)，只需執(zhí)行如下命令：

git submodule update --init --recursive

即可將子模塊內(nèi)容下載下來后工程才不會(huì)缺少相應(yīng)的文件。

056 contribute

注意這關(guān)不是在測(cè)試你創(chuàng)建pull request的能力，而是真的邀請(qǐng)大家去github上為這個(gè)項(xiàng)目共享有用的代碼和文檔。

最后

通過這56關(guān)的練習(xí)，大致對(duì)git各方面的能力有了初步了解，日常解決一些問題應(yīng)該足夠了，從解決問題的過程中也發(fā)現(xiàn)了，官方文檔真的是一份很重要的資料，一定要學(xué)會(huì)閱讀官方文檔。git這么強(qiáng)大的功能也難怪《git權(quán)威指南》是一本那么厚的書。

所有關(guān)卡名字：

#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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。