最基本的git操作無非包括git add、git commit、git checkout、git pull、git push，但是除此之外工作中還會應用到很多其他的git操作，我這里列舉了一些最近工作中使用到的一些git功能，分享給大家！

1 git remote update

當你使用Git進行版本控制時，你可能會和其他人一起協作開發一個項目。在這種情況下，你需要與遠程倉庫保持同步，確保你能獲取到其他團隊成員所做的更改。每次開始創建分支或者計劃提交之前，最好使用git remote update來更新一下遠端的分支信息到本地，以防止未更新而基于舊的版本進行開發，避免完成工作之后merge沖突等問題。

2 git stash

git stash 是一個非常有用的命令，它幫助你在處理一些臨時的工作或者當你需要切換到另一個任務時，能夠暫時“隱藏”你當前的工作進度。想象一下，你正在寫一篇文章，突然接到一個緊急電話，需要立刻去處理別的事情。這時候，你不想丟失已經寫下的內容，但又不得不馬上離開。Git stash 就像是快速保存你的工作草稿，等你回來后可以繼續從你停下的地方開始。

創建一個stash：

當你有一些未提交的改動，并且想暫時把這些改動放到一邊，你可以使用 git stash save <message> 命令。這里的 <message> 是可選的，用來描述這次stash的內容。如果不加任何消息，默認也會創建一個stash。

 git stash save "暫時保存未完成的功能"

查看stash列表：

你可以使用 git stash list 查看所有已有的stash列表，每個stash都有一個編號和描述信息。

 git stash list

應用stash：

如果你想把某個stash應用回你的工作目錄，可以使用 git stash apply <stash>。如果你只寫了 git stash apply，默認會應用最近的一次stash。

 git stash apply

或者如果你想在應用的同時刪除stash（類似于“一次性使用”），可以使用 git stash pop。

 git stash pop

清理stash：

如果你不再需要某些stash了，可以使用 git stash drop <stash> 來刪除特定的stash。如果你想清除所有的stash，可以使用 git stash clear。

 git stash clear

3 .gitignore和.gitkeep

    當你在使用Git管理項目的時候，經常會遇到一些文件或目錄，你不希望它們被納入版本控制系統中。比如編譯生成的二進制文件、日志文件、臨時文件或者是包含敏感信息的配置文件等等。這些文件通常不需要被版本控制，因為它們要么是自動生成的，要么包含私密數據，不適合公開共享。

.gitignore 文件

.gitignore 文件就像是一個清單，告訴Git哪些文件和目錄不需要被跟蹤。它可以幫你過濾掉那些不需要提交到倉庫的文件，讓倉庫保持整潔，并保護隱私。

創建 .gitignore 文件

假設你在項目根目錄下創建一個名為 .gitignore 的文件，這個文件的名字前綴必須是一個點（.），表示這是一個隱藏文件。在這個文件里，每行寫一個模式，Git會根據這些模式來決定忽略哪些文件或目錄。

示例

假設你有一個Python項目，你可能不想將虛擬環境目錄和一些日志文件加入版本控制。你可以在項目的根目錄下創建一個 .gitignore 文件，并添加以下內容：

 # 忽略Python虛擬環境

 venv/

 # 忽略日志文件

 *.log

 # 忽略Thumbs.db文件（Windows系統）

 Thumbs.db

上面的.gitignore文件告訴Git忽略所有位于venv/目錄下的文件和子目錄，忽略所有擴展名為.log的文件，以及忽略名為Thumbs.db的文件。

使用 .gitignore 文件

當你創建了一個新的.gitignore文件或修改了現有的文件后，Git會自動應用新的規則。但是，如果某個已經被跟蹤的文件現在被加入了.gitignore文件，Git不會自動刪除該文件的歷史記錄。你可以選擇使用git rm --cached <file>命令來取消對文件的跟蹤，但保留文件在本地磁盤上。

.gitkeep 文件

有時候，你會有一些空的目錄需要被Git跟蹤，以便于保持項目結構清晰。但是Git默認不會跟蹤空目錄。為了告訴Git跟蹤這些空目錄，你可以在空目錄內創建一個名為.gitkeep的文件。

創建 .gitkeep 文件

創建一個空文件，命名為.gitkeep，然后把它放在你希望Git跟蹤的空目錄內。這個文件的作用就是讓Git知道這個目錄不是真的空，而是有意留空的。

示例

