git-push · Git 中文參考

# git-push > 原文： [https://git-scm.com/docs/git-push](https://git-scm.com/docs/git-push) ## 名稱 git-push - 更新遠程引用以及相關對象 ## 概要 ``` git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose] [-u | --set-upstream] [-o <string> | --push-option=<string>] [--[no-]signed|--signed=(true|false|if-asked)] [--force-with-lease[=<refname>[:<expect>]]] [--no-verify] [<repository> [<refspec>…?]] ``` ## 描述使用本地引用更新遠程引用，同時發送完成給定引用所必需的對象。通過在那里設置_掛鉤_，當你每次推入存儲庫時都可以使存儲庫發生有趣的事情。請參閱 [git-receive-pack [1]](https://git-scm.com/docs/git-receive-pack) 的文檔。如果命令行未使用`<repository>`參數指定進行推送的位置，則會查詢當前分支的`branch.*.remote`配置以確定推送位置。如果缺少相應配置，則默認為_原點_。當命令行沒有指定用`<refspec>...`參數或`--all`，`--mirror`，`--tags`選項推送什么時，該命令通過查詢`remote.*.push`配置找到默認的`<refspec>`，如果找不到，根據`push.default`配置來決定推送什么（參見 [git-config [1]](https://git-scm.com/docs/git-config) 了解`push.default`的含義）。當命令行和配置都沒有指定要推送的內容時，則使用默認行為，它對應于`push.default`的`simple`值：當前分支被推送到相應的上游分支，但作為安全措施，如果上游分支與本地分支的名稱不同，則推送被中止。 ## 選項 ``` <repository> ``` 作為推送操作目標的“遠程”存儲庫。該參數可以是一個URL（參見下面的 [GIT URL](#URLS) 部分）或遙控器的名稱（參見下面的 [REMOTES](#REMOTES) 部分）。 ``` <refspec>…? ``` 使用什么源對象指定要更新的目標。 < refspec>參數的格式是可選加`+`，后跟源對象< src>，后跟冒號`:`，后跟目標ref< dst>。 < src>通常是您想要推送的分支的名稱，但它可以是任意“SHA-1表達式”，例如`master~4`或`HEAD`（參見 [gitrevisions [7]](https://git-scm.com/docs/gitrevisions) ）。 < dst>通過此推送告知遠程端的哪個ref已更新。這里不能使用任意表達式，必須命名實際的ref。如果沒有任何`<refspec>`參數的`git push [<repository>]`設置為使用`<src>`和`remote.<repository>.push`配置變量更新目標的某些ref，則可以省略`:<dst>`部分 - 這樣的推送將更新`<src>`的參考號通常在命令行上沒有任何`<refspec>`的情況下更新。否則，缺少`:<dst>`意味著更新與`<src>`相同的參考號。如果< dst>不以`refs/`開頭（例如`refs/heads/master`）我們將嘗試推斷目的地< repository>上的`refs/*`中的位置它屬于< src>的類型被推，是否< dst>很曖昧。 * 如果< dst>明確地引用遠程< repository>上的引用。然后推送到那個參考。 * 如果< src>被解析為以refs / heads /或refs / tags /開頭的ref，然后將其添加到< dst>。 * 將來可能會添加其他歧義解決方案，但是現在任何其他情況都會出錯，并指出我們嘗試過的錯誤，并且取決于`advice.pushUnqualifiedRefname`配置（參見 [git-config [1]](https://git-scm.com/docs/git-config) ）建議你可能想要推薦的refs / namespace。 < src>引用的對象被用于更新< dst>遠程參考。是否允許這取決于`refs/*`中< dst>的位置。參考活動如下面詳細描述的那樣，在這些部分中，“更新”是指除刪除之外的任何修改，如下面幾節中所述的不同處理。 `refs/heads/*`命名空間僅接受提交對象，并且只有在可以快速轉發時才更新。 `refs/tags/*`命名空間將接受任何類型的對象（因為可以標記提交，樹和blob），并且將拒絕對它們的任何更新。可以將任何類型的對象推送到`refs/{tags,heads}/*`之外的任何命名空間。對于標記和提交，這些將被視為它們是`refs/heads/*`內的提交，以確定是否允許更新。即允許在`refs/{tags,heads}/*`之外快速提交提交和標記，即使在快速轉發的內容不是提交的情況下，也允許標記對象恰好指向新提交，這是提交的快進它正在替換的最后一個標記（或提交）。如果標記指向相同的提交，并且推送剝離的標記，即推送現有標記對象指向的提交，或者現有提交指向的新標記對象，則也允許使用完全不同的標記替換標記。。 `refs/{tags,heads}/*`之外的樹和blob對象的處理方式與它們在`refs/tags/*`中的方式相同，任何對它們的更新都將被拒絕。通過將可選的前導`+`添加到refspec（或使用`--force`命令行選項），可以覆蓋上面描述的關于不允許作為更新的所有規則。唯一的例外是沒有任何強制將使`refs/heads/*`命名空間接受非提交對象。鉤子和配置也可以覆蓋或修改這些規則，參見例如 [git-config [1]](https://git-scm.com/docs/git-config) 中的`receive.denyNonFastForwards`和 [githooks [5]](https://git-scm.com/docs/githooks) 中的`pre-receive`和`update`。推空< src>允許您刪除< dst>來自遠程存儲庫的ref。除非配置或掛鉤禁止，否則始終在refspec（或`--force`）中沒有前導`+`的情況下接受刪除。參見 [git-config [1]](https://git-scm.com/docs/git-config) 中的`receive.denyDeletes`和 [githooks [5]](https://git-scm.com/docs/githooks) 中的`pre-receive`和`update`。特殊refspec `:`（或`+:`允許非快進更新）指示Git推送“匹配”分支：對于本地端存在的每個分支，如果遠程端分支更新，則更新遠程端名稱已存在于遠程端。 `tag <tag>`表示與`refs/tags/<tag>:refs/tags/<tag>`相同。 ``` --all ``` 推送所有分支（即`refs/heads/`下的引用）;不能與其他< refspec>一起使用。 ``` --prune ``` 刪除沒有本地對應項的遠程分支。例如，如果不再存在具有相同名稱的本地分支，則將刪除遠程分支`tmp`。這也尊重refspecs，例如如果`refs/heads/foo`不存在，`git push --prune remote refs/heads/*:refs/tmp/*`將確保遠程`refs/tmp/foo`將被刪除。 ``` --mirror ``` 而不是將每個引用命名為push，指定將`refs/`下的所有引用（包括但不限于`refs/heads/`，`refs/remotes/`和`refs/tags/`）鏡像到遠程存儲庫。新創建的本地引用將被推送到遠程端，本地更新的引??用將在遠程端強制更新，并且已刪除的引用將從遠程端刪除。如果設置了配置選項`remote.<remote>.mirror`，則這是默認值。 ``` -n ``` ``` --dry-run ``` 做所有事情，除了實際發送更新。 ``` --porcelain ``` 生成機器可讀輸出。每個引用的輸出狀態行將以制表符的形式分隔并發送到stdout而不是stderr。我們將給出參考的完整符號名稱。 ``` -d ``` ``` --delete ``` 所有列出的引用都將從遠程存儲庫中被刪除。這與使用冒號為所有引號添加前綴相同。 ``` --tags ``` 除了在命令行中明確列出的refspec之外，還會推送`refs/tags`下的所有引用。 ``` --follow-tags ``` 推送沒有此選項的將要被推送的所有引用，并且還在`refs/tags`中推送遠程數據庫中缺少的注釋標記，但是指向可以從被推送的引用中訪問的commit-ish。也可以使用配置變量`push.followTags`指定。有關更多信息，請參閱 [git-config [1]](https://git-scm.com/docs/git-config) 中的`push.followTags`。 ``` --[no-]signed ``` ``` --signed=(true|false|if-asked) ``` GPG簽署推送請求以更新接收方的refs，以允許鉤子檢查和/或記錄。如果記錄為`false`或`--no-signed`，則不會嘗試簽名。如果為`true`或`--signed`，如果服務器不支持簽名推送，則推送將失敗。如果設置為`if-asked`，則當且僅當服務器支持簽名推送時才簽名。如果對`gpg --sign`的實際調用失敗，推送也將失敗。有關接收端的詳細信息，請參閱 [git-receive-pack [1]](https://git-scm.com/docs/git-receive-pack) 。 ``` --[no-]atomic ``` 如果可用，請在遠程端使用原子事務。要么更新所有引用，要么在出錯時，不更新引用。如果服務器不支持原子推送，則推送將失敗。 ``` -o <option> ``` ``` --push-option=<option> ``` 將給定的字符串傳輸到服務器，服務器將它們傳遞給預接收和后接收掛鉤。給定的字符串不得包含NUL或LF字符。當給出多個`--push-option=<option>`時，它們都按照命令行中列出的順序發送到另一側。如果沒有從命令行給出`--push-option=<option>`，則使用配置變量`push.pushOption`的值。 ``` --receive-pack=<git-receive-pack> ``` ``` --exec=<git-receive-pack> ``` 遠程端 _git-receive-pack_ 程序的路徑。當通過ssh推送到遠程存儲庫時，有時很有用，并且您沒有將程序放在默認$ PATH上的目錄中。 ``` --[no-]force-with-lease ``` ``` --force-with-lease=<refname> ``` ``` --force-with-lease=<refname>:<expect> ``` 通常，“git push”拒絕更新遠程ref，該遠程ref不是用于覆蓋它的本地ref的祖先。如果遠程ref的當前值是預期值，則此選項將覆蓋此限制。否則“git push”會失敗。想象一下，你必須改變你已發表的內容。您必須繞過“必須快進”規則才能將最初發布的歷史記錄替換為重新定位的歷史記錄。如果其他人在您重新定位時建立在您的原始歷史之上，那么遠程分支的提示可能會隨著她的提交而提前，并且盲目推動`--force`將失去她的工作。此選項允許您說您希望更新的歷史記錄是您重新定義并想要替換的內容。如果遠程引用仍然指向您指定的提交，您可以確定沒有其他人對引用做過任何事情。這就像在ref上接受“租約”而沒有明確地鎖定它，并且僅當“lease”仍然有效時才會更新遠程ref。單獨`--force-with-lease`，沒有指定細節，將通過要求它們的當前值與我們為它們提供的遠程跟蹤分支相同來保護將要更新的所有遠程ref。 `--force-with-lease=<refname>`，未指定期望值，將保護命名ref（單獨），如果要更新，則要求其當前值與我們為其設置的遠程跟蹤分支相同。 `--force-with-lease=<refname>:<expect>`將保護命名ref（單獨），如果它將要更新，通過要求其當前值與指定值`<expect>`相同（允許它與遠程跟蹤分支不同于我們的refname，或者在使用此表單時我們甚至不必擁有這樣的遠程跟蹤分支）。如果`<expect>`是空字符串，則指定的命名ref必須不存在。請注意，除了`--force-with-lease=<refname>:<expect>`之外的所有明確指定ref的當前值的表單仍然是實驗性的，并且隨著我們獲得與此功能相關的經驗，它們的語義可能會發生變化。 “--no-force-with-lease”將在命令行中取消之前的所有--force-with-lease。關于安全性的一般注意事項：提供沒有預期值的該選項，即`--force-with-lease`或`--force-with-lease=<refname>`與在遙控器上隱式運行`git fetch`以在后臺推送的任何東西非常相互作用，例如，您在Cronjob中的存儲庫中的`git fetch origin`。它提供的保護優于`--force`，確保您的工作所依據的后續更改不會被破壞，但如果某些后臺進程在后臺更新引用，則這很容易被忽略。除了遠程跟蹤信息之外，我們沒有任何其他內容作為您希望看到的能作為參考資料的啟發式信息。有可能導致破壞。如果您的編輯器或其他系統在后臺運行`git fetch`，那么緩解這種情況的方法就是簡單地設置另一個遠程： ``` git remote add origin-push $(git config remote.origin.url) git fetch origin-push ``` 現在，當后臺進程運行`git fetch origin`時，`origin-push`上的引用將不會更新，因此命令如下： ``` git push --force-with-lease origin-push ``` 除非您手動運行`git fetch origin-push`，否則將失敗。這種方法當然完全會被運行`git fetch --all`的東西所擊敗，在這種情況下你需要禁用它或做一些更乏味的事情，如： ``` git fetch # update 'master' from remote git tag base master # mark our base point git rebase -i master # rewrite some commits git push --force-with-lease=master:base master:master ``` 即為您已經看到并愿意覆蓋的上游代碼版本創建`base`標記，然后重寫歷史記錄，如果遠程版本仍在`base`，最后強制推送更改為`master`，無論是什么，您的本地`remotes/origin/master`已在后臺更新。 ``` -f ``` ``` --force ``` 通常，該命令拒絕更新遠程ref，該遠程ref不是用于覆蓋它的本地ref的祖先。此外，當使用`--force-with-lease`選項時，該命令拒絕更新當前值與預期值不匹配的遠程ref。此標志禁用這些檢查，并可能導致遠程存儲庫丟失提交;小心使用它。請注意，`--force`適用于所有被推送的引用，因此在`push.default`設置為`matching`或使用`remote.*.push`配置的多個推送目標時使用它可能會覆蓋當前分支以外的引用（包括本地引用）嚴格落后于他們的遠程對手）。要強制推送到一個分支，請使用refspec前面的`+`進行推送（例如`git push origin +master`強制推送到`master`分支）。有關詳細信息，請參閱上面的`<refspec>...`部分。 ``` --repo=<repository> ``` 此選項等同于< repository>論點。如果同時指定了兩者，則命令行參數優先。 ``` -u ``` ``` --set-upstream ``` 對于每個最新或成功推送的分支，添加上游（跟蹤）引用，由無參數 [git-pull [1]](https://git-scm.com/docs/git-pull) 和其他命令使用。有關更多信息，請參閱 [git-config [1]](https://git-scm.com/docs/git-config) 中的`branch.<name>.merge`。 ``` --[no-]thin ``` 這些選項傳遞給 [git-send-pack [1]](https://git-scm.com/docs/git-send-pack) 。當發送方和接收方共享許多相同的對象時，精簡傳輸會顯著減少發送的數據量。默認值為`--thin`。 ``` -q ``` ``` --quiet ``` 除非發生錯誤，否則禁止所有輸出，包括更新的ref列表。未向標準錯誤流報告進度。 ``` -v ``` ``` --verbose ``` 詳細地運行。 ``` --progress ``` 除非-q已被指定，否則在將標準錯誤流附加到終端時，默認情況下會報告進度狀態。即使標準錯誤流未定向到終端，此標志也會強制進度狀態。 ``` --no-recurse-submodules ``` ``` --recurse-submodules=check|on-demand|only|no ``` 可用于確保要推送的修訂使用的所有子模塊提交在遠程跟蹤分支上可用。如果使用_檢查_，Git將驗證在子模塊的至少一個遠程處可用的所有要推送的修訂中更改的子模塊提交。如果缺少任何提交，則將中止推送并以非零狀態退出。如果使用_按需_，則將推送在要推送的修訂中更改的所有子模塊。如果按需無法推送所有必要的修訂，它也將被中止并退出非零狀態。如果僅使用，則在超級項目未被按下時遞歸推送所有子模塊。當不需要子模塊遞歸時， _no_ 或`--no-recurse-submodules`的值可用于覆蓋push.recurseSubmodules配置變量。 ``` --[no-]verify ``` 切換預推鉤（參見 [githooks [5]](https://git-scm.com/docs/githooks) ）。默認值為--verify，使鉤子有機會阻止推送。使用--no-verify，掛鉤完全被繞過。 ``` -4 ``` ``` --ipv4 ``` 僅使用IPv4地址，忽略IPv6地址。 ``` -6 ``` ``` --ipv6 ``` 僅使用IPv6地址，忽略IPv4地址。 ## 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> ``` ## OUTPUT “git push”的輸出取決于所使用的傳輸方法;本節描述了推送Git協議時的輸出（本地或通過ssh）。 push的狀態以表格形式輸出，每行代表一個ref的狀態。每一行的形式如下： ``` <flag> <summary> <from> -> <to> (<reason>) ``` 如果使用了--porcelain，那么輸出的每一行都是以下形式： ``` <flag> \t <from>:<to> \t <summary> (<reason>) ``` 僅當使用--porcelain或--verbose選項時，才會顯示最新引用的狀態。 ``` flag ``` 一個表示ref狀態的字符： ``` (space) ``` 為了成功快進推送; ``` + ``` 成功的強制更新; ``` - ``` 成功刪除參考; ``` * ``` 成功推出新的參考; ``` ! ``` 對于拒絕或未能推送的裁判;和 ``` = ``` 對于一個最新的ref并且不需要推送的ref。 ``` summary ``` 對于成功推送的ref，摘要以適合用作`git log`的參數的形式顯示ref的舊值和新值（在大多數情況下這是`<old>..<new>`，而強制非快速的`<old>...<new>` - 轉發更新）。對于失敗的更新，提供了更多詳細信息： ``` rejected ``` Git根本沒有嘗試發送引用，通常是因為它不是快進而你沒有強制更新。 ``` remote rejected ``` 遠程端拒絕更新。通常由遠程端的掛鉤引起，或者因為遠程存儲庫具有以下安全選項之一：`receive.denyCurrentBranch`（用于推送到已檢出的分支），`receive.denyNonFastForwards`（用于強制非快進更新）），`receive.denyDeletes`或`receive.denyDeleteCurrent`。見 [git-config [1]](https://git-scm.com/docs/git-config) 。 ``` remote failure ``` 遠程端沒有報告ref的成功更新，可能是因為遠程端的臨時錯誤，網絡連接中斷或其他瞬態錯誤。 ``` from ``` 被推送的本地引用的名稱減去其`refs/<type>/`前綴。在刪除的情況下，省略本地引用的名稱。 ``` to ``` 要更新的遠程引用的名稱減去其`refs/<type>/`前綴。 ``` reason ``` 一個人類可讀的解釋。在成功推送refs的情況下，不需要解釋。對于失敗的ref，描述了失敗的原因。 ## 關于快速前進的說明當更新更改一個分支（或更多，一般來說，一個ref），它曾經指向提交A，當指向另一個提交B時，當且僅當B是A的后代時，它才被稱為快進更新。在從A到B的快速更新中，原始提交A構建在其上的提交集是新提交B構建在其上的提交的子集。因此，它不會失去任何歷史。相反，非快進更新將丟失歷史記錄。例如，假設您和其他人在同一個提交X中啟動，并且您構建了一個導致提交B的歷史記錄，而另一個人構建了一個導致提交A的歷史記錄。歷史記錄如下所示： ``` B / ---X---A ``` 進一步假設另一個人已經將更改導致A返回到原始存儲庫，您從中獲得了原始提交X. 由另一個人完成的推送更新了用于指向提交X的分支以指向提交A.這是一個快進。但是如果你試圖推送，你將嘗試用提交B更新分支（現在指向A）。這樣做_而不是_快進。如果你這樣做，提交A引入的更改將會丟失，因為每個人現在都將開始在B之上構建。默認情況下，該命令不允許更新不是快進以防止此類歷史記錄丟失。如果您不想丟失您的工作（從X到B的歷史記錄）或其他人的工作（從X到A的歷史記錄），您需要先從存儲庫中獲取歷史記錄，創建包含已完成更改的歷史記錄由雙方共同推動結果。你可以執行“git pull”，解決潛在的沖突，并“git push”結果。 “git pull”將在提交A和B之間創建合并提交C. ``` B---C / / ---X---A ``` 使用生成的合并提交更新A將快進并且您的推送將被接受。或者，您可以使用“git pull --rebase”在A之上重新定義X和B之間的更改，然后將結果推回。 rebase將創建一個新的提交D，它在A之上構建X和B之間的變化。 ``` B D / / ---X---A ``` 同樣，使用此提交更新A將快進并且您的推送將被接受。還有一種常見的情況是，當您嘗試推送時，您可能會遇到非快進拒絕，甚至當您進入存儲庫時，也有可能沒有其他人推進。在你自己推送提交A之后（在本節的第一張圖片中），將其替換為“git commit --amend”以生成提交B，并嘗試將其推出，因為忘記已經將A推出了。在這種情況下，并且只有當您確定沒有人同時獲取您之前的提交A（并開始在其上構建）時，您可以運行“git push --force”來覆蓋它。換句話說，“git push --force”是一種保留用于表示失去歷史記錄的情況的方法。 ## 例子 ``` git push ``` 像`git push <remote>`一樣工作，其中< remote>是當前分支的遠程（或`origin`，如果沒有為當前分支配置遠程）。 ``` git push origin ``` 如果沒有其他配置，則將當前分支推送到已配置的上游（`remote.origin.merge`配置變量），如果它與當前分支具有相同的名稱，則錯誤輸出而不推送。沒有< refspec>時此命令的默認行為給定可以通過設置遙控器的`push`選項或`push.default`配置變量來配置。例如，要默認僅將當前分支推送到`origin`，請使用`git config remote.origin.push HEAD`。任何有效的< refspec> （如下例中的那些）可以配置為`git push origin`的默認值。 ``` git push origin : ``` 將“匹配”分支推送到`origin`。見< refspec>在上面的 [OPTIONS](#OPTIONS) 部分中，對“匹配”分支進行了描述。 ``` git push origin master ``` 找到與源存儲庫中的`master`匹配的引用（很可能，它會找到`refs/heads/master`），并用它更新`origin`存儲庫中的相同引用（例如`refs/heads/master`）。如果遠程不存在`master`，則會創建它。 ``` git push origin HEAD ``` 一種將當前分支推送到遠程同名的便捷方法。 ``` git push mothership master:satellite/master dev:satellite/dev ``` 使用與`master`匹配的源ref（例如`refs/heads/master`）來更新`mothership`存儲庫中與`satellite/master`（最可能是`refs/remotes/satellite/master`）匹配的ref;為`dev`和`satellite/dev`做同樣的事情。有關匹配語義的討論，請參閱上面描述`<refspec>...`的部分。這是為了模擬在`mothership`上運行的`git fetch`在相反方向上運行`git push`，以便集成在`satellite`上完成的工作，當你只能以一種方式進行連接時，通常需要這樣做（即衛星可以進入母艦，但母艦無法啟動與衛星的連接，因為后者位于防火墻后面或不運行sshd）。在`satellite`機器上運行`git push`后，您將進入`mothership`并在那里運行`git merge`以完成在`mothership`上運行的`git pull`的仿真，以提取在`satellite`上進行的更改。 ``` git push origin HEAD:master ``` 將當前分支推送到`origin`存儲庫中與`master`匹配的遠程ref。此表單便于在不考慮其本地名稱的情況下推送當前分支。 ``` git push origin master:refs/heads/experimental ``` 通過復制當前`master`分支在`origin`存儲庫中創建分支`experimental`。僅當本地名稱和遠程名稱不同時，才需要此表單在遠程存儲庫中創建新分支或標記;否則，引用名稱本身就可以使用。 ``` git push origin :experimental ``` 找到與`origin`存儲庫中的`experimental`匹配的引用（例如`refs/heads/experimental`），并將其刪除。 ``` git push origin +dev:master ``` 使用dev分支更新原始存儲庫的主分支，允許非快進更新。 **這可以在原始存儲庫中懸掛未引用的提交。** 考慮以下情況：無法進行快進： ``` o---o---o---A---B origin/master \ X---Y---Z dev ``` 上面的命令會將原始存儲庫更改為 ``` A---B (unnamed branch) / o---o---o---X---Y---Z master ``` 提交A和B將不再屬于具有符號名稱的分支，因此將無法訪問。因此，這些提交將通過源存儲庫上的`git gc`命令刪除。 ## 安全提取和推送協議的目的不是為了防止一方竊取不打算共享的其他存儲庫中的數據。如果您需要保護私有數據免受惡意對等方的攻擊，那么最佳選擇是將其存儲在另一個存儲庫中。這適用于客戶端和服務器。特別是，服務器上的命名空間對讀訪問控制無效;您應該只將命名空間的讀訪問權授予您信任的客戶端，并具有對整個存儲庫的讀訪問權限。已知的攻擊向量如下： 1. 受害者發送“have”行，宣傳其擁有的對象的ID，這些對象并未明確地用于共享，但如果對等方也擁有它們，則可用于優化轉移。攻擊者選擇一個對象ID X來竊取并向X發送一個ref，但不需要發送X的內容，因為受害者已經擁有它。現在，受害者認為攻擊者擁有X，并且稍后會將X的內容發送回攻擊者。（這種攻擊對于客戶端在服務器上執行是最直接的，通過在客戶端有權訪問的命名空間中創建ref，然后獲取它。服務器在客戶端上執行它的最可能方式是“將“X”合并到一個公共分支中，并希望用戶在此分支上執行其他工作，并將其推送回服務器，而不會注意到合并。） 2. 與＃1一樣，攻擊者選擇一個對象ID X來竊取。受害者發送攻擊者已經擁有的對象Y，并且攻擊者錯誤地聲稱擁有X而不是Y，因此受害者將Y作為針對X的增量發送。該增量顯示X的區域與攻擊者的Y類似。 ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件