2019年4月14日 星期日

gitbook8.1翻譯未整理版

8.1 自訂 Git-Git 配置

到目前為止, 我們已經介紹了 Git 如何工作以及如何使用它的基礎知識, 並介紹了 Git 提供的許多工具, 以説明您輕鬆高效地使用它。在本章中, 我們將通過引入幾個重要的配置設置和掛鉤系統, 瞭解如何使 Git 以更自訂的方式運行。有了這些工具, 很容易讓 Git 按照你、你的公司或你的團隊需要的方式工作。

Git Configuration

正如您在"開始" 中簡要看到的, 您可以使用git config命令指定 git 配置設置。您首先要做的事情之一是設置您的姓名和電子郵件地址:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
現在, 您將瞭解一些更有趣的選項, 您可以以這種方式設置這些選項, 以自訂 Git 使用方式。
首先, 快速查看: Git 使用一系列設定檔來確定您可能需要的非預設行為。Git 查找這些值的第一個位置是在/etc/gitconfig檔中, 該檔包含系統及其所有存儲庫中每個使用者的值。如果您傳遞的選項--system git config, 它將專門從這個檔讀取和寫入。
Git 看起來的下一個地方是~/.gitconfig (或~/.config/git/config) 檔, 該檔特定于每個使用者。您可以通過--global選項來使 git 讀取和寫入此檔。
最後, Git 在您當前使用的任何存儲庫的 Git 目錄 (.git/config) 的設定檔中查找配置值。這些值特定于該單個存儲庫。
這些 "級別" (系統、全域、本地) 中的每個都覆蓋上一個級別中的值, 因此.git/config中的值勝過/etc/gitconfig的值。
手寫
Git 的設定檔是純文字的, 因此您還可以通過手動編輯檔並插入正確的語法來設置這些值。不過, 運行git config命令通常更容易。

基本用戶端配置

Git 識別的配置選項分為兩類: 用戶端和伺服器端。大多數選項都是用戶端配置您的個人工作首選項。支援許多配置選項, 但其中很大一部分僅在某些邊緣情況下有用。我們將只涵蓋這裡最常見和最有用的。如果您想查看 Git 版本識別的所有選項的清單, 您可以運行
$ man git-config
此命令列出了所有可用的選項相當詳細。您還可以在HTTP://git-scm.com/docs/git-config.html找到此參考材料.

core.editor

預設情況下, Git 使用設置為預設文字編輯器 ($VISUAL或$EDITOR) 的任何內容, 否則將返回到vi編輯器來創建和編輯提交和標記郵件。若要將該預設值更改為其他內容, 可以使用core.editor設置:
$ git config --global core.editor emacs
現在, 無論設置為預設 shell 編輯器是什麼, 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

如果您正在製作帶批註的簽名標記 (如簽名您的工作中所述), 則將 gpg 簽名金鑰設置為配置設置會使操作更容易。將金鑰識別碼 設置為如下所示:
$ git config --global user.signingkey <gpg-key-id>
現在, 您可以對標記進行簽名, 而無需每次使用git tag命令指定金鑰:
$ git tag -s <tag-name>

core.excludesfile

您可以在專案的.gitignore檔中放置模式, 使 git 不會將其視為未跟蹤的檔, 或者在運行 git 添加時嘗試對其進行git add如忽略不需要的檔案中所述.
但有時您希望忽略與您一起使用的所有存儲庫的某些檔。如果您的電腦正在運行 Mac OS X, 您可能已經熟悉.DS_Store檔。如果你喜歡的編輯器是 Emacs 或 Vim, 你知道以~ .swp結尾的檔案名.
通過此設置, 您可以編寫一種全域.gitignore檔。如果創建包含這些內容~/.gitignore_global檔:
*~
.*.swp
.DS_Store
...你運行git config --global core.excludesfile ~/.gitignore_global, git 將永遠不會再打擾你關於這些檔。

help.autocorrect

如果鍵入的命令錯誤, 它將向您顯示如下內容:
$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.

Did you mean this?
    checkout
Git 很有説明地試圖找出你的意思, 但它仍然拒絕這樣做。如果將help.autocorrect為 1, git 實際上將為您運行此命令:
$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...
請注意, "0.1秒" 業務。help.autocorrect是一個整數, 表示十分之一秒。因此, 如果將其設置為 50, Git 將在執行自動校正的命令之前給您5秒的時間來改變主意。

Git 中的顏色

Git 完全支援彩色終端輸出, 極大地説明您快速、輕鬆地直觀地分析命令輸出。許多選項可以説明您將顏色設置為您的首選項。

color.ui