假設你有一個名為data的目錄，它目前是空的，但是你希望Git能夠跟蹤這個目錄的存在。你可以在data目錄內創建一個.gitkeep文件：

 mkdir data

 touch data/.gitkeep

這樣，Git就會把這個空的data目錄也納入版本控制，保證項目結構的完整性。

4 git patch

git patch 不是一個直接的Git命令，這里指的是使用Git來生成補丁文件（patch files），這些文件包含了對代碼庫的更改。補丁文件是一種文本文件，它們包含了文件差異（diffs），可以用來在另一個副本中重現這些更改。

什么是補丁文件？

補丁文件是一個文本文件，它記錄了兩個文件或兩個目錄之間的一系列差異。這些差異包括添加、刪除或修改的行。補丁文件可以應用于另一個相同或相似的文件或目錄，從而將這些差異應用上去，達到“修補”的效果。

Git生成補丁文件的方法

在Git中，你可以使用幾種不同的命令來生成補丁文件。最常用的是git diff 和 git format-patch 命令。

使用 git diff

git diff 命令可以顯示兩個版本之間的差異，這些差異可以被重定向到一個文件中，成為補丁文件。例如，如果你想要生成當前工作目錄與最后一次提交之間的差異作為補丁文件，你可以這樣做：

 git diff > mypatch.patch

這會生成一個名為 mypatch.patch 的文件，里面包含了當前工作目錄與最后一次提交之間的差異。

使用 git format-patch

git format-patch 命令則更加高級，它不僅可以生成補丁文件，還可以將補丁文件格式化為郵件格式，方便通過電子郵件發送給項目維護者或其他貢獻者。

生成單個補丁文件

如果你想要為當前分支上的最后一次提交生成一個補丁文件，可以使用如下命令：

 git format-patch HEAD~1

這將會在當前目錄下生成一個補丁文件，文件名通常是 0001-<commit_message>.patch 格式。

生成一系列補丁文件

如果你想要為一系列提交生成多個補丁文件，可以使用下面的命令：

 git format-patch <start-commit>..<end-commit>

例如，如果你想要為HEAD~5到HEAD之間的所有提交生成補丁文件，可以這樣寫：

 git format-patch HEAD~5..HEAD

這將在當前目錄下生成一系列按順序編號的補丁文件。

應用補丁文件

一旦你有了補丁文件，你可以使用 git apply 命令來應用這些補丁。例如，如果你有一個名為 mypatch.patch 的補丁文件，你可以這樣應用它：

 git apply mypatch.patch

5 git squash

git squash 是一種在Git中合并多個提交成一個單一提交的技術。想象一下，你在做一項復雜的任務時，可能會產生很多中間的提交，比如修復一個小bug、添加一些測試代碼、調整樣式等。這些提交雖然一步一步地推動了項目的進展，但它們單獨看起來可能顯得雜亂無章。使用git squash，你可以把這些相關的提交合并成一個干凈、簡潔的提交記錄，使得你的提交歷史更加清晰易讀。

為什么使用 git squash？

1. 整理提交歷史：有時候，你可能做了很多小的修改，這些修改最終構成了一個大的功能。通過git squash，你可以把這些修改合并成一個邏輯上完整的提交，使得其他人查看你的提交歷史時更加容易理解。

2. 保持歷史簡潔：當你在進行開發時，可能會有一些實驗性的提交或者一些臨時的調試代碼。這些提交并不需要保留在最終的提交歷史中，git squash 可以幫助你清理這些雜亂的部分。

3. 便于代碼審查：在團隊協作中，提交歷史的整潔程度直接影響到代碼審查的效率。通過git squash，你可以減少審查者的負擔，讓他們更容易集中注意力在重要的變更上。

如何使用 git squash

git本身沒有一個直接叫做git squash的命令，而是通過git rebase來實現git squash的效果。下面是一個簡單的步驟來演示如何使用git rebase來進行git squash：

1. 確保你在正確的分支上：首先，確保你處于你想要合并提交的那個分支上。

2.  git checkout my-feature-branch

3. 列出你想要合并的提交：使用git log或者git reflog查看你想要合并的提交。

4. 開始交互式重新基線（rebase）：使用git rebase -i命令進入交互式重新基線模式，這里HEAD~n表示你想要合并的提交之前的提交，n是你想要保留的第一個提交。

5.  git rebase -i HEAD~5

6. 這會打開一個文本編輯器（通常是vim），顯示一個列表，列出了你最近五次提交的SHA哈希值和提交信息。

