1、 你的 ~/.gitconfig 文件

當你第一次嘗試使用 git 命令向倉庫提交一個更改時，你可能會收到這樣的歡迎信息：

*** Please tell me who you are.
Run
 git config --global user.email "you@example.com" git config --global user.name "Your Name"to set your account's default identity.

你可能沒有意識到正是這些命令在修改 ~/.gitconfig 的內容，這是 Git 存儲全局配置選項的地方。你可以通過 ~/.gitconfig 文件來做大量的事，包括定義別名、永久性打開（或關閉）特定命令選項，以及修改 Git 工作方式（例如，git diff 使用哪個 diff 算法，或者默認使用什么類型的合并策略）。你甚至可以根據倉庫的路徑有條件地包含其他配置文件！所有細節請參閱 man git-config。

2、 你倉庫中的 .git/config 文件

在之前的技巧中，你可能想知道 git config 命令中 –global 標志是干什么的。它告訴 Git 更新~/.gitconfig 中的“全局”配置。當然，有全局配置也意味著會有本地配置，顯然，如果你省略 –global標志，git config 將改為更新倉庫特有的配置，該配置存儲在 .git/config 中。

在 .git/config 文件中設置的選項將覆蓋 ~/.gitconfig 文件中的所有設置。因此，例如，如果你需要為特定倉庫使用不同的電子郵件地址，則可以運行 git config user.email “also_you@example.com“。然后，該倉庫中的任何提交都將使用你單獨配置的電子郵件地址。如果你在開源項目中工作，而且希望它們顯示自己的電子郵件地址，同時仍然使用自己工作郵箱作為主 Git 配置，這非常有用。

幾乎任何你可以在 ~/.gitconfig 中設置的東西，你也可以在 .git/config 中進行設置，以使其作用于特定的倉庫。在下面的技巧中，當我提到將某些內容添加到 ~/.gitconfig 時，只需記住你也可以在特定倉庫的.git/config 中添加來設置那個選項。

3、 別名

別名是你可以在 ~/.gitconfig 中做的另一件事。它的工作原理就像命令行中的 shell —— 它們設定一個新的命令名稱，可以調用一個或多個其他命令，通常使用一組特定的選項或標志。它們對于那些你經常使用的又長又復雜的命令來說非常有效。

你可以使用 git config 命令來定義別名 —— 例如，運行 git config –global –add alias.st status 將使運行 git st 與運行 git status 做同樣的事情 —— 但是我在定義別名時發現，直接編輯 ~/.gitconfig文件通常更容易。

如果你選擇使用這種方法，你會發現 ~/.gitconfig 文件是一個 INI 文件。INI 是一種帶有特定段落的鍵值對文件格式。當添加一個別名時，你將改變 [alias] 段落。例如，定義上面相同的 git st 別名時，添加如下到文件：

[alias]
st = status

（如果已經有 [alias] 段落，只需將第二行添加到現有部分。）

4、 shell 命令中的別名

別名不僅僅限于運行其他 Git 子命令 —— 你還可以定義運行其他 shell 命令的別名。這是一個用來處理一個反復發生的、罕見和復雜的任務的很好方式：一旦你確定了如何完成它，就可以在別名下保存該命令。例如，我有一些復刻fork的開源項目的倉庫，并進行了一些本地修改。我想跟上項目正在進行的開發工作，并保存我本地的變化。為了實現這個目標，我需要定期將來自上游倉庫的更改合并到我復刻的項目中 —— 我通過使用我稱之為upstream-merge 的別名來完成。它是這樣定義的：

upstream-merge = !"git fetch origin -v && git fetch upstream -v && git merge upstream/master && git push"

別名定義開頭的 ! 告訴 Git 通過 shell 運行這個命令。這個例子涉及到運行一些 git 命令，但是以這種方式定義的別名可以運行任何 shell 命令。

（注意，如果你想復制我的 upstream-merge 別名，你需要確保你有一個名為 upstream 的 Git 遠程倉庫，指向你已經分配的上游倉庫，你可以通過運行 git remote add upstream 來添加一個。）

5、 可視化提交圖

如果你在一個有很多分支活動的項目上開發，有時可能很難掌握所有正在發生的工作以及它們之間的相關性。各種圖形用戶界面工具可讓你獲取不同分支的圖片并在所謂的“提交圖表”中提交。例如，以下是我使用 GitLab提交圖表查看器可視化的我的一個倉庫的一部分：

GitLab commit graph viewer

如果你是一個專注于命令行的用戶或者發現分支切換工具讓人分心，那么可以從命令行獲得類似的提交視圖。這就是 git log 命令的 –graph 參數出現的地方：

Repository visualized with –graph command

以下命令可視化相同倉庫可達到相同效果：

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit --date=relative

–graph 選項將圖添加到日志的左側，–abbrev-commit 縮短提交的 SHA 值，–date=relative 以相對方式表示日期，以及 –pretty 來處理所有其他自定義格式。我有個 git lg 別名用于這個功能，它是我最常用的 10 個命令之一。

6、 更優雅的強制推送

有時，你越是想避開越避不開，你會發現你需要運行 git push –force 來覆蓋倉庫遠程副本上的歷史記錄。你可能得到了一些反饋，需要你進行交互式變基rebase，或者你可能已經搞砸了，并希望隱藏“罪證”。

當其他人在倉庫的遠程副本的同一分支上進行更改時，會發生強制推送的危險。當你強制推送已重寫的歷史記錄時，這些提交將會丟失。這就是 git push –force-with-lease 出現的原因 — 如果遠程分支已經更新，它不會允許你強制推送，這確保你不會丟掉別人的工作。

7、 git add -N