Git 會自動為其大部分輸出著色, 但如果您不喜歡此行為, 則會有一個主開關。要關閉所有 Git 的彩色終端輸出, 請執行以下操作:
$ git config --global color.ui false
預設設置為auto, 當它直接進入終端時, 它會輸出顏色, 但當輸出重定向到管道或檔時, 它會省略顏色控制代碼。
您還可以將其設置為always忽略終端和管道之間的差異。你很少會想要這個;在大多數情況下, 如果您希望在重定向輸出中使用顏色代碼, 則可以將--color標誌傳遞給 git 命令, 以強制其使用顏色代碼。預設設置幾乎總是您想要的。

color.*

如果要更具體地說明哪些命令是彩色的以及如何著色, Git 將提供特定于語言的著色設置。其中的每一個都可以設置為true、false或always:
color.branch
color.diff
color.interactive
color.status
此外, 如果要覆蓋每種顏色, 每個子設置都可以用於為輸出的某些部分設置特定的顏色。例如, 要將差異輸出中的元資訊設置為藍色前景、黑色背景和粗體文本, 可以運行
$ git config --global color.diff.meta "blue black bold"
您可以將顏色設置為以下任何值:normal、black、red、green、yellow、blue、品magenta、cyan或white。如果您想要像前面示例中的粗體屬性, 可以從bold、dim、 ul (底線)、blink和reverse(交換前景和背景) 中進行選擇。

外部合併和差異工具

儘管 Git 有一個內部差異實現, 這也是我們在本書中所展示的, 但您可以設置一個外部工具。您還可以設置圖形合併衝突解決工具, 而不必手動解決衝突。我們將演示如何設置 "強制視覺合併工具" (P4Merge) 來執行差異和合併解析度, 因為它是一個不錯的圖形工具, 並且是免費的。
如果你想嘗試一下, P4Merge 適用于所有主要平臺, 所以你應該能夠做到這一點。我們將在適用于 Mac 和 Linux 系統的示例中使用路徑名;對於 Windows, 您必須將/usr/local/bin更改為環境中的可執行路徑。
首先,從 "強制" 下載 P4Merge.接下來, 您將設置外部包裝腳本來運行您的命令。我們將使用 Mac 路徑的可執行檔;在其他系統中, 它將是您的p4merge二進位檔案的安裝位置。設置名為 Exmerge 的合併包裝extMerge腳本, 使用提供的所有參數調用二進位檔案:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
Diff 包裝檢查以確保提供了七個參數, 並將其中的兩個傳遞給合併腳本。預設情況下, Git 將以下參數傳遞給 diff 程式:
path old-file old-hex old-mode new-file new-hex new-mode
因為您只需要old-file和new-file參數, 所以您可以使用包裝腳本來傳遞所需的參數。
$ 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>.trustExitCodegit, 如果結束代碼的出口代碼程式指示成功的合併解析度或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
在設置了所有這些之後, 如果您運行這樣的差異命令:
$ git diff 32d1776b1^ 32d1776b1
Git 沒有在命令列上獲取差異輸出, 而是觸發 P4Merge, 如下所示:
P4Merge.
第142點。P4Merge。
如果您嘗試合併兩個分支, 並隨後有合併衝突, 您可以運行命令git mergetool它啟動 P4Merge, 讓您通過該 GUI 工具解決衝突。
這個包裝設置的好處是, 你可以很容易地改變你的差異和合併工具。例如, 若要更改extDiff和extMerge工具以運行 kdiff3 工具, 只需編輯extMerge檔即可:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
現在, Git 將使用 KDiff3 工具來差異查看和合併衝突解決。
Git 是預設的, 可以使用許多其他的合併解析度工具, 而無需設置 cmd 配置。若要查看它支援的工具的清單, 請嘗試以下操作:
$ 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 進行差異沒有興趣, 而是想只用于合併解析度, 而 kdif3 命令就在你的路徑中, 那麼你可以運行 "
$ git config --global merge.tool kdiff3
如果您運行此, 而不是設置extMerge和extDiff檔, Git 將使用 kdiff3 的合併解析度和正常的 git 差異工具的差異。

格式和空白

格式化和空白問題是許多開發人員在協作 (尤其是跨平臺) 時遇到的一些更令人沮喪和微妙的問題。修補程式或其他協作工作很容易引入細微的空白更改, 因為編輯器會默默介紹它們, 如果您的檔曾經接觸過 Windows 系統, 它們的行尾可能會被替換。Git 有一些配置選項可以説明解決這些問題。

core.autocrlf

