git-pull · Git 中文參考

# git-pull > 原文： [https://git-scm.com/docs/git-pull](https://git-scm.com/docs/git-pull) > > 貢獻者：[Mrhuangyi](https://github.com/Mrhuangyi) ## 名稱 git-pull - 從另一個存儲庫或本地分支獲取并與其集成 ## 概要 ``` git pull [<options>] [<repository> [<refspec>…?]] ``` ## 描述將來自遠程存儲庫的更改合并到當前分支中。在默認模式下，`git pull`是`git fetch`的縮寫，后跟`git merge FETCH_HEAD`。更確切地說， _git pull_ 使用給定參數運行 _git fetch_ 并調用 _git merge_ 將檢索到的分支頭合并到當前分支中。使用`--rebase`，它運行 _git rebase_ 而不是 _git merge_ 。 <庫>應該是傳遞給 [git-fetch [1]](https://git-scm.com/docs/git-fetch) 的一個遠程存儲庫的名稱。 <的Refspec>可以命名任意遠程引用（例如，標簽的名稱），或者甚至是具有相應遠程跟蹤分支的引用集合（例如，refs / heads / *：refs / remotes / origin / *），但通常它是遠程存儲庫中分支的名稱。 < repository>和< branch>的默認值從 [git-branch [1]](https://git-scm.com/docs/git-branch) `--track`設置的當前分支的“遠程”和“合并”配置中讀取。假設存在以下歷史記錄并且當前分支為“`master`”： ``` A---B---C master on origin / D---E---F---G master ^ origin/master in your repository ``` 因為它偏離本地`master`（即`E`），所以“`git pull`”將從遠程`master`分支獲取并重放相應的更改，直到它的當前提交（`C`）在`master`上面并將結果記錄在新提交中，同時記錄兩個父提交的名稱以及描述更改的用戶的日志消息。 ``` A---B---C origin/master / \ D---E---F---G---H master ``` 有關詳細信息，請參閱 [git-merge [1]](https://git-scm.com/docs/git-merge) ，包括如何呈現和處理沖突。在Git 1.7.0或更高版本中，要取消一個有沖突的合并，請使用`git reset --merge`。 **警告**：在舊版本的Git中，不鼓勵使用未提交的更改運行 _git pull_ ：盡管或許可行，但它可能會使您處于難以退出的沖突狀態如果任何遠程更改與本地未提交的更改重疊，則將自動取消合并并且不更改工作樹。通過 [git-stash [1]](https://git-scm.com/docs/git-stash) 拉動或存放它們之前，通常最好在工作順序中進行任何局部更改。 ## OPTIONS ``` -q ``` ``` --quiet ``` 這將傳遞給基礎git-fetch以在傳輸過程中進行靜噪報告，并在合并期間將基礎git-merge傳遞給靜噪輸出。 ``` -v ``` ``` --verbose ``` 傳遞--verbose到git-fetch和git-merge。 ``` --[no-]recurse-submodules[=yes|on-demand|no] ``` 此選項控制是否應該獲取和更新所有已填充子模塊的新提交（請參閱 [git-config [1]](https://git-scm.com/docs/git-config) 和 [gitmodules [5]](https://git-scm.com/docs/gitmodules) ）。如果通過rebase完成檢出，則本地子模塊提交也會被重新設置。如果通過合并完成更新，則解析并檢出子模塊沖突。 ### 與合并相關的選項 ``` --commit ``` ``` --no-commit ``` 執行合并并提交結果。此選項可用于覆蓋--no-commit。使用--no-commit執行合并但假裝合并失敗并且不自動提交，以便讓用戶有機會在提交之前檢查并進一步調整合并結果。 ``` --edit ``` ``` -e ``` ``` --no-edit ``` 在提交成功的機械合并之前調用編輯器以進一步編輯自動生成的合并消息，以便用戶可以解釋并證明合并。 `--no-edit`選項可用于接受自動生成的消息（通常不鼓勵這樣做）。較舊的腳本可能取決于不允許用戶編輯合并日志消息的歷史行為。他們將在運行`git merge`時看到編輯器打開。為了便于將此類腳本調整為更新的行為，可以在環境變量`GIT_MERGE_AUTOEDIT`的開頭設置為`no`。 ``` --ff ``` 當合并解析為快進時，僅更新分支指針，而不創建合并提交。這是默認行為。 ``` --no-ff ``` 即使合并解析為快進，也要創建合并提交。這是在 _refs / tags /_ 層次結構中合并未存儲在其自然位置的帶注釋（且可能已簽名）的標記時的默認行為。 ``` --ff-only ``` 拒絕以非零狀態合并和退出，除非當前`HEAD`已經是最新的，或者合并可以解析為快進。 ``` -S[<keyid>] ``` ``` --gpg-sign[=<keyid>] ``` GPG簽署生成的合并提交。 `keyid`參數是可選的并且默認為提交者標識;如果具體指定，它必須粘在沒有空格的選項上。 ``` --log[=<n>] ``` ``` --no-log ``` 除了分支名稱之外，還使用最多< n>的單行描述填充日志消息。正在合并的實際提交。另見 [git-fmt-merge-msg [1]](https://git-scm.com/docs/git-fmt-merge-msg) 。使用--no-log不會列出正在合并的實際提交中的單行描述。 ``` --signoff ``` ``` --no-signoff ``` 在提交日志消息的末尾由提交者逐行添加簽名。簽收的含義取決于項目，但它通常證明提交者有權在同一許可下提交此作品并同意開發者原產地證書（參見 [http://developercertificate.org/](http://developercertificate.org/) ] 欲獲得更多信息）。使用--no-signoff時不要添加類似Sign-off-by的短行。 ``` --stat ``` ``` -n ``` ``` --no-stat ``` 在合并結束時顯示diffstat。 diffstat也由配置選項merge.stat控制。使用-n或--no-stat時，在合并結束時不顯示diffstat。 ``` --squash ``` ``` --no-squash ``` 生成工作樹和索引狀態，就好像發生了真正的合并（合并信息除外），但實際上沒有提交，移動`HEAD`或記錄`$GIT_DIR/MERGE_HEAD`（導致下一個`git commit`命令到創建合并提交）。這允許您在當前分支之上創建單個提交，其效果與合并另一個分支（或章魚的情況下更多）相同。使用--no-squash執行合并并提交結果。此選項可用于覆蓋--squash。 ``` -s <strategy> ``` ``` --strategy=<strategy> ``` 使用給定的合并策略;可以多次提供，以按照應該嘗試的順序指定它們。如果沒有`-s`選項，則使用內置的策略列表（合并單個頭時 _git merge-recursive_ ，否則使用 _git merge-octopus_ ）。 ``` -X <option> ``` ``` --strategy-option=<option> ``` 將合并策略特定選項傳遞給合并策略。 ``` --verify-signatures ``` ``` --no-verify-signatures ``` 驗證正在合并的側分支的提示提交是否使用有效密鑰簽名，即具有有效uid的密鑰：在默認信任模型中，這意味著簽名密鑰已由可信密鑰簽名。如果側分支的提示提交未使用有效密鑰簽名，則合并將中止。 ``` --summary ``` ``` --no-summary ``` 同義詞--stat和--no-stat;這些已被棄用，將來會被刪除。 ``` --allow-unrelated-histories ``` 默認情況下，`git merge`命令拒絕合并不共享共同祖先的歷史記錄。在合并獨立開始生命的兩個項目的歷史時，此選項可用于覆蓋此安全性。由于這是一種非常罕見的情況，因此默認情況下不會啟用任何配置變量來啟用它，也不會添加。 ``` -r ``` ``` --rebase[=false|true|merges|preserve|interactive] ``` 如果為true，則在獲取后將當前分支重新綁定在上游分支的頂部。如果存在與上游分支對應的遠程跟蹤分支，并且自上次提取以來上游分支已重新定位，則rebase使用該信息來避免重新定位非本地更改。設置為`merges`時，使用`git rebase --rebase-merges`進行rebase，以便本地合并提交包含在rebase中（有關詳細信息，請參閱 [git-rebase [1]](https://git-scm.com/docs/git-rebase) ）。設置為preserve時，將`--preserve-merges`選項的rebase傳遞給`git rebase`，以便本地創建的合并提交不會被展平。如果為false，則將當前分支合并到上游分支中。當為`interactive`時，啟用rebase的交互模式。如果要使`git pull`始終使用`--rebase`而不是合并，請參見 [git-config [1]](https://git-scm.com/docs/git-config) 中的`pull.rebase`，`branch.<name>.rebase`和`branch.autoSetupRebase`。 | 注意 | 這是一種潛在的_危險_操作模式。它重寫了歷史，當你已經發布了這段歷史時，它并不是一個好兆頭。除非您仔細閱讀 [git-rebase [1]](https://git-scm.com/docs/git-rebase) ，否則**不能**使用此選項。 | ``` --no-rebase ``` 先覆蓋--rebase。 ``` --autostash ``` ``` --no-autostash ``` 在開始rebase之前，根據需要隱藏本地修改（參見 [git-stash [1]](https://git-scm.com/docs/git-stash) ），并在完成后應用存儲條目。 `--no-autostash`用于覆蓋`rebase.autoStash`配置變量（參見 [git-config [1]](https://git-scm.com/docs/git-config) ）。此選項僅在使用“--rebase”時有效。 ### 與獲取相關的選項 ``` --all ``` 獲取所有遙控器。 ``` -a ``` ``` --append ``` 將獲取的引用的引用名稱和對象名稱附加到`.git/FETCH_HEAD`的現有內容。如果沒有此選項，`.git/FETCH_HEAD`中的舊數據將被覆蓋。 ``` --depth=<depth> ``` 從每個遠程分支歷史記錄的提示限制提取到指定的提交數。如果使用`--depth=<depth>`選項（參見 [git-clone [1]](https://git-scm.com/docs/git-clone) ）獲取`git clone`創建的_淺_存儲庫，請將歷史記錄加深或縮短到指定的提交數。不提取深化提交的標記。 ``` --deepen=<depth> ``` 與--depth類似，不同之處在于它指定了當前淺邊界而不是每個遠程分支歷史記錄的提交數。 ``` --shallow-since=<date> ``` 深化或縮短淺存儲庫的歷史記錄，以包括< date>之后的所有可訪問提交。 ``` --shallow-exclude=<revision> ``` 深化或縮短淺存儲庫的歷史記錄，以排除從指定的遠程分支或標記可到達的提交。可以多次指定此選項。 ``` --unshallow ``` 如果源存儲庫已完成，請將淺存儲庫轉換為完整存儲庫，從而消除淺存儲庫所施加的所有限制。如果源存儲庫很淺，則盡可能多地獲取，以便當前存儲庫與源存儲庫具有相同的歷史記錄。 ``` --update-shallow ``` 默認情況下，從淺存儲庫中獲取時，`git fetch`拒絕需要更新.git / shallow的引用。此選項更新.git / shallow并接受此類引用。 ``` --negotiation-tip=<commit|glob> ``` 默認情況下，Git將向服務器報告可從所有本地引用訪問的提交，以查找公共提交以嘗試減少要接收的包文件的大小。如果指定，Git將僅報告從給定提示可到達的提交。當用戶知道哪個本地ref可能與正在獲取的上游引用有共同提交時，這對于加速提取是有用的。此選項可以多次被指定;如果是這樣，Git將報告從任何給定的提交中可訪問的提交。此選項的參數可以是ref的名稱，ref或者提交的（可能縮寫的）SHA-1上的glob。指定glob等效于多次指定此選項，每個匹配對應的一個ref名稱。另請參見 [git-config [1]](https://git-scm.com/docs/git-config) 中記錄的`fetch.negotiationAlgorithm`配置變量。 ``` -f ``` ``` --force ``` 當 _git fetch_ 與`<src>:<dst>` refspec一起使用時，它可能會拒絕更新本地分支，如 [git-fetch [1]](https://git-scm.com/docs/git-fetch) 文檔的`<refspec>`部分所述。此選項會覆蓋該檢查。 ``` -k ``` ``` --keep ``` 保持下載的包。 ``` --no-tags ``` 默認情況下，指向從遠程存儲庫下載的對象的標記將被提取并存儲在本地。此選項會禁用此自動標記。可以使用遠程。< name> .tagOpt設置指定遠程的默認行為。見 [git-config [1]](https://git-scm.com/docs/git-config) 。 ``` -u ``` ``` --update-head-ok ``` 默認情況下 _git fetch_ 拒絕更新與當前分支對應的頭部。此標志禁用檢查。這純粹是為 _git pull_ 與 _git fetch_ 內部使用時進行通信，除非你實現你自己的瓷器，否則你不應該使用它。 ``` --upload-pack <upload-pack> ``` 當給定，并且要獲取的存儲庫由 _git fetch-pack_ 處理時，`--exec=<upload-pack>`被傳遞給命令以指定另一端運行的命令的非默認路徑。 ``` --progress ``` 除非指定了-q，否則在將標準錯誤流附加到終端時，默認情況下會報告進度狀態。即使標準錯誤流未定向到終端，此標志也會強制進度狀態。 ``` -o <option> ``` ``` --server-option=<option> ``` 使用協議版本2進行通信時，將給定的字符串傳輸到服務器。給定的字符串不得包含NUL或LF字符。當給出多個`--server-option=<option>`時，它們都按照命令行中列出的順序發送到另一側。 ``` -4 ``` ``` --ipv4 ``` 僅使用IPv4地址，忽略IPv6地址。 ``` -6 ``` ``` --ipv6 ``` 僅使用IPv6地址，忽略IPv4地址。 ``` <repository> ``` “遠程”存儲庫，它是獲取或拉取操作的源。該參數可以是URL（參見下面的 [GIT URL](#URLS) 部分）或remote的名稱（參見下面的 [REMOTES](#REMOTES) 部分）。 ``` <refspec> ``` 指定要獲取的引用和要更新的本地引用。如果命令行中沒有< refspec> s，則從`remote.<repository>.fetch`變量讀取reff to fetch（參見 [git-fetch [1]](https://git-scm.com/docs/git-fetch) ）。 < refspec>的格式參數是可選加`+`，后跟源< src>，后跟冒號`:`，后跟目標ref< dst>。當< dst>時，可以省略冒號。是空的。 < SRC>通常是ref，但它也可以是完全拼寫的十六進制對象名稱。 `tag <tag>`表示與`refs/tags/<tag>:refs/tags/<tag>`相同;它請求獲取給定標記的所有內容。匹配< src>的遠程引用取出，如果< dst>不是空字符串，嘗試更新與其匹配的本地引用。在沒有`--force`的情況下是否允許更新取決于它被提取到的ref命名空間，被提取的對象的類型，以及更新是否被認為是快進。通常，相同的規則適用于推送時的提取，請參閱 [git-push [1]](https://git-scm.com/docs/git-push) 的`<refspec>...`部分。 _git fetch_ 特有的那些規則的例外情況如下所述。直到Git版本2.20，并且與使用 [git-push [1]](https://git-scm.com/docs/git-push) 推送時不同，對`refs/tags/*`的任何更新都將在refspec（或`--force`）中沒有`+`的情況下被接受。在獲取時，我們會混淆地將遠程的所有標記更新視為強制提取。從Git版本2.20開始，獲取更新`refs/tags/*`的方式與推送時相同。即如果沒有refspec（或`--force`）中的`+`，任何更新都將被拒絕。與使用 [git-push [1]](https://git-scm.com/docs/git-push) 進行推送時不同，[refdpec（或`--force`）中的`+`將接受`refs/{tags,heads}/*`以外的任何更新，無論是否交換，例如一個blob的樹對象，或另一個提交的提交，它沒有先前的提交作為祖先等。與使用 [git-push [1]](https://git-scm.com/docs/git-push) 進行推送不同，沒有任何配置可以修改這些規則，也沒有類似于`pre-receive`掛鉤的`pre-fetch`掛鉤。與使用 [git-push [1]](https://git-scm.com/docs/git-push) 推送一樣，可以通過向refspec添加可選的前導`+`（或使用`--force` 命令行選項）來覆蓋上面描述的關于不允許作為更新的所有規則。。唯一的例外是沒有任何強制將使`refs/heads/*`命名空間接受非提交對象。 | 注意 | 當你想要獲取的遠程分支被認為是經常倒帶和重新定位時，預計它的新提示將不會是其上一個提示的后代（如上次提取時存儲在遠程跟蹤分支中）。您可能希望使用`+`符號來指示此類分支將需要非快進更新。無法確定或聲明具有此行為的存儲庫中的分支可用;拉動用戶只需知道這是分支的預期使用模式。 | | 注意 | 在 _git pull_ 命令行上直接列出多個< refspec&gt和在您的配置中為< repository>提供多個`remote.<repository>.fetch`條目并運行 _git pull_ 命令，沒有任何明確的< refspec>參數之間存在差異。在命令行中明確列出的< refspec>在獲取后始終合并到當前分支中。換句話說，如果你列出多個遠程引用， _git pull_ 將創建一個Octopus合并。另一方面，如果你沒有列出任何明確的< refspec>在命令行上的參數， _git pull_ 將獲取它在`remote.<repository>.fetch`配置中找到的所有< refspec> s并僅合并第一個找到的< refspec>到當前的分支。這是因為很少使用遠程參考設備制作八達通，而通過提取一個以上來一次跟蹤多個遠程磁頭通常很有用。 | ## GIT網址通常，URL包含有關傳輸協議，遠程服務器的地址以及存儲庫路徑的信息。根據傳輸協議，可能缺少某些信息。 Git支持ssh，git，http和https協議（此外，ftp和ftps可用于獲取，但這是低效的并且已被棄用;請勿使用它）。本機傳輸（即git：// URL）不進行身份驗證，在不安全的網絡上應當謹慎使用。可以使用以下語法： * SSH：// [用戶@] host.xz [：端口] /path/to/repo.git/ * GIT中：//host.xz [：端口] /path/to/repo.git/ * HTTP [S]：//host.xz [：端口] /path/to/repo.git/ * FTP [S]：//host.xz [：端口] /path/to/repo.git/ 另一種類似scp的語法也可以與ssh協議一起使用： * [用戶@] host.xz：路徑/到/ repo.git / 只有在第一個冒號之前沒有斜杠時才會識別此語法。這有助于區分包含冒號的本地路徑。例如，本地路徑`foo:bar`可以指定為絕對路徑或`./foo:bar`，以避免被誤解為一個ssh url。 ssh和git協議還支持?用戶名擴展： * SSH：// [用戶@] host.xz [：端口] /?[用戶] /path/to/repo.git/ * GIT中：//host.xz [：端口] /?[用戶] /path/to/repo.git/ * [用戶@] host.xz：/?[用戶] /path/to/repo.git/ 對于本地也受Git支持的本地存儲庫，可以使用以下語法： * /path/to/repo.git/ * 文件：///path/to/repo.git/ 這兩種語法大多是等價的，除了克隆時，前者暗示--local選項。有關詳細信息，請參閱 [git-clone [1]](https://git-scm.com/docs/git-clone) 。當Git不知道如何處理某種傳輸協議時，它會嘗試使用 _remote-< transport>_ 遠程助手，如果存在的話。要顯式請求遠程幫助程序，可以使用以下語法： * <運輸> ::<地址> 其中<地址>可以是路徑，服務器和路徑，或者由被調用的特定遠程助手識別的任意類似URL的字符串。有關詳細信息，請參閱 [gitremote-helpers [1]](https://git-scm.com/docs/gitremote-helpers) 。如果存在大量具有相似名稱的遠程存儲庫，并且您希望為它們使用不同的格式（以便將您使用的URL重寫為有效的URL），則可以創建表單的配置部分： ``` [url "<actual url base>"] insteadOf = <other url base> ``` 例如，有了這個： ``` [url "git://git.host.xz/"] insteadOf = host.xz:/path/to/ insteadOf = work: ``` 像“work：repo.git”這樣的URL或類似“host.xz：/path/to/repo.git”的URL將在任何帶有URL的上下文中被重寫為“git：//git.host.xz/repo” git的”。如果要為僅推送重寫URL，可以創建表單的配置部分： ``` [url "<actual url base>"] pushInsteadOf = <other url base> ``` 例如，有了這個： ``` [url "ssh://example.org/"] pushInsteadOf = git://example.org/ ``` 像“git：//example.org/path/to/repo.git”這樣的網址將被重寫為“ssh：//example.org/path/to/repo.git”以進行推送，但是pull仍會使用原始網址。 ## 遙控可以使用以下某個名稱而不是URL作為`<repository>`參數： * Git配置文件中的一個遙控器：`$GIT_DIR/config`， * `$GIT_DIR/remotes`目錄中的文件，或 * `$GIT_DIR/branches`目錄中的文件。所有這些也允許你從命令行省略refspec，因為它們每個都包含一個git將默認使用的refspec。 ### 在配置文件中命名為remote 您可以選擇使用 [git-remote [1]](https://git-scm.com/docs/git-remote) ， [git-config [1]](https://git-scm.com/docs/git-config) 提供之前配置的遙控器的名稱，甚至可以手動編輯`$GIT_DIR/config`文件。此遠程的URL將用于訪問存儲庫。如果你未在命令行上提供refspec，則默認情況下將使用此遠程的refspec。配置文件中的條目如下所示： ``` [remote "<name>"] url = <url> pushurl = <pushurl> push = <refspec> fetch = <refspec> ``` `<pushurl>`僅用于推送。它是可選的，默認為`<url>`。 ### `$GIT_DIR/remotes`中的命名文件您可以選擇在`$GIT_DIR/remotes`中提供文件名。此文件中的URL將用于訪問存儲庫。如果未在命令行上提供refspec，則此文件中的refspec將用作默認值。該文件應具有以下格式： ``` URL: one of the above URL format Push: <refspec> Pull: <refspec> ``` _git push_ 使用`Push:`行， _git pull_ 和 _git fetch_ 使用`Pull:`系。可以為其他分支映射指定多個`Push:`和`Pull:`行。 ### `$GIT_DIR/branches`中的命名文件您可以選擇在`$GIT_DIR/branches`中提供文件名。此文件中的URL將用于訪問存儲庫。該文件應具有以下格式： ``` <url>#<head> ``` `<url>`是必需的; `#<head>`是可選的。根據操作，如果您沒有在命令行上提供一個refitpec，git將使用以下refspec中的一個。 `<branch>`是`$GIT_DIR/branches`中此文件的名稱，`<head>`默認為`master`。 git fetch使用： ``` refs/heads/<head>:refs/heads/<branch> ``` git push使用： ``` HEAD:refs/heads/<head> ``` ## 合并戰略合并機制（`git merge`和`git pull`命令）允許使用`-s`選項選擇后端_合并策略_。一些策略也可以采用自己的選項，可以通過向`git merge`和/或`git pull`提供`-X<option>`參數來傳遞。 ``` resolve ``` 這只能使用3向合并算法解析兩個頭（即當前分支和您從中拉出的另一個分支）。它試圖仔細檢測縱橫交錯的合并模糊，并且通常被認為是安全和快速的。 ``` recursive ``` 這只能使用3向合并算法解析兩個磁頭。當有多個可用于3向合并的共同祖先時，它會創建共同祖先的合并樹，并將其用作3向合并的參考樹。據報道，這會導致更少的合并沖突，而不會因為從Linux 2.6內核開發歷史記錄中進行的實際合并提交所做的測試而導致錯誤。此外，這可以檢測和處理涉及重命名的合并，但目前無法使用檢測到的副本。這是拉動或合并一個分支時的默認合并策略。 _遞歸_策略可以采用以下選項： ``` ours ``` 這個選項通過支持_我們的_版本來強制大塊的沖突干凈地自動解決。來自與我們方不沖突的其他樹的更改將反映到合并結果中。對于二進制文件，整個內容都來自我們這邊。這不應該與_我們的_合并策略混淆，后者甚至不會查看其他樹包含的內容。它丟棄了另一棵樹所做的一切，聲明_我們的_歷史記錄中包含了所有發生的事情。 ``` theirs ``` 這與_我們的_相反;請注意，與_我們的_不同，沒有_他們的_合并策略來混淆這個合并選項。 ``` patience ``` 使用此選項， _merge-recursive_ 花費一點額外的時間來避免由于不重要的匹配行（例如，來自不同函數的大括號）而有時發生的錯誤。當要合并的分支發生瘋狂分歧時使用此選項。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `--patience`。 ``` diff-algorithm=[patience|minimal|histogram|myers] ``` 告訴 _merge-recursive_ 使用不同的diff算法，這有助于避免由于不重要的匹配行（例如來自不同函數的大括號）而發生的錯誤。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `--diff-algorithm`。 ``` ignore-space-change ``` ``` ignore-all-space ``` ``` ignore-space-at-eol ``` ``` ignore-cr-at-eol ``` 為了進行三向合并，將具有指示類型的空白的行更改為未更改。與空行的其他更改混合的空白更改不會被忽略。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `-b`，`-w`，`--ignore-space-at-eol`和`--ignore-cr-at-eol`。 * 如果_他們的_版本只將空格更改引入一行，_我們的_版本被使用; * 如果_我們的_版本引入了空格更改，但_他們的_版本包含了實質性更改，_使用了他們的_版本; * 否則，合并以通常的方式進行。 ``` renormalize ``` 在解析三向合并時，這將運行虛擬簽出并檢入文件的所有三個階段。此選項適用于將分支與不同的清除過濾器或行尾規范化規則合并時使用。有關詳細信息，請參閱 [gitattributes [5]](https://git-scm.com/docs/gitattributes) 中的“合并具有不同簽入/簽出屬性的分支”。 ``` no-renormalize ``` 禁用`renormalize`選項。這會覆蓋`merge.renormalize`配置變量。 ``` no-renames ``` 關閉重命名檢測。這會覆蓋`merge.renames`配置變量。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `--no-renames`。 ``` find-renames[=<n>] ``` 打開重命名檢測，可選擇設置相似性閾值。這是默認值。這會覆蓋 _merge.renames_ 配置變量。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `--find-renames`。 ``` rename-threshold=<n> ``` 已棄用`find-renames=<n>`的同義詞。 ``` subtree[=<path>] ``` 此選項是_子樹_策略的更高級形式，其中策略猜測兩個樹在合并時必須如何移位以相互匹配。相反，指定的路徑是前綴（或從頭開始剝離），以使兩個樹的形狀匹配。 ``` octopus ``` 這解決了具有兩個以上磁頭的情況，但拒絕執行需要手動解決的復雜合并。它主要用于將主題分支頭捆綁在一起。這是拉動或合并多個分支時的默認合并策略。 ``` ours ``` 這會解析任意數量的頭，但合并的結果樹始終是當前分支頭的樹，實際上忽略了所有其他分支的所有更改。它旨在用于取代側枝的舊發展歷史。請注意，這與_遞歸_合并策略的-Xours選項不同。 ``` subtree ``` 這是一種修改后的遞歸策略。當合并樹A和B時，如果B對應于A的子樹，則首先調整B以匹配A的樹結構，而不是讀取相同級別的樹。這種調整也是對共同的祖先樹進行的。使用三向合并的策略（包括默認的_遞歸_），如果在兩個分支上進行了更改，但稍后在其中一個分支上進行了更改，則該更改將出現在合并結果中;有些人發現這種行為令人困惑。之所以會發生這種情況，是因為在執行合并時只考慮頭和合并基礎，而不是單個提交。因此，合并算法將恢復的更改視為完全沒有更改，而是替換更改的版本。 ## 違約行為通常人們使用`git pull`而不給出任何參數。傳統上，這相當于說`git pull origin`。但是，當在分支`<name>`上存在配置`branch.<name>.remote`時，將使用該值代替`origin`。為了確定用于獲取的URL，請參考配置`remote.<origin>.url`的值，如果沒有任何此類變量，則使用`$GIT_DIR/remotes/<origin>`中`URL:`行的值。為了確定在命令行上沒有任何refspec參數的情況下運行命令時要獲取（并且可選地存儲在遠程跟蹤分支中）的遠程分支，將查詢配置變量`remote.<origin>.fetch`的值，如果沒有t any，咨詢`$GIT_DIR/remotes/<origin>`并使用其`Pull:`線。除了OPTIONS部分中描述的refspec格式之外，您還可以使用如下所示的globbing refspec： ``` refs/heads/*:refs/remotes/origin/* ``` globbing refspec必須具有非空RHS（即必須存儲在遠程跟蹤分支中獲取的內容），并且其LHS和RHS必須以`/*`結束。以上規定了使用相同名稱的`refs/remotes/origin/`層次結構中的遠程跟蹤分支跟蹤所有遠程分支。在獲取之后確定要合并哪個遠程分支的規則有點涉及，以便不破壞向后兼容性。如果在`git pull`的命令行上給出了顯式refspec，則它們都被合并。如果命令行上沒有給出refspec，則`git pull`使用配置中的refspec或`$GIT_DIR/remotes/<origin>`。在這種情況下，以下規則適用： 1. 如果當前分支`<name>`的`branch.<name>.merge`配置存在，那么這是合并的遠程站點的分支的名稱。 2. 如果refspec是一個全局的，則不會合并任何內容。 3. 否則，合并第一個refspec的遠程分支。 ## 例子 * 更新你克隆的存儲庫的遠程跟蹤分支，然后將其中一個合并到當前分支中： ``` $ git pull $ git pull origin ``` 通常，合并的分支是遠程存儲庫的HEAD，但選擇由分支確定。< name> .remote和branch。< name> .merge options;有關詳細信息，請參閱 [git-config [1]](https://git-scm.com/docs/git-config) 。 * 合并到當前分支遠程分支`next`： ``` $ git pull origin next ``` 這會在FETCH_HEAD中暫時保留`next`的副本，但不會更新任何遠程跟蹤分支。使用遠程跟蹤分支，可以通過調用fetch和merge來完成相同的操作： ``` $ git fetch origin $ git merge origin/next ``` 如果您嘗試拉取后導致復雜沖突并且想要重新開始，則可以使用 _git reset_ 進行恢復。 ## 安全設計提取和推送協議的目的不是為了防止一方竊取不打算共享的其他存儲庫中的數據。如果您需要保護私有數據免受惡意對等方的攻擊，那么最佳選擇是將其存儲在另一個存儲庫中。這適用于客戶端和服務器。特別是，服務器上的命名空間對讀訪問控制無效;您應該只將命名空間的讀訪問權授予您信任的客戶端，并具有對整個存儲庫的讀訪問權限。已知的攻擊向量如下： 1. 受害者發送“有”行，宣傳其擁有的對象的ID，這些對象并未明確地用于共享，但如果對等方也擁有它們，則可用于優化轉移。攻擊者選擇一個對象ID X來竊取并向X發送一個ref，但不需要發送X的內容，因為受害者已經擁有它。現在，受害者認為攻擊者擁有X，并且稍后會將X的內容發送回攻擊者。（這種攻擊對于客戶端在服務器上執行是最直接的，通過在客戶端有權訪問的命名空間中創建ref，然后獲取它。服務器在客戶端上執行它的最可能方式是“將“X”合并到一個公共分支中，并希望用戶在此分支上執行其他工作，并將其推送回服務器，而不會注意到合并。） 2. 與＃1一樣，攻擊者選擇一個對象ID X來竊取。受害者發送攻擊者已經擁有的對象Y，并且攻擊者錯誤地聲稱擁有X而不是Y，因此受害者將Y作為針對X的增量發送。該增量顯示X的區域與攻擊者的Y類似。 ## BUGS 使用--recurse-submodules只能在已檢出的子模塊中獲取新的提交。例如，當上游在超級項目的剛剛提取的提交中添加了一個新的子模塊，子模塊本身無法獲取，因此無法在以后檢查該子模塊而無需再次進行提取。這預計將在未來的Git版本中被修復。 ## 也可以看看 [git-fetch [1]](https://git-scm.com/docs/git-fetch) ， [git-merge [1]](https://git-scm.com/docs/git-merge) ， [git-config [1]](https://git-scm.com/docs/git-config) ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件