git使用小技巧有哪些

1、 你的 ~/.gitconfig 文件

當(dāng)你第一次嘗試使用 git 命令向倉庫提交一個(gè)更改時(shí)，你可能會(huì)收到這樣的歡迎信息：

*** 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.

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

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

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

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

幾乎任何你可以在 ~/.gitconfig 中設(shè)置的東西，你也可以在 .git/config 中進(jìn)行設(shè)置，以使其作用于特定的倉庫。在下面的技巧中，當(dāng)我提到將某些內(nèi)容添加到 ~/.gitconfig 時(shí)，只需記住你也可以在特定倉庫的.git/config 中添加來設(shè)置那個(gè)選項(xiàng)。

3、 別名

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

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

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

[alias]
st = status

（如果已經(jīng)有 [alias] 段落，只需將第二行添加到現(xiàn)有部分。）

4、 shell 命令中的別名

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

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

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

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

5、 可視化提交圖

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

GitLab commit graph viewer

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

Repository visualized with –graph command

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

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

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

6、 更優(yōu)雅的強(qiáng)制推送

有時(shí)，你越是想避開越避不開，你會(huì)發(fā)現(xiàn)你需要運(yùn)行 git push –force 來覆蓋倉庫遠(yuǎn)程副本上的歷史記錄。你可能得到了一些反饋，需要你進(jìn)行交互式變基rebase，或者你可能已經(jīng)搞砸了，并希望隱藏“罪證”。

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

7、 git add -N

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

8、 git add -p

使用 Git 時(shí)的最佳做法是確保每次提交都只包含一個(gè)邏輯修改 —— 無論這是修復(fù)錯(cuò)誤還是添加新功能。然而，有時(shí)當(dāng)你在工作時(shí)，你的倉庫中的修改最終應(yīng)該使用多個(gè)提交。你怎樣才能設(shè)法把事情分開，使每個(gè)提交只包含適當(dāng)?shù)男薷哪兀縢it add –patch 來拯救你了！

這個(gè)標(biāo)志會(huì)讓 git add 命令查看你工作副本中的所有變化，并為每個(gè)變化詢問你是否想要將它提交、跳過，或者推遲決定（你可以在運(yùn)行該命令后選擇 ? 來查看其他更強(qiáng)大的選項(xiàng)）。git add -p 是生成結(jié)構(gòu)良好的提交的絕佳工具。

9、 git checkout -p

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

這真的很棒。例如，當(dāng)你追蹤一個(gè) bug 時(shí)引入了一堆調(diào)試日志語句，修正了這個(gè) bug 之后，你可以先使用 git checkout -p 移除所有新的調(diào)試日志，然后 git add -p 來添加 bug 修復(fù)。沒有比組合一個(gè)優(yōu)雅的、結(jié)構(gòu)良好的提交更令人滿意！

10、 變基時(shí)執(zhí)行命令

有些項(xiàng)目有一個(gè)規(guī)則，即存儲(chǔ)庫中的每個(gè)提交都必須處于可工作狀態(tài) —— 也就是說，在每次提交時(shí)，應(yīng)該可以編譯該代碼，或者應(yīng)該運(yùn)行測試套件而不會(huì)失敗。 當(dāng)你在分支上工作時(shí)，這并不困難，但是如果你最終因?yàn)槟撤N原因需要變基rebase時(shí)，那么需要逐步完成每個(gè)變基的提交以確保你沒有意外地引入一個(gè)中斷，而這個(gè)過程是乏味的。

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

11、 基于時(shí)間的修訂引用

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

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

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

12、 全知的 reflog

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

運(yùn)行 git reflog 將在本地工作副本中顯示當(dāng)前分支的所有活動(dòng)的列表，并為你提供每個(gè)提交的 SHA1 值。一旦發(fā)現(xiàn)你變基時(shí)放棄的那個(gè)提交，你可以運(yùn)行 git checkout 跳轉(zhuǎn)到該提交，復(fù)制任何你需要的信息，然后再運(yùn)行 git checkout HEAD 返回到分支最近的提交去。

13、 自己清理

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

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

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