如果您在 Windows 上程式設計, 並與不是在 windows 上程式設計的人員一起工作 (反之亦然), 您可能會在某個時候遇到行尾問題。這是因為 Windows 在其檔中使用行返回字元和換行字元, 而 Mac 和 Linux 系統只使用換行字元。這是跨平臺工作的一個微妙但令人難以置信的令人討厭的事實;Windows 上的許多編輯器以靜默方式將現有的 lf 樣式行尾替換為 CRLF, 或者在使用者命中輸入鍵時插入兩個行尾字元。
Git 可以通過在將檔添加到索引時自動將 CRLF 行結尾轉換為 LF 來處理此問題, 反之亦然, 反之亦然, 當它將代碼簽出到檔案系統時。您可以使用core.autocrlf . autocrlf 設置打開此功能。如果您在 Windows 電腦上, 請將其設置為true -這會在簽出代碼時將 lf 結尾轉換為 crlf:
$ git config --global core.autocrlf true
如果您使用的是使用 LF 行結尾的 Linux 或 Mac 系統, 則不希望 Git 在簽出檔時自動轉換它們; 如果您使用的是使用 lf 行結尾的 linux 或 mac 系統, 則不希望 Git 自動轉換它們。但是, 如果不小心引入了帶有 CRLF 結尾的檔, 則可能需要 Git 來修復它。您可以通過設置 corc. aut眼神輸入來告訴 Git 在提交core.autocrlf將 crlf 轉換為 lf, 但不能相反。
$ git config --global core.autocrlf input
此設置將在 Windows 簽出中留下 CRLF 結尾, 但 LF 結尾在 Mac 和 Linux 系統以及存儲庫中。
如果您是執行僅使用 windows 專案的 Windows 程式師, 則可以關閉此功能, 通過將配置值設置為false來將回車記錄在存儲庫中:
$ git config --global core.autocrlf false

core.whitespace

Git 是預設的, 用於檢測和修復一些空白問題。它可以查找六個主要空白問題--三個問題在預設情況下是啟用的, 可以關閉, 三個在預設情況下是禁用的, 但可以啟動。
預設情況下打開的三個是blank-at-eol點-eol, 它在一行的末尾查找空格;blank-at-eof其中注意到空白行在一個檔的末尾;和space-before-tab, 它在行開頭的選項卡之前查找空格。
預設情況下禁用但可以打開的三個indent-with-non-tab, 它查找以空格而不是選項卡開頭的行 (並由tabwidth選項控制);tab-in-indent縮進, 它在行的縮進部分中監視選項卡;和cr-at-eol, 它告訴 git, 線上路末端返回的回車是可以的。
您可以通過將 core. 白空間core.whitespace您想要打開或關閉的值 (用逗號分隔) 來告訴 git 您想要啟用這些值中的哪一個。您可以通過將設置排除在設置字串之外或在值前面加上 "" -來禁用設置。例如, 如果您希望設置除cr-at-eol以外的所有內容, 則可以執行以下操作:
$ git config --global core.whitespace \
    trailing-space,space-before-tab,indent-with-non-tab
Git 將檢測到這些問題時, 您運行git diff命令, 並嘗試為它們著色, 以便您可以在提交之前修復它們。當您應用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 檢查每個推送上的物件一致性, 可以通過將receive.fsckObjects為 true 來強制它執行此操作:
$ git config --system receive.fsckObjects true
現在, Git 將在接受每個推送之前檢查存儲庫的完整性, 以確保有問題 (或惡意) 的用戶端不會引入損壞的資料。

receive.denyNonFastForwards

如果您重新建立已推送的提交的基礎, 然後嘗試再次推送, 或者嘗試將提交推送到不包含遠端分支當前指向的提交的遠端分支, 則您將被拒絕。這通常是一個好的政策;但在重基的情況下, 您可能會確定您知道自己在做什麼, 並且可以強制使用-f標誌將遠端分支更新到推送命令。
要告訴 Git 拒絕強制推送, 請設置receive.denyNonFastForwards:
$ git config --system receive.denyNonFastForwards true
另一種方法, 你可以做到這一點是通過伺服器端接收掛鉤, 我們將在一點介紹。這種方法允許您執行更複雜的操作, 例如拒絕向特定的使用者子集進行非快速轉發。

receive.denyDeletes

denyNonFastForwards策略的解決方法之一是讓使用者刪除分支, 然後使用新引用將其推回。若要避免這種情況, 請將receive.denyDeletes設置為 true:
$ git config --system receive.denyDeletes true
這將拒絕刪除分支或標記--沒有使用者可以執行此操作。若要刪除遠端分支, 必須手動從伺服器中刪除 ref 檔。還有一些更有趣的方法可以通過 Acl 在每個使用者的基礎上執行此操作, 您將在一個示例 git 強制策略中瞭解到這一點.

沒有留言:

張貼留言

gitbook9.2翻譯未整理

9.2 Git 和其他系統-遷移到 Git Migrating to Git 如果您在另一個 VCS 中有一個現有的代碼庫, 但您已決定開始使用 Git, 則必須以這樣或那樣的方式遷移專案。 本節介紹了一些通用系統的導入器, 然後演示如何開發您自己的自訂導入器。 您...