Git系列的前幾篇文章針對(duì)基礎(chǔ)知識(shí)進(jìn)行了詳細(xì)講解，但是Git還包含很多其他命令，就不每個(gè)都展開細(xì)講了，本篇文章整理了一些2.0+版本的常用Git命令，以供備忘。

1. 創(chuàng)建版本庫

1.1 git clone <url> <本地路徑>
克隆遠(yuǎn)程版本庫到本地所指定的路徑中，包括代碼，分支和版本的提交記錄等；
若后面不加本地路徑，則默認(rèn)克隆到當(dāng)前目錄中，且倉庫所在目錄名為遠(yuǎn)程倉庫的名稱；
可以參考Git系列講解（一）：代碼托管平臺(tái)GitCode及本地Git環(huán)境搭建 的使用。

其它用法：

• git clone -n <url> <本地路徑>
  不做檢出操作，也就是只克隆.git，后續(xù)想檢出代碼時(shí)直接使用git checkout HEAD即可。

• git clone --branch <branch / tag> --depth=<num> <url>
  (1) 參數(shù)解釋：
  –branch 指定了要克隆的分支或標(biāo)簽。
  –depth=<num> 代表只克隆最近num筆提交，要注意真實(shí)情況下，克隆下來的提交可能會(huì)比num多，這里解釋比較麻煩，直接看下面例子，指定tag為v237，指定depth為2，但是卻克隆下來3筆提交，因?yàn)閚um所指的次數(shù)為v237所在分支(紅色分支線)上的提交，所以此時(shí)要被合并的綠色分支上的提交是不計(jì)入num中的。
  
  
  (2) 恢復(fù)完整的提交記錄
  由于指定了–depth，所以提交記錄不完整。如果想要恢復(fù)完整的提交記錄，此時(shí)只需要使用命令git pull --unshallow即可。
  (3) 恢復(fù)所有的分支
  指定了–depth之后，只會(huì)clone默認(rèn)分支。如果想要所有的遠(yuǎn)程分支，則可以將remote.origin.fetch里的默認(rèn)分支(master)改為星號(hào)(*)。
  
  有兩種方法修改remote.origin.fetch，一是使用 git config 命令 git config remote.origin.fetch “+refs/heads/*:refs/remotes/origin/*”。二是修改.git/config文件中的remote.origin.fetch。
  (4) 總結(jié)
  有時(shí)候項(xiàng)目很大，若想完整的clone整個(gè)項(xiàng)目確實(shí)要花費(fèi)不少時(shí)間，在比較著急的時(shí)候我們可以使用–branch或–depth參數(shù)只clone我們想要的那個(gè)分支或者某(些)筆提交，這樣可以極大的縮短clone項(xiàng)目花費(fèi)的時(shí)間。如果后期想要恢復(fù)所有提交和所有分支，則可以參看上面(2)(3)提到的方法。

1.2 git init <倉庫名稱>
初始化一個(gè)git倉庫，執(zhí)行完后目錄下會(huì)出現(xiàn) .git 目錄，并且默認(rèn)當(dāng)前為master分支。

其它用法：

• git init --bare <倉庫名稱> 初始化一個(gè)git的bare(裸)倉庫
  (1) 看下圖，git裸倉庫bareproject.git目錄結(jié)構(gòu)和上面的git倉庫里邊的.git目錄結(jié)構(gòu)是一樣的，就相當(dāng)于普通git倉庫的.git目錄，而沒有工作區(qū)，所以git相關(guān)的操作(git add/push/commit等)都是無效的。bare倉庫的意義在于作為git的中心倉庫而使用在服務(wù)器上，存儲(chǔ)各個(gè)客戶端所提交的版本信息等。
  
  (2) 創(chuàng)建bare倉庫時(shí)，名稱一般以.git結(jié)尾，這樣就解釋了從gitcode等代碼托管平臺(tái)進(jìn)行g(shù)it clone的項(xiàng)目為什么都是.git結(jié)尾。
  

2. 修改和提交

2.1 git status
查看文件在工作區(qū)和暫存區(qū)的狀態(tài)，包含修改，刪除，增加的文件及未跟蹤的文件

2.2 git diff
查看工作區(qū)中已經(jīng)跟蹤的文件對(duì)比暫存區(qū)記錄的變更內(nèi)容，也就是文件執(zhí)行g(shù)it add后，git diff就沒有輸出了

其它用法：

• git diff <file> 查看具體某個(gè)文件的變更內(nèi)容

2.3 git add .
將工作區(qū)所有文件的變動(dòng)記錄添加到暫存區(qū)（包含文件更新，刪除，新建等記錄，與git 1.0+版本的git add -A相同）

其它用法：

• git add <file> 將工作區(qū)某文件變動(dòng)記錄添加到暫存區(qū)
• git add -u 只添加已經(jīng)跟蹤的文件變更記錄到暫存區(qū)

2.4 git rm <file>
刪除工作區(qū)某文件，并將刪除記錄添加到暫存區(qū)，等同于rm <file> + git add <file>

其它用法：

• git rm <file> --cached
  在暫存區(qū)中添加文件的刪除記錄，工作區(qū)文件不變。然后再進(jìn)行git commit這樣的操作，這個(gè)文件就會(huì)從本地版本庫或者是遠(yuǎn)程版本庫中刪除。這個(gè)命令的應(yīng)用場(chǎng)景一般是發(fā)現(xiàn)某文件有問題，想從版本庫中刪除，但是后續(xù)還需要在此文件基礎(chǔ)上修改，所以不直接刪除本地工作區(qū)中此文件。

2.5 git mv <old name> <new name>
更改工作區(qū)某文件的名字，并將更改記錄添加到暫存區(qū)。

2.6 git commit
提交所有暫存區(qū)記錄的文件(更新，新建，刪除)到版本庫。執(zhí)行此命令后會(huì)自動(dòng)打開.git目錄下的COMMIT_EDITMSG文件(默認(rèn)使用nano編輯器)，編輯提交信息后，保存退出，本次提交即可完成。

其它用法：

• git commit -m “提交信息” ：與git commit相比，不會(huì)自動(dòng)打開提交記錄文件
• git commit --amend ：是對(duì)上一次提交的補(bǔ)充，新的提交信息及commit id會(huì)覆蓋上一次提交的
• git commit -am “提交信息” ：相當(dāng)于git add與git commit -m的結(jié)合

3. 查看提交歷史

3.1 git log
這一部分內(nèi)容在Git系列講解（四）：提交記錄之git log與git blame的使用 進(jìn)行了詳細(xì)講解，這里就大概整理一下。

其它用法：

• git log --pretty=
• git log --oneline
• git log --stat
• git log -p
• git show commitID
• git show --stat commitID
• git log --date=
• git blame <file>
• git blame -L <開始行數(shù)>,<結(jié)束行數(shù)> <file>

3.2 git reflog
reflog 可以顯示本地倉庫變更動(dòng)作的歷史記錄，比如切換分支，倉庫回退，倉庫提交 ( 包括amend的提交 ) 等，下面介紹兩個(gè)使用場(chǎng)景。

案例一：回退amend的提交
有的時(shí)候使用git commit --amend提交代碼后，突然想使用git reset <commitId>回退到上一筆提交，但是我們知道git log中amend提交記錄會(huì)覆蓋上一筆提交，沒有辦法拿到上一筆提交的commitId，這時(shí)候可以使用git reflog來查詢上一筆提交的commitId，從而進(jìn)行回退提交。

案例二：恢復(fù)刪除的分支

此時(shí)如果想恢復(fù)刪除的dev分支，則可以使用下面命令。

git branch dev dbe6784

4. 撤銷

4.1 git reset <commit>
(1) 主要作用就是重置HEAD指針到某筆提交，默認(rèn)效果等于下面的git reset --mixed <commit>
(2) 這里的<commit>也可以是HEAD指針，如git reset HEAD，代表reset到HEAD所指向的那筆提交（即最新的一筆提交）
(3) 注意未跟蹤的文件(沒有進(jìn)行g(shù)it add的文件)不會(huì)受影響，這一點(diǎn)適用下面所有選項(xiàng)。

其它用法：

• git reset --soft <commit>
  工作區(qū)和暫存區(qū)不變，重置版本庫到某筆提交
• git reset --mixed <commit>
  工作區(qū)不變，重置暫存區(qū)及版本庫到某筆提交
• git reset --hard <commit>
  重置工作區(qū)，暫存區(qū)，未進(jìn)行commit的內(nèi)容都會(huì)被清除。
• git reset --merge <commit>
  分兩種情況講解此選項(xiàng)：
  (1) 工作區(qū)中未改動(dòng)的文件和已經(jīng)加入到暫存區(qū)的改動(dòng)文件，這部分的處理就和–hard一樣，這些文件在工作區(qū)，暫存區(qū)和版本庫中全部重置；
  (2) 還未加入暫存區(qū)的改動(dòng)文件，這部分的處理就和–mixed一樣，這些文件在工作區(qū)中不會(huì)被重置，改動(dòng)依然保留。而這部分文件有兩種情況下無法正常進(jìn)行reset操作而導(dǎo)致終止，如下圖所示：
  
  第一種情況：重置的那筆提交中不包含此文件
  
  第二種情況：重置的那筆提交中包括此文件，但是那筆提交并不是最新對(duì)此文件進(jìn)行修改的提交。
  
• git reset --keep <commit>
  這個(gè)和–merge選項(xiàng)類似，不同點(diǎn)在于即使是添加到暫存區(qū)的文件，也會(huì)受兩種異常情況的影響。

4.2 git checkout
此命令除了有切換分支的功能，還有檢出文件的作用，以此達(dá)到撤銷的目的。
注意未跟蹤或者已跟蹤未提交過的文件不受影響。

其它用法：

• git checkout HEAD .
  對(duì)比工作區(qū)，暫存區(qū)與版本庫中的不同，從本地版本庫中(當(dāng)前分支)檢出當(dāng)前目錄下的所有文件，覆蓋到工作區(qū)與暫存區(qū)。
• git checkout .
  與git checkout HEAD .的區(qū)別就是，只對(duì)比暫存區(qū)和工作區(qū)的不同，所以說已經(jīng)執(zhí)行過git add的文件，用此命令不會(huì)進(jìn)行檢出操作，如果想檢出已經(jīng)git add的文件，可以使用git checkout HEAD .
• git checkout HEAD <file>
  對(duì)比工作區(qū)，暫存區(qū)與版本庫中的不同，從本地版本庫中(當(dāng)前分支)檢出某個(gè)文件，覆蓋到工作區(qū)與暫存區(qū)。
• git checkout <file>
  與git checkout HEAD <file>的區(qū)別就是，只對(duì)比暫存區(qū)和工作區(qū)的不同，所以說已經(jīng)執(zhí)行過git add的文件，用此命令不會(huì)進(jìn)行檢出操作，如果想檢出已經(jīng)git add的文件，可以使用git checkout HEAD <file>

4.3 git revert <commit>
不同于git reset <commit>，git revert會(huì)生成一個(gè)新commit，這個(gè)commit的作用是撤消一個(gè)已存在提交的所有修改。head指向新生成的這個(gè)commit，本質(zhì)上是撤銷或者倒轉(zhuǎn)。

其它用法：

• git revert -n <commit>
  加上-n選項(xiàng)代表not commit，所以如果加上-n，則需要在git revert后再手動(dòng)執(zhí)行g(shù)it commit。

5. 分支與標(biāo)簽

5.1 git branch
顯示本地所有分支

其它用法：

• git branch -a
  顯示本地和遠(yuǎn)程所有分支名稱，一般與-v或者-vv一起使用。
• git branch -v
  顯示本地分支名稱，提交的簡寫哈希值以及提交注釋。如果是-vv，則可以進(jìn)一步顯示本地分支對(duì)應(yīng)的遠(yuǎn)程分支名。
• git branch -r
  顯示所有的遠(yuǎn)程分支名
• git branch <new branch name>
  創(chuàng)建一個(gè)新的本地分支
• git branch -d <branch name>
  刪除一個(gè)本地分支，沒有合并的分支不能刪除
• git branch -D <branch name>
  強(qiáng)制刪除一個(gè)本地分支，小心使用

5.2 git tag
列出所有本地標(biāo)簽

其它用法：

• git tag <tag name>
  基于最新提交創(chuàng)建標(biāo)簽
• git tag -a <tag name> <commit id>
  基于某筆提交創(chuàng)建標(biāo)簽
• git tag -d <tag name>
  刪除本地標(biāo)簽

5.3 git checkout <branch / tag>
切換到指定分支或標(biāo)簽，注意直接使用git checkout <tag>會(huì)出現(xiàn)頭指針分離的狀態(tài)，一般情況沒有這么使用的。

其它用法：

• git checkout -b <new branch>
  創(chuàng)建分支并切換到此分支
• git checkout -b <new branch> <old branch>
  基于已有的branch，創(chuàng)建新分支并切換到此分支
• git checkout -b <new branch> <tag>
  以tag那筆提交為最新提交，創(chuàng)建一個(gè)新分支并切換到此分支。如下面例子所示：
  

6. 合并與變基

6.1 git merge <branch>
合并指定分支到當(dāng)前分支

6.2 git rebase <branch>
變基操作。如下圖所示，例如當(dāng)前是處于work分支，執(zhí)行git rebase master，首先找到兩個(gè)分支共同的父分支C2，然后截取work分支上C2以后的分支（即W3），改變W3的基底分支為master分支上最新的分支，這個(gè)改變的過程中會(huì)有merge的過程而形成W3’。

這里有必要講一下變基的意義，個(gè)人認(rèn)為變基操作和合并操作雖然都有將兩條分支合并到一起的能力，但是變基可以形成一個(gè)非常清晰的提交歷史，分支圖上不會(huì)分叉。具體可以看另一篇文章Git系列講解（三）：同一分支下多人協(xié)同開發(fā)。

雖然變基有著這樣的優(yōu)點(diǎn)，但是它卻有一個(gè)致命的缺點(diǎn)，就是無法在分支圖上體現(xiàn)出它是何時(shí)進(jìn)行合并的，而git merge卻可以體現(xiàn)出來，加上git rebase操作確實(shí)有一些復(fù)雜，導(dǎo)致企業(yè)一般情況很少使用它。雖然分支圖會(huì)比較亂出現(xiàn)很多自動(dòng)合并的提交信息，但是一般情況無傷大雅。最后到底要不要使用git rebase，請(qǐng)各位結(jié)合實(shí)際情況進(jìn)行考慮。

6.3 git cherry-pick <commit>
cherry-pick顧名思義，就是摘取某個(gè)提交然后掛在當(dāng)前的分支上。對(duì)比merge和rebase來講，其優(yōu)勢(shì)在于靈活性高，想用哪個(gè)提交的內(nèi)容，直接cherry-pick過來就行。

其它用法：

• git cherry-pick <commit 1>…<commit n>
  cherry-pick支持范圍摘取，注意左側(cè)的commit時(shí)間早于右側(cè)的commit時(shí)間，而且選取的范圍是左開右閉的，所以想把最左側(cè)的commit也成功取到，則需要這么寫git cherry-pick <commit 1>^…<commit n>

• git cherry-pick -e
  可以編輯提交過程中信息

• git cherry-pick -n
  不自動(dòng)進(jìn)行commit操作，只是將內(nèi)容更新到工作區(qū)和暫存區(qū)，后續(xù)可以手動(dòng)使用git commit將變更提交到版本庫中。

• git cherry-pick -x
  在commit的信息后面自動(dòng)添加一行“(cherry picked from commit xxx)”，強(qiáng)調(diào)這條commit是cherry-pick過來的。

• git cherry-pick -s
  在commit的信息后面自動(dòng)添加一行“(Signed-off-by: xxx)”，強(qiáng)調(diào)這條commit是誰cherry-pick過來的。

• git cherry-pick -m <num>
  有些提交是由兩個(gè)分支合并而來的，那么這個(gè)提交就會(huì)有兩個(gè)parent。而cherry-pick其實(shí)是使用目標(biāo)提交與父提交的差異補(bǔ)丁進(jìn)行工作的，那么在cherry-pick這樣的合并提交時(shí)，如果不指定用哪個(gè)parent與目標(biāo)提交做差異補(bǔ)丁，那么cherry-pick就會(huì)失敗。而-m選項(xiàng)可以指定使用哪個(gè)parent做差異補(bǔ)丁，兩個(gè)parent分別用1號(hào)和2號(hào)代表，其中1號(hào)parent代表當(dāng)前分支上的提交，2號(hào)parent代表合入過來的分支上的提交，所以這個(gè)數(shù)值一般指定為1。

7. 遠(yuǎn)程操作

7.1 git remote -v
查看遠(yuǎn)程版本庫信息（包含遠(yuǎn)程版本庫名稱和倉庫地址）

其它用法：

• git remote show <remote>
  查看指定遠(yuǎn)程版本庫信息，例如git remote show origin

• git remote add <remote> <url>
  添加遠(yuǎn)程倉庫。這條命令適用于新建的工程，可以使用這條命令添加一個(gè)遠(yuǎn)程倉庫的名稱和url地址，再通過git push <remote> <branch>命令將倉庫信息一并提交到服務(wù)器，這樣遠(yuǎn)程服務(wù)器那邊就創(chuàng)建好了此倉庫和分支。

7.2 git fetch <remote> <branch>
獲取遠(yuǎn)程倉庫更新信息，并將信息更新到本地的遠(yuǎn)程倉庫副本。git fetch使用后，可以根據(jù)實(shí)際情況確定是否進(jìn)行與本地倉庫進(jìn)行merge。

7.3 git pull <remote> <branch>
拉取遠(yuǎn)程分支代碼并合并到本地，相當(dāng)于git fetch + git merge

7.4 git push <remote> <branch>
在使用git commit向本地倉庫提交之后，使用此命令向遠(yuǎn)程倉庫推送本地倉庫的提交信息(代碼，索引，提交記錄等)。當(dāng)然這條命令也可以推送本地新創(chuàng)建的遠(yuǎn)程分支，遠(yuǎn)程倉庫等。關(guān)于如何本地創(chuàng)建遠(yuǎn)程分支和遠(yuǎn)程倉庫，請(qǐng)看前面的內(nèi)容。

其它用法：

• git push <remote> :<branch / tag>
  刪除遠(yuǎn)程倉庫的某個(gè)分支或者標(biāo)簽

7.5 git push --tags
上傳本地所有標(biāo)簽

8. 緩存修改（git stash）

先講述兩個(gè)場(chǎng)景：
?
場(chǎng)景一： 正在dev分支下在開發(fā)某個(gè)功能，突然來了一個(gè)bug需要解決，這個(gè)時(shí)候如果切換到bugfix分支進(jìn)行修改bug，那dev分支下的修改就沒有了，但是現(xiàn)在的代碼沒寫完，所以我還不想提交。怎么辦？
?
場(chǎng)景二： 代碼寫的正高興呢，突然發(fā)現(xiàn)寫錯(cuò)分支了，寫在了bugfix分支，怎么將代碼修改更改到dev分支下？
?
上面兩個(gè)場(chǎng)景都是在不適合提交的基礎(chǔ)上，但是又想將現(xiàn)在的更改保留，有沒有不用備份文件的方法？不用擔(dān)心，git給我們提供了git stash緩存機(jī)制。

git stash
將工作區(qū)的修改內(nèi)容（注意是git所管理的文件，即之前已經(jīng)git add過的）添加到緩存中。執(zhí)行完成后，緩存中會(huì)多出一條記錄，并清除當(dāng)前工作區(qū)修改內(nèi)容。每執(zhí)行一次git stash，緩存中都會(huì)多出一條記錄，這個(gè)緩存類似數(shù)據(jù)結(jié)構(gòu)的棧，保持后進(jìn)先出的原則，這個(gè)我們下面講git stash pop的時(shí)候會(huì)明白。

git stash save “注釋”
和git stash一樣，不過多了一個(gè)注釋記錄，方便后期查看理解

git stash list
查看緩存列表

git stash pop
執(zhí)行這條命令，會(huì)將緩存中最后(最新)一條修改覆蓋到工作區(qū)文件，并且這條緩存也會(huì)在緩存中清除。上面我們說緩存類似于棧，這條命令就能體現(xiàn)出來。

git stash apply stash@{index}
如果想將緩存中的某條記錄覆蓋到工作區(qū)，可以使用這條命令，并且執(zhí)行后，也不會(huì)自動(dòng)清除該條緩存。例如git stash apply stash@{1}

git stash show stash@{index}
查看當(dāng)前工作區(qū)文件和某條緩存的差異，不過只能顯示差異的數(shù)量，不能顯示具體差異內(nèi)容。

git stash drop stash@{index}
丟棄/清除某條緩存，清除該條緩存后，后面的緩存index會(huì)自動(dòng)減一。

git stash clear
清除所有緩存

所以，上面兩個(gè)場(chǎng)景的問題也就解決了。
?
場(chǎng)景一： 在切換bugfix分支之前，先將工作區(qū)的修改使用git stash緩存，然后切換到bugfix修改好問題后，再切換回dev分支將緩存覆蓋到工作區(qū)繼續(xù)開發(fā)工作
?
場(chǎng)景二： 發(fā)現(xiàn)沒有在正確的分支進(jìn)行編寫代碼，只需要將當(dāng)前工作區(qū)修改緩存，然后切換到正確分支，再進(jìn)行g(shù)it stash pop或者git stash apply stash@{index}即可。

9. 工作樹（git worktree）

上面講的git緩存機(jī)制的確是好用，不過對(duì)某些場(chǎng)景下卻不適用。
?
場(chǎng)景一： 比如我在A分支上改完一個(gè)問題進(jìn)行編譯，恰好編譯時(shí)間要很久，那我這期間就只能等著編譯完才能進(jìn)行別的分支開發(fā)任務(wù)。
?
場(chǎng)景二： 比如想使用Beyond Compare軟件進(jìn)行兩個(gè)分支代碼對(duì)比，但是軟件只能是對(duì)兩個(gè)目錄的文件做對(duì)比。
?
有人提出對(duì)這套代碼在本地克隆多個(gè)代碼倉庫即可解決，但是問題是多個(gè)代碼倉庫之間不能直接進(jìn)行代碼修改共享，在A倉修改的代碼需要提交到服務(wù)器，然后B倉再通過git pull等命令拉取服務(wù)器內(nèi)容，才能得到A倉的修改內(nèi)容，不免有些麻煩。
?
所以針對(duì)這種情況，git提供了工作樹的機(jī)制，即創(chuàng)建一個(gè)新的工作區(qū)(目錄)，這些創(chuàng)建出的工作區(qū)使用的都是同一個(gè)本地版本庫，在創(chuàng)建工作區(qū)的時(shí)候，要指定一個(gè)分支進(jìn)行管理（也可以創(chuàng)建新分支）。

9.1 git worktree add <工作樹路徑> -b <new branch> <old branch>
基于原有分支創(chuàng)建一個(gè)新分支，并基于新分支創(chuàng)建一個(gè)工作樹。
Tips：新分支建議起名字加一個(gè)temp前綴，強(qiáng)調(diào)此分支是臨時(shí)的。

其它用法：

• git worktree add <工作樹路徑>
  以工作樹目錄名稱創(chuàng)建一個(gè)新分支，而此新分支是基于當(dāng)前分支（或當(dāng)前頭指針位置）創(chuàng)建。
  注：包含子模塊的工作樹在創(chuàng)建后，新生成的工作樹目錄子模塊為空，需要重新同步子模塊。

• git worktree add <工作樹路徑> -b <new branch>
  指定新分支名創(chuàng)建工作樹，新分支基于當(dāng)前分支（或當(dāng)前頭指針位置）創(chuàng)建。

• git worktree add <工作樹路徑> <old branch>
  這條命令會(huì)直接使用原有的分支進(jìn)行創(chuàng)建新工作樹。

9.2 git worktree list
列出所有的工作樹，包括工作樹路徑及其對(duì)應(yīng)的commit的哈希值和分支名稱(或頭指針狀態(tài))

9.3 git worktree remove <工作樹路徑>
刪除某個(gè)工作樹目錄（包含子模塊的工作樹無法刪除），但是其對(duì)應(yīng)的分支不會(huì)被刪除，可以后續(xù)手動(dòng)刪除。

其它用法：

• git worktree remove <工作樹路徑> --force
  和上面的差不多，只不過是即使包含子模塊的工作樹目錄也可以刪除。

9.4 git worktree move <工作樹路徑> <新工作樹路徑>
將某個(gè)工作樹目錄移動(dòng)到另一個(gè)位置（或改名），包含子模塊的工作樹無法執(zhí)行此操作。

9.5 git worktree lock <工作樹路徑>
給某個(gè)工作樹上鎖，上鎖后不能對(duì)此工作樹進(jìn)行git worktree move，git worktree remove，git worktree prune等操作。

9.6 git worktree unlock <工作樹路徑>
解鎖某個(gè)工作樹

9.7 git worktree prune
有時(shí)候沒有通過git worktree remove進(jìn)行刪除工作樹，而是使用rm等命令直接刪除了工作樹目錄，這樣在.git/worktrees目錄下還會(huì)存在此工作樹信息，使用prune命令可以清除這部分無用信息。

10. 搜索字符串

基本命令：
git grep <字符串>

命令介紹：
和grep一樣，都是用來搜索字符串的，不過既然是git命令，那要被搜索的文件必須是git倉庫內(nèi)的文件。
※只搜索已添加到暫存區(qū)或已經(jīng)提交過的文件，未添加到暫存區(qū)的文件不會(huì)被git grep搜索。

常用選項(xiàng)：

• -i： 忽略大小寫。
• -w：全詞匹配。
• -n：輸出結(jié)果中打印行號(hào)。
• -e： 當(dāng)需要指定多個(gè)pattern時(shí)，使用該選項(xiàng)，每個(gè)-e后面接一個(gè)pattern。
  ??不指定邏輯運(yùn)算符選項(xiàng)( --and, --or, --not )時(shí)，默認(rèn)這些pattern是或( --or )的關(guān)系。
• –and, --or, --not：邏輯運(yùn)算符選項(xiàng)，–and的優(yōu)先級(jí)高于–or。
  ????????這里建議混有–and和–or運(yùn)算的地方使用小括號(hào)進(jìn)行分割，從而明確劃分算式優(yōu)先級(jí)。
• --all-match：與-e結(jié)合使用時(shí)，只輸出滿足-e所有條件的文件，參考下面例子理解。
• --：選項(xiàng)結(jié)束的標(biāo)志，一般后接搜索路徑。

10.1 git grep -e <pattern> --and -e <pattern>
可以看到這里使用了小括號(hào)來聲明了運(yùn)算優(yōu)先級(jí)，括號(hào)內(nèi)的先運(yùn)算，所以最后的結(jié)果就是匹配 #define LOG_TAG 或 #define LOG_NDEBUG

10.2 git grep -e <pattern> -e <pattern>（ git grep -E ‘<pattern>|<pattern>’ ）
上面介紹參數(shù)的時(shí)候說了，在不指定邏輯運(yùn)算選項(xiàng)時(shí)，默認(rèn)-e之間的參數(shù)為或的關(guān)系。所以最后結(jié)果就是匹配 LOG_TAG 或 LOG_NDEBUG。
git grep -e <pattern> -e <pattern> 等同于 git grep -E ‘<pattern>|<pattern>’

10.3 git grep --all-match -e <pattern> -e <pattern>
該例子得到的結(jié)果與10.2例子相比，可以看出來少了Bitmap.cpp等文件，這是因?yàn)橹付?--all-match 選項(xiàng)后，只有同時(shí)滿足所有篩選條件的文件才會(huì)被輸出。很明顯，少的Bitmap.cpp等文件只有 LOG_TAG 而沒有 LOG_NDEBUG。

10.4 git grep <pattern> -- <pathspec>
--選項(xiàng)上面已經(jīng)介紹過了，這個(gè)沒什么好說的，需要注意的是<pathspec>這個(gè)選項(xiàng)。

(1) pathspec可以是要被搜索文件名的后綴。

git grep -w startPreview -- '*.cpp' '*.h'

(2) pathspec可以是要搜索的路徑。

git grep -w startPreview -- 'services/camera/libcameraservice/api1'

(3) pathspec可以是要排除的搜索路徑。

git grep -w startPreview -- :^'services/camera/libcameraservice/api1'

文章來源地址http://www.zghlxwxcb.cn/news/detail-764310.html

到了這里，關(guān)于Git系列講解（五）：Git常用命令整理的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！