你是否使用過 git commit -a 在一次行動中提交所有未完成的修改，但在你推送完提交后才發現 git commit -a 忽略了新添加的文件？你可以使用 git add -N (想想 “notify”) 來解決這個問題，告訴 Git 在第一次實際提交它們之前，你希望在提交中包含新增文件。

8、 git add -p

使用 Git 時的最佳做法是確保每次提交都只包含一個邏輯修改 —— 無論這是修復錯誤還是添加新功能。然而，有時當你在工作時，你的倉庫中的修改最終應該使用多個提交。你怎樣才能設法把事情分開，使每個提交只包含適當的修改呢？git add –patch 來拯救你了！

這個標志會讓 git add 命令查看你工作副本中的所有變化，并為每個變化詢問你是否想要將它提交、跳過，或者推遲決定（你可以在運行該命令后選擇 ? 來查看其他更強大的選項）。git add -p 是生成結構良好的提交的絕佳工具。

9、 git checkout -p

與 git add -p 類似，git checkout 命令也接受 –patch 或 -p 選項，這會使其在本地工作副本中顯示每個“大塊”的改動，并允許丟棄它 —— 簡單來說就是將本地工作副本恢復到更改之前的狀態。

這真的很棒。例如，當你追蹤一個 bug 時引入了一堆調試日志語句，修正了這個 bug 之后，你可以先使用 git checkout -p 移除所有新的調試日志，然后 git add -p 來添加 bug 修復。沒有比組合一個優雅的、結構良好的提交更令人滿意！

10、 變基時執行命令

有些項目有一個規則，即存儲庫中的每個提交都必須處于可工作狀態 —— 也就是說，在每次提交時，應該可以編譯該代碼，或者應該運行測試套件而不會失敗。 當你在分支上工作時，這并不困難，但是如果你最終因為某種原因需要變基rebase時，那么需要逐步完成每個變基的提交以確保你沒有意外地引入一個中斷，而這個過程是乏味的。

幸運的是，git rebase 已經覆蓋了 -x 或 –exec 選項。git rebase -x 將在每個提交在變基中被應用后運行該命令。因此，舉個例子，如果你有一個項目，其中使用 npm run tests 運行你的測試套件，git rebase -x npm run tests 將在變基期間每次提交之后運行測試套件。這使你可以查看測試套件是否在任何變基的提交中失敗，以便你可以確認測試套件在每次提交時仍能通過。

11、 基于時間的修訂引用

很多 Git 子命令都接受一個修訂參數來決定命令作用于倉庫的哪個部分，可以是某次特定的提交的 SHA1 值，一個分支的名稱，甚至是一個符號性的名稱如 HEAD（代表當前檢出分支最后一次的提交），除了這些簡單的形式以外，你還可以附加一個指定的日期或時間作為參數，表示“這個時間的引用”。

這個功能在某些時候會變得十分有用。當你處理最新出現的 bug，自言自語道：“這個功能昨天還是好好的，到底又改了些什么”，不用盯著滿屏的 git log 的輸出試圖弄清楚什么時候更改了提交，你只需運行 git diff HEAD@{yesterday}，看看從昨天以來的所有修改。這也適用于更長的時間段（例如 git diff HEAD@{‘2 months ago’}），以及一個確切的日期（例如 git diff HEAD@{‘2010-01-01 12:00:00’}）。

你也可以將這些基于日期的修訂參數與使用修訂參數的任何 Git 子命令一起使用。在 gitrevisions 手冊頁中有關于具體使用哪種格式的詳細信息。

12、 全知的 reflog

你是不是試過在變基時干掉過某次提交，然后發現你需要保留那個提交中一些東西？你可能覺得這些信息已經永遠找不回來了，只能重新創建。但是如果你在本地工作副本中提交了，提交就會被添加到引用日志（reflog）中 ，你仍然可以訪問到。

運行 git reflog 將在本地工作副本中顯示當前分支的所有活動的列表，并為你提供每個提交的 SHA1 值。一旦發現你變基時放棄的那個提交，你可以運行 git checkout 跳轉到該提交，復制任何你需要的信息，然后再運行 git checkout HEAD 返回到分支最近的提交去。

13、 自己清理

哎呦！ 事實證明，我的基本數學技能不如我的 Git 技能。 Git 最初是在 2005 年發布的，這意味著它今年會變成 13 歲，而不是 12 歲（LCTT 譯注：本文原來是以 12 歲生日為題的）。為了彌補這個錯誤，這里有可以讓我們變成十三歲的第 13 條技巧。

如果你使用基于分支的工作流，隨著在一個長期項目上的工作，除非你在每個分支合并時清理干凈，否則你最終會得到一大堆分支。這使得你難于找到想要的分支，分支的森林會讓你無從找起。甚至更糟糕的是，如果你有大量活躍的分支，確定一個分支是否被合并（可以被安全刪除）或仍然沒有被合并而應該留下會非常繁瑣。幸運的是，Git 可以幫到你：只需要運行 git branch –merged 就可以得到已經被合并到你的當前分支的分支列表，或者 git branch –no-merged 找出被合并到其它分支的分支。默認情況下這會列出你本地工作副本的分支，但是如果你在命令行包括 –remote 或 -r 參數，它也會列出僅存于遠程倉庫的已合并分支。

重要提示：如果你計劃使用 git branch –merged 的輸出來清理那些已合并的分支，你要小心它的輸出也包括了當前分支（畢竟，這個當前的分支就被合并到當前分支！）。確保你在任何銷毀動作之前排除了該分支（如果你忘記了，參見第 12 條技巧來學習 reflog 怎樣幫你把分支找回來，希望有用……）。