使用這12個Git的訣竅與技巧來令你的版本控制經驗更加有用。
Git，一個分散式版本控制系統，它已經成為了開源世界的原始碼控制預設工具，在4月7號12歲了。但是使用Git中更另人沮喪的是，你需要了解多少才能讓你更有效的使用它。同時這也是使用Git中比較美妙的一件事，因為沒有什麼比發現一個新的小技巧來簡化或提高你的工作流的效率更加令人快樂了。
為了紀念Git的12歲生日，這篇文章提供12個訣竅與技巧來讓你的Git經驗更加有用和強大，從一些你可能會忽視的基礎開始到一些真正的強大技巧!
-
你的 ~/.gitconfig 檔案
在第一次用git命令來提交一個倉庫的修改，你可能會首先看到像下面這種內容：
|
1 2 3 4 5 |
*** 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. 你的倉庫的.gitconfig檔案
在之前的技巧中，你可能會想知道在git config 命令中的—global標識是做什麼的。它告訴Git更新“global”配置，也就是~/.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別名，需要新增下面這段程式碼：
|
1 2 |
[alias] st = status |
（如果已經有了[alias]這個段落，只需要在這個段落中新增到第二行）
4. shell命令中的別名
別名不僅僅是執行其他Git子命令——你也可以定義別名，這些別名可以執行其他shell命令。這是一個很好的方法來處理一個重複的、罕見的、複雜的任務：一旦你已經想到第一次怎麼做，那就使用一個別名儲存這個命令。例如，我有幾個倉庫是我fork了一個開源專案，而且在本地做了一些修改，這些修改不用貢獻給這個專案。在專案的持續的開發的過程中我想保持最新的版本，同時保留我的本地修改。為了完成這個想法，我需要定期地從upstream倉庫中合併這些修改到我的fork——我定義一個別名“upstream-merge”來完成這個操作。定義如下：
|
1 |
upstream-merge = !"git fetch origin -v && git fetch upstream -v && git merge upstream/master && git push" |
別名定義開始的這個“!”是告訴Git來通過shell執行這個命令。這個例子包括了執行一些git命令，但是使用這種方式定義別名可以執行任何shell命令。
（注意：如果你想複製我的upstream-merge別名，你將需要確認你有一個Git remote命名為upstream來指定這個你fork的upstream倉庫。你可以通過“git remote add upstream <URL to repo>”來新增一個。）
5. 視覺化提交圖
如果你從事的是一個有很多分支活動的專案，有時可能很難掌握所有正在發生的工作以及它們之間的相關性。各種GUI工具可讓你弄清楚不同分支的概況以及在所謂的“提交圖”中提交記錄。例如，以下是我使用GitLab提交圖檢視器進行視覺化的一個儲存卡的部分截圖：
John Anderson, CC BY
如果你是專注於命令列的使用者，就可以不在多個工具之間切換導致分心，這個工具在命令列上實現了類似圖形介面的提交檢視。通過 –graph 引數獲取 git 的記錄：
John Anderson, CC BY
下面的命令可以得到一樣的倉庫視覺化片段：
|
1 |
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative |
–graph 選項將圖表新增到日誌的左側，–abbrev-commit 儲存提交使用了 SHA 方法， –date=relative 表示式用相對的術語來表示日期，並且 –pretty 以 bit 格式處理自定義格式。我知道 git lg 的別名，它是我最常執行的10個命令之一。
6. 更優雅的強制推送(force-push)
有時，就跟你儘量避免使用它一樣困難的是，你會發現你需要執行 git push –force 來覆寫你倉庫的遠端副本上的歷史記錄。你可能已得到了一些反饋，他們會要求你進行互動式的變基(rebase)，或者你可能已經搞砸了，並且希望隱藏證據。
當他人在倉庫的遠端副本的同一分支上進行改動後，會發生強制推送的風險。當你強制推送已重寫的歷史記錄時，某些提交將會丟失。這是 git push –force-with-lease 出現的原因 – 如果遠端分支已更新，它不會允許你執行強制推送，這將確保你不會丟棄他人的工作。
7. git add -N
你是否使用過git commit -a在一次行動中提交你所有未完成的修改，只有在你push完你的提交後才發現git commit -a忽略了新新增的檔案？解決這個問題你可以用git add -N（“通知”）來告訴Git你想把新新增的檔案包含在提交中在你第一次實際提交之前。
8. git add -p
一最佳的實踐為當使用Git時確保每個提交只包含一個邏輯更改–不管是修復一個bug還是（實現）一個新功能。然而，有時當你工作，會在你的倉庫中出現一個以上的修改提交。你怎麼樣把事情分開，使每個提交只包含適當的修改呢？git add –patch來解救！
這個標誌將會使git add命令檢視你工作副本中所有的變更，詢問你是否願意將它提交，跳過，或者推遲決定（還有其他一些更強大的選項，你可以通過在執行這命令後選擇？來檢視）。git add -p是一個神奇的工具來生產結構良好的提交。
9. git checkout -p
與 git add -p類似，git checkout命令將使用 –patch 或 -p 選項，這會使 git 在本地工作副本中展示每個“大塊”的改動，並允許丟棄對應改動 —— 簡單地說就是恢復本地工作副本到你改變之前的狀態。
某些場景下這非常有用，例如，在你跟蹤一個 bug 時引入了一堆除錯日誌語句，在修正了這個 bug 之後，你可以先使用 git checkout -p 刪除所有新加的除錯日誌，之後使用 git add -p 來新增 bug 修復。沒有比組合一個極好的、結構良好的提交更令人滿意的了！
10. Rebase with command execution
有些專案有一條規則，即儲存庫中的每個提交都必須處於可工作狀態 – 也就是說，在每次提交時，程式碼應該是可編譯的，或執行測試套件應該不會失敗的。當你在某分支上工作時間長時，但如果你最終因為某種原因需要rebase時，那麼跳過每個變基後的提交以確保你沒有意外引入一箇中斷是有些冗長乏味的。
幸運的是，git rebase已經支援了-x或–exec選項。git rebase -x <cmd>將在每次提交應用到rebase後執行該命令。因此，例如，如果你有一個專案，其中npm run tests會執行你的測試套件，那麼在rebase期間應用每次提交後，git rebase -x npm run tests將會執行測試套件。這使你可以檢視測試套件是否在任何變基後的提交中有失敗情況，因此你可以確保測試套件在每次提交時仍能通過。
11. 基於時間修改的指南
很多Git子命令都接受一個修正的引數來決定命令作用於倉庫的哪個部分，可能是某次特定的提交的 sha1 值，或者一個分支的名稱，又或者是一個符號性的名稱如 HEAD（代表當前檢出分支最後一次的提交），除了這些簡單的形式以外，你還可以附加一個指定的日期或時間作為引數，表示“這個時間的引用”。
這個功能在某些時候會變得十分有用，比如當你處理最新出現的 bug，自言自語道：“這個功能明明昨天還是好好的，到底又改了些什麼”，不用盯著滿屏的 git 日誌的輸出試圖弄清楚什麼時候更改了提交，您只需執行 git diff HEAD@{yesterday}，會看到從昨天以來的所有修改，這也適用於較長的時間段（例如 git diff HEAD@{‘2 months ago’}） ，以及一個確切的日期（例如git diff HEAD@{‘2010-01-01 12:00:00’}）。
您還可以將這些基於日期的修改引數與使用修正引數的任何 Git 子命令一起使用。在 gitrevisions 手冊頁中有關於具體使用哪種格式的詳細資訊。
12. 全知的 reflog
你是不是試過在 rebase 時幹掉過某次提交，後來又發現你需要保留這次提交的一些東西？你可能覺得這些提交的東西已經永遠找不回來了，只能從頭再來了。其實不然，但如果你在本地工作副本中提交了，提交就會進入到 “引用日誌” ，你仍然可以訪問到。
執行 git reflog 將在本地工作副本中顯示當前分支的所有活動的列表，併為您提供每個提交的 SHA1 值。一旦發現你 rebase 時放棄的那個提交，你可以執行 git checkout 來檢出該次提交，複製好你需要的資訊，然後再執行 git checkout HEAD 返回到分支最新的提交去。
以上就是全部內容
希望這些技巧中至少有一個能教你一些關於 Git 的新知識，Git 已經 12 歲了，在這個持續創新，不斷新增新特性的專案裡，你最喜歡哪個技巧？