## 配置 Git 你在?[起步](http://git-scm.com/book/zh/v2/1-introduction/_getting_started)?中看到，可以用?`git config`?配置 Git。 首先要做的事情就是設置你的名字和郵件地址： ~~~ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ~~~ 現在，你會了解到許多更有趣的選項，并用類似的方式來定制 Git。 首先，快速回憶下：Git 使用一系列配置文件來保存你自定義的行為。 它首先會查找`/etc/gitconfig`?文件，該文件含有系統里每位用戶及他們所擁有的倉庫的配置值。 如果你傳遞`--system`?選項給?`git config`，它就會讀寫該文件。 接下來 Git 會查找每個用戶的?`~/.gitconfig`?文件（或者?`~/.config/git/config`?文件）。 你可以傳遞?`--global`?選項讓 Git 讀寫該文件。 最后 Git 會查找你正在操作的版本庫所對應的 Git 目錄下的配置文件（`.git/config`）。 這個文件中的值只對該版本庫有效。 以上三個層次中每層的配置（系統、全局、本地）都會覆蓋掉上一層次的配置，所以?`.git/config`中的值會覆蓋掉?`/etc/gitconfig`?中所對應的值。 > ###### NOTE > Git 的配置文件是純文本的，所以你可以直接手動編輯這些配置文件，輸入合乎語法的值。 但是運行?`git config`?命令會更簡單些。 ## 客戶端基本配置 Git 能夠識別的配置項分為兩大類：客戶端和服務器端。 其中大部分屬于客戶端配置 —— 可以依你個人的工作偏好進行配置。 盡管 Git 支持的選項?*繁多*，但其中大部分僅僅在某些罕見的情況下有意義。 我們只講述最平常和最有用的選項。 如果想得到你當前版本的 Git 支持的選項列表，請運行 ~~~ $ man git-config ~~~ 這個命令列出了所有可用的選項，以及與之相關的介紹。 你也可以在?[*http://git-scm.com/docs/git-config.html*](http://git-scm.com/docs/git-config.html)?找到同樣的內容。 #### `core.editor` 默認情況下，Git 會調用環境變量（`$VISUAL`?或?`$EDITOR`）設置的任意文本編輯器，如果沒有設置，會調用?`vi`?來創建和編輯你的提交以及標簽信息。 你可以使用?`core.editor`?選項來修改默認的編輯器： ~~~ $ git config --global core.editor emacs ~~~ 現在，無論你定義了什么終端編輯器，Git 都會調用 Emacs 編輯信息。 #### `commit.template` 如果把此項指定為你的系統上某個文件的路徑，當你提交的時候， Git 會使用該文件的內容作為提交的默認信息。 例如：假設你創建了一個叫?`~/.gitmessage.txt`?的模板文件，類似這樣： ~~~ subject line what happened [ticket: X] ~~~ 要想讓 Git 把它作為運行?`git commit`?時顯示在你的編輯器中的默認信息， 如下設置`commit.template`： ~~~ $ git config --global commit.template ~/.gitmessage.txt $ git commit ~~~ 然后當你提交時，編輯器中就會顯示如下的提交信息占位符： ~~~ subject line what happened [ticket: X] # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: lib/test.rb # ~ ~ ".git/COMMIT_EDITMSG" 14L, 297C ~~~ 如果你的團隊對提交信息有格式要求，可以在系統上創建一個文件，并配置 Git 把它作為默認的模板，這樣可以更加容易地使提交信息遵循格式。 #### `core.pager` 該配置項指定 Git 運行諸如?`log`?和?`diff`?等命令所使用的分頁器。 你可以把它設置成用?`more`或者任何你喜歡的分頁器（默認用的是?`less`），當然也可以設置成空字符串，關閉該選項： ~~~ $ git config --global core.pager '' ~~~ 這樣不管命令的輸出量多少，Git 都會在一頁顯示所有內容。 #### `user.signingkey` 如果你要創建經簽署的含附注的標簽（正如?[簽署工作](http://git-scm.com/book/zh/v2/1-git-tools/_signing)?所述），那么把你的 GPG 簽署密鑰設置為配置項會更好。 如下設置你的密鑰 ID： ~~~ $ git config --global user.signingkey <gpg-key-id> ~~~ 現在，你每次運行?`git tag`?命令時，即可直接簽署標簽，而無需定義密鑰： ~~~ $ git tag -s <tag-name> ~~~ #### `core.excludesfile` 正如?[忽略文件](http://git-scm.com/book/zh/v2/1-git-basics/_ignoring)?所述，你可以在你的項目的?`.gitignore`?文件里面規定無需納入 Git 管理的文件的模板，這樣它們既不會出現在未跟蹤列表，也不會在你運行?`git add`?后被暫存。 不過有些時候，你想要在你所有的版本庫中忽略掉某一類文件。 如果你的操作系統是 OS X，很可能就是指?`.DS_Store`。 如果你把 Emacs 或 Vim 作為首選的編輯器，你肯定知道以?`~`?結尾的臨時文件。 這個配置允許你設置類似于全局生效的?`.gitignore`?文件。 如果你按照下面的內容創建一個`~/.gitignore_global`?文件： ~~~ *~ .DS_Store ~~~ ……然后運行?`git config --global core.excludesfile ~/.gitignore_global`，Git 將把那些文件永遠地拒之門外。 #### `help.autocorrect` 假如你打錯了一條命令，會顯示： ~~~ $ git chekcout master git：'chekcout' 不是一個 git 命令。參見 'git --help'。 您指的是這個么？ checkout ~~~ Git 會嘗試猜測你的意圖，但是它不會越俎代庖。 如果你把?`help.autocorrect`?設置成 1，那么只要有一個命令被模糊匹配到了，Git 會自動運行該命令。 ~~~ $ git chekcout master 警告：您運行一個不存在的 Git 命令 'chekcout'。繼續執行假定您要要運行的 是 'checkout' 在 0.1 秒鐘后自動運行... ~~~ 注意提示信息中的“0.1 秒”。`help.autocorrect`?接受一個代表十分之一秒的整數。 所以如果你把它設置為 50, Git 將在自動執行命令前給你 5 秒的時間改變主意。 ## Git 中的著色 Git 充分支持對終端內容著色，對你憑肉眼簡單、快速分析命令輸出有很大幫助。 你可以設置許多的相關選項來滿足自己的偏好。 #### `color.ui` Git 會自動著色大部分輸出內容，但如果你不喜歡花花綠綠，也可以關掉。 要想關掉 Git 的終端顏色輸出，試一下這個： ~~~ $ git config --global color.ui false ~~~ 這個設置的默認值是?`auto`，它會著色直接輸出到終端的內容；而當內容被重定向到一個管道或文件時，則忽略著色功能。 你也可以設置成?`always`，來忽略掉管道和終端的不同，即在任何情況下著色輸出。 你很少會這么設置，在大多數場合下，如果你想在被重定向的輸出中插入顏色碼，可以傳遞?`--color`?標志給 Git 命令來強制它這么做。 默認設置就已經能滿足大多數情況下的需求了。 #### `color.*` 要想具體到哪些命令輸出需要被著色以及怎樣著色，你需要用到和具體命令有關的顏色配置選項。 它們都能被置為?`true`、`false`?或?`always`： ~~~ color.branch color.diff color.interactive color.status ~~~ 另外，以上每個配置項都有子選項，它們可以被用來覆蓋其父設置，以達到為輸出的各個部分著色的目的。 例如，為了讓?`diff`?的輸出信息以藍色前景、黑色背景和粗體顯示，你可以運行 ~~~ $ git config --global color.diff.meta "blue black bold" ~~~ 你能設置的顏色有：`normal`、`black`、`red`、`green`、`yellow`、`blue`、`magenta`、`cyan`或?`white`。 正如以上例子設置的粗體屬性，想要設置字體屬性的話，可以選擇包括：`bold`、`dim`、`ul`（下劃線）、`blink`、`reverse`（交換前景色和背景色）。 ## 外部的合并與比較工具 雖然 Git 自己內置了一個?`diff`?實現，而且到目前為止我們一直在使用它，但你能夠用一個外部的工具替代它。 除此以外，你還能設置一個圖形化的工具來合并和解決沖突，從而不必自己手動解決。 這里我們以一個不錯且免費的工具 —— Perforce 圖形化合并工具（P4Merge） —— 來展示如何用一個外部的工具來合并和解決沖突。 P4Merge 可以在所有主流平臺上運行，所以安裝上應該沒有什么困難。 在這個例子中，我們使用的路徑名可以直接應用在 Mac 和 Linux 上；在 Windows 上，`/usr/local/bin`?需要被改為你的環境中可執行文件所在的目錄路徑。 首先， 從?[*http://www.perforce.com/downloads/Perforce/*](http://www.perforce.com/downloads/Perforce/)?下載 P4Merge。 接下來，你要編寫一個全局包裝腳本來運行你的命令。 我們會使用 Mac 上的路徑來指定該腳本的位置，在其他系統上，它將是?`p4merge`?二進制文件所在的目錄。 創建一個名為?`extMerge`?的腳本包裝 merge 命令，讓它把參數轉發給 p4merge 二進制文件： ~~~ $ cat /usr/local/bin/extMerge #!/bin/sh /Applications/p4merge.app/Contents/MacOS/p4merge $* ~~~ 包裝 diff 命令的腳本首先確保傳遞了七個參數過來，隨后把其中兩個轉發給包裝了 merge 的腳本。 默認情況下， Git 傳遞以下參數給?`diff`： ~~~ path old-file old-hex old-mode new-file new-hex new-mode ~~~ 由于你僅僅需要?`old-file`?和?`new-file`?參數，由包裝 diff 的腳本來轉發它們吧。 ~~~ $ cat /usr/local/bin/extDiff #!/bin/sh [ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5" ~~~ 你也需要確保這些腳本具有可執行權限： ~~~ $ sudo chmod +x /usr/local/bin/extMerge $ sudo chmod +x /usr/local/bin/extDiff ~~~ 現在你可以修改配置文件來使用你自定義的合并和比較工具了。 這將涉及許多自定義設置：`merge.tool`?通知 Git 該使用哪個合并工具，?`mergetool.<tool>.cmd`?規定命令運行的方式，`mergetool.<tool>.trustExitCode`?會通知 Git 程序的返回值是否表示合并操作成功，`diff.external`?通知 Git 該用什么命令做比較。 因此，你可以運行以下四條配置命令： ~~~ $ git config --global merge.tool extMerge $ git config --global mergetool.extMerge.cmd \ 'extMerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"' $ git config --global mergetool.extMerge.trustExitCode false $ git config --global diff.external extDiff ~~~ 或編輯你的?`~/.gitconfig`?文件，添加以下各行： ~~~ [merge] tool = extMerge [mergetool "extMerge"] cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED" trustExitCode = false [diff] external = extDiff ~~~ 待一切設置妥當后，如果你像這樣運行 diff 命令： ~~~ $ git diff 32d1776b1^ 32d1776b1 ~~~ Git 將啟動 P4Merge，而不是在命令行輸出比較的結果，就像這樣：  Figure 8-1.?P4Merge. 如果你嘗試合并兩個分支，隨后遇到了合并沖突，運行?`git mergetool`，Git 會調用 P4Merge 讓你通過圖形界面來解決沖突。 設置包裝腳本的好處在于大大降低了改變 diff 和 merge 工具的工作量。 舉個例子，想把`extDiff`?和?`extMerge`?的工具改成 KDiff3，你要做的僅僅是編輯?`extMerge`?腳本文件： ~~~ $ cat /usr/local/bin/extMerge #!/bin/sh /Applications/kdiff3.app/Contents/MacOS/kdiff3 $* ~~~ 現在，Git 將使用 KDiff3 作為查看比較和解決合并沖突的工具。 Git 預設了許多其他的合并和解決沖突的工具，無需特別的設置你就能用上它們。 要想看到它支持的工具列表，試一下這個： ~~~ $ git mergetool --tool-help 'git mergetool --tool=<tool>' may be set to one of the following: emerge gvimdiff gvimdiff2 opendiff p4merge vimdiff vimdiff2 The following tools are valid, but not currently available: araxis bc3 codecompare deltawalker diffmerge diffuse ecmerge kdiff3 meld tkdiff tortoisemerge xxdiff Some of the tools listed above only work in a windowed environment. If run in a terminal-only session, they will fail. ~~~ 如果你不想用到 KDiff3 的所有功能，只是想用它來合并，那么 kdiff3 正符合你的要求，運行： ~~~ $ git config --global merge.tool kdiff3 ~~~ 如果運行了以上命令，而沒有設置?`extMerge`?和?`extDiff`?文件，Git 會用 KDiff3 做合并，讓內置的?`diff`?來做比較。 ## 格式化與多余的空白字符 格式化與多余的空白字符是許多開發人員在協作時，特別是在跨平臺情況下，不時會遇到的令人頭疼的瑣碎的問題。 由于編輯器的不同或者文件行尾的換行符在 Windows 下被替換了，一些細微的空格變化會不經意地混入提交的補丁或其它協作成果中。 不用怕，Git 提供了一些配置項來幫助你解決這些問題。 #### `core.autocrlf` 假如你正在 Windows 上寫程序，而你的同伴用的是其他系統（或相反），你可能會遇到 CRLF 問題。 這是因為 Windows 使用回車（CR）和換行（LF）兩個字符來結束一行，而 Mac 和 Linux 只使用換行（LF）一個字符。 雖然這是小問題，但它會極大地擾亂跨平臺協作。許多 Windows 上的編輯器會悄悄把行尾的換行字符轉換成回車和換行，或在用戶按下 Enter 鍵時，插入回車和換行兩個字符。 Git 可以在你提交時自動地把回車和換行轉換成換行，而在檢出代碼時把換行轉換成回車和換行。 你可以用?`core.autocrlf`?來打開此項功能。 如果是在 Windows 系統上，把它設置成?`true`，這樣在檢出代碼時，換行會被轉換成回車和換行： ~~~ $ git config --global core.autocrlf true ~~~ 如果使用以換行作為行結束符的 Linux 或 Mac，你不需要 Git 在檢出文件時進行自動的轉換；然而當一個以回車加換行作為行結束符的文件不小心被引入時，你肯定想讓 Git 修正。 你可以把`core.autocrlf`?設置成 input 來告訴 Git 在提交時把回車和換行轉換成換行，檢出時不轉換： ~~~ $ git config --global core.autocrlf input ~~~ 這樣在 Windows 上的檢出文件中會保留回車和換行，而在 Mac 和 Linux 上，以及版本庫中會保留換行。 如果你是 Windows 程序員，且正在開發僅運行在 Windows 上的項目，可以設置?`false`?取消此功能，把回車保留在版本庫中： ~~~ $ git config --global core.autocrlf false ~~~ #### `core.whitespace` Git 預先設置了一些選項來探測和修正多余空白字符問題。 它提供了六種處理多余空白字符的主要選項 —— 其中三個默認開啟，另外三個默認關閉，不過你可以自由地設置它們。 默認被打開的三個選項是：`blank-at-eol`，查找行尾的空格；`blank-at-eof`，盯住文件底部的空行；`space-before-tab`，警惕行頭 tab 前面的空格。 默認被關閉的三個選項是：`indent-with-non-tab`，揪出以空格而非 tab 開頭的行（你可以用`tabwidth`?選項控制它）；`tab-in-indent`，監視在行頭表示縮進的 tab；`cr-at-eol`，告訴 Git 忽略行尾的回車。 通過設置?`core.whitespace`，你可以讓 Git 按照你的意圖來打開或關閉以逗號分割的選項。 要想關閉某個選項，你可以在輸入設置選項時不指定它或在它前面加個?`-`。 例如，如果你想要打開除`cr-at-eol`?之外的所有選項： ~~~ $ git config --global core.whitespace \ trailing-space,space-before-tab,indent-with-non-tab ~~~ 當你運行?`git diff`?命令并嘗試給輸出著色時，Git 將探測到這些問題，因此你在提交前就能修復它們。 用?`git apply`?打補丁時你也會從中受益。 如果正準備應用的補丁存有特定的空白問題，你可以讓 Git 在應用補丁時發出警告： ~~~ $ git apply --whitespace=warn <patch> ~~~ 或者讓 Git 在打上補丁前自動修正此問題： ~~~ $ git apply --whitespace=fix <patch> ~~~ 這些選項也能運用于?`git rebase`。 如果提交了有空白問題的文件，但還沒推送到上游，你可以運行?`git rebase --whitespace=fix`?來讓 Git 在重寫補丁時自動修正它們。 ## 服務器端配置 Git 服務器端的配置項相對來說并不多，但仍有一些饒有生趣的選項值得你一看。 #### `receive.fsckObjects` Git 能夠確認每個對象的有效性以及 SHA-1 檢驗和是否保持一致。 但 Git 不會在每次推送時都這么做。這個操作很耗時間，很有可能會拖慢提交的過程，特別是當庫或推送的文件很大的情況下。 如果想在每次推送時都要求 Git 檢查一致性，設置?`receive.fsckObjects`?為 true 來強迫它這么做： ~~~ $ git config --system receive.fsckObjects true ~~~ 現在 Git 會在每次推送生效前檢查庫的完整性，確保沒有被有問題的客戶端引入破壞性數據。 #### `receive.denyNonFastForwards` 如果你變基已經被推送的提交，繼而再推送，又或者推送一個提交到遠程分支，而這個遠程分支當前指向的提交不在該提交的歷史中，這樣的推送會被拒絕。 這通常是個很好的策略，但有時在變基的過程中，你確信自己需要更新遠程分支，可以在 push 命令后加?`-f`?標志來強制更新（force-update）。 要禁用這樣的強制更新推送（force-pushes），可以設置?`receive.denyNonFastForwards`： ~~~ $ git config --system receive.denyNonFastForwards true ~~~ 稍后我們會提到，用服務器端的接收鉤子也能達到同樣的目的。 那種方法可以做到更細致的控制，例如禁止某一類用戶做非快進（non-fast-forwards）推送。 #### `receive.denyDeletes` 有一些方法可以繞過?`denyNonFastForwards`?策略。其中一種是先刪除某個分支，再連同新的引用一起推送回該分支。 把?`receive.denyDeletes`?設置為 true 可以把這個漏洞補上： ~~~ $ git config --system receive.denyDeletes true ~~~ 這樣會禁止通過推送刪除分支和標簽 — 沒有用戶可以這么做。 要刪除遠程分支，必須從服務器手動刪除引用文件。 通過用戶訪問控制列表（ACL）也能夠在用戶級的粒度上實現同樣的功能，你將在?[使用強制策略的一個例子](http://git-scm.com/book/zh/v2/ch00/_an_example_git_enforced_policy)?一節學到具體的做法。