7. 選擇要合并的提交：在編輯器中，你會看到每一行都以pick開頭，后面跟著一個提交的SHA哈希值和提交信息。對于你想要合并的提交，把pick改成squash或squash!，簡稱s。

8. 比如：

9.  pick 7a61e01 添加功能A

10.  pick 1b40f0d 修復功能A中的bug

11.  pick 3a9c5f2 調整功能A的樣式

12.  pick 4d65220 添加功能B

13. 改成：

14.  pick 7a61e01 添加功能A

15.  squash 1b40f0d 修復功能A中的bug

16.  squash 3a9c5f2 調整功能A的樣式

17.  pick 4d65220 添加功能B

18. 編輯合并后的提交信息：當Git看到你選擇了squash選項時，它會提示你編輯一個新的提交信息。這個信息將代表你合并后的所有提交。你可以在這里輸入一個新的提交信息，或者編輯合并的提交信息。

19.  # 編輯合并后的提交信息

20. 完成重新基線：保存并關閉編輯器后，Git會執行合并，并將你帶回到命令行。此時，你已經成功地將多個提交合并成了一個。

21. 推送更改：由于你改變了提交歷史，所以需要推送分支到遠程倉庫時需要加上--force參數。但是這通常是不建議的行為，git squash最好只用來處理本地分支，squash完畢之后再push到遠端。

22.  git push --force

    通過這樣的步驟，你可以將一系列的小提交合并成一個邏輯上連貫的大提交，使得你的Git提交歷史更加整潔有序。這對于保持良好的項目文檔和提高團隊協作效率是非常有幫助的。

6 git submodule status

git submodule status 是一個用于檢查Git子模塊狀態的命令。子模塊允許你在Git倉庫中嵌入另一個Git倉庫，就像在一個大項目中包含一個獨立的庫或組件一樣。子模塊可以有自己的提交歷史和版本控制，但它們被整合到主項目的版本控制流程中。使用git submodule status可以幫助你了解這些子模塊的當前狀態，確保它們與你期望的狀態一致。

什么是Git子模塊？

在開發過程中，你可能會用到一些外部庫或工具，這些庫或工具本身就是獨立的Git項目。例如，你可能在構建一個Web應用時，需要用到一個第三方的JavaScript庫。在這種情況下，你可以將這個庫作為一個子模塊添加到你的主項目中，這樣你的項目就包含了這個庫的所有源碼和歷史記錄。

為什么要使用 git submodule status？

當你在一個項目中有多個子模塊時，了解這些子模塊的狀態是非常重要的。這包括知道它們是否已經初始化，是否有未提交的更改，是否與遠程倉庫同步等。git submodule status 命令提供了這些信息，幫助你更好地管理子模塊。git倉庫中保存了主倉庫和子倉庫的對應關系，這些關系往往是非常重要的，不同倉庫的版本必須嚴格對應，使用git submodule status 命令可以快速得知當前主倉庫的提交對應哪些子倉庫的提交。

如何使用 git submodule status

使用git submodule status命令，你可以查看所有子模塊的狀態。命令非常簡單：

 git submodule status

執行這個命令后，你將看到一個列表，每個子模塊對應一行，每一行包含以下信息：

1. SHA-1 哈希值：這是子模塊當前指向的提交的哈希值。

2. 子模塊路徑：這是子模塊在你的項目中的位置。

3. 狀態標志

4. ：這一列會顯示子模塊的狀態。如果一切正常，通常會看到一個空格。如果有變化，則會顯示相應的狀態標志，例如：

• +：表示子模塊的本地版本比其記錄的版本超前。

• -：表示子模塊的本地版本落后于其記錄的版本。

• D：表示子模塊的本地版本與記錄的版本有分歧。

• A：表示子模塊已被添加但尚未初始化。

• I：表示子模塊已初始化。

• R：表示子模塊的URL已被更改。

示例

假設你有一個項目，其中包含了一個名為third-party-library的子模塊。你可以這樣查看它的狀態：

 $ git submodule status

 166d2f8b3e83893f9d150c19d6f02b279e490639 third-party-library (HEAD detached at v1.2.3) +

這表明子模塊third-party-library當前指向的提交是166d2f8b3e83893f9d150c19d6f02b279e490639，并且本地版本比記錄的版本超前（因為有+標志）。

7 git blame

git blame 是一個非常有用的命令，它幫助你追蹤某一行代碼是誰在什么時候修改的。想象一下，你正在閱讀一個復雜的代碼文件，突然發現了一個問題，可能是某個功能不再工作了，或者某個變量的值看起來不對勁。這時候，你可能會想知道：“這一行代碼是誰寫的？是什么時候改的？為什么這么改？” git blame 就是用來回答這些問題的。

什么是 git blame？

git blame 命令顯示了每一個文件行的最后修改者及其修改的時間戳和提交信息。這就像給每一行代碼打上了標簽，告訴你這行代碼是由誰在哪個提交中引入或修改的。

為什么使用 git blame？

1. 查找修改者：當你發現一個問題時，可以通過git blame找到最后修改那行代碼的人，從而更容易地定位問題的原因。

2. 了解歷史：通過查看某一行代碼的修改歷史，你可以了解為什么代碼被這樣編寫，這對理解代碼邏輯和意圖非常有幫助。

3. 代碼審查：在團隊協作中，git blame 可以幫助審查代碼的變更，確保代碼質量。

如何使用 git blame

使用git blame非常簡單，基本語法如下：

 git blame [options] <file>

• [options]：你可以添加一些選項來定制輸出，比如限制顯示的行數或顯示完整提交信息。

• <file>：這是你要查看的文件名。

基本用法

如果你想查看某個文件的每一行最后被誰修改，可以直接運行：

 git blame <file>

例如，如果你有一個名為app.js的文件，你可以這樣查看：

 git blame app.js

輸出結果會顯示每一行代碼對應的提交信息，包括提交者的姓名、日期和提交的摘要信息。

示例輸出

假設你運行了git blame app.js，輸出可能是這樣的：

 9e15a148 (Alice Smith 2024-01-01 10:30:00 +0800) 1: function greet() {

 9e15a148 (Alice Smith 2024-01-01 10:30:00 +0800) 2: console.log('Hello!');

 c6f3b47a (Bob Lee 2024-01-02 14:15:00 +0800) 3: // Added a comment for clarity.

 9e15a148 (Alice Smith 2024-01-01 10:30:00 +0800) 4: }

每一行的輸出包含以下信息：

• SHA-1哈希值（如9e15a148）：這是最后一次修改該行的提交的唯一標識符。

• 提交者的姓名（如Alice Smith）。

• 提交的日期和時間（如2024-01-01 10:30:00 +0800）。

• 提交信息摘要（如function greet()）。

• 行號（如1:）。

• 實際的代碼行內容。

更多選項

git blame 還支持許多選項來定制輸出，例如：

如果你想查看app.js文件第5行到第10行的修改歷史，可以這樣運行：

 1git blame -L 5,10 app.js

實際場景中的應用

假設你在開發一個Web應用，突然發現用戶登錄功能出現了問題。你不確定是什么時候引入的這個問題，也不知道是誰修改了這部分代碼。你可以使用git blame來追蹤：

1. 找到出現問題的文件，比如login.js。

2. 運行 git blame login.js 查看每一行的修改記錄。

3. 發現第15行的代碼有問題，然后看到這條記錄是由Bob在兩天前的提交中修改的。

4. 通過這種方式，你可以快速定位問題的來源，并聯系Bob詢問他當時的修改原因，從而更快地解決問題。

8 git status | grep ...

想象一下，在一個大型工程中，一次編譯會產生非常多的產物，這些產物可能都會影響到了倉庫狀態，而如果我們只想關注哪些源文件發生了變化，這個時候應該怎么辦呢？

我們可以通過git status + grep命令來解決這個問題。

 git status --short | grep '\.(c|h)$'

• git status --short：輸出一個簡潔的格式，每行包含一個狀態代碼和文件名。

• grep '\.(c|h)$'：篩選出以.c或.h結尾的文件。

結語

在日常的開發工作中，Git是我們不可或缺的好幫手，它幫助我們管理代碼的版本、協同工作并追蹤每一次的改動。從確保與遠程倉庫同步的git remote update，到臨時保存工作進度的git stash；從避免不必要的文件被納入版本控制的.gitignore和.gitkeep，到生成補丁文件以便審查和應用的git patch；從整理提交歷史、使代碼審查更加清晰的git squash，到管理子模塊狀態的git submodule status；再到追蹤代碼修改源頭的git blame，以及快速篩選特定文件改動的git status | grep組合——這些技巧都是Git強大功能的一部分。本文介紹了幾個在實際工作中非常實用的Git技巧，希望能讓你的開發體驗更加高效和順暢。

原文來源：https://mp.weixin.qq.com/s/VhmCENaL7BjhaL-MG01x1A