git-rebase · Git 中文參考

# git-rebase > 原文： [https://git-scm.com/docs/git-rebase](https://git-scm.com/docs/git-rebase) ## 名稱 git-rebase - 重新應用提交在另一個基本提示之上 ## 概要 ``` git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] [<upstream> [<branch>]] git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] --root [<branch>] git rebase --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch ``` ## 描述如果< branch>如果指定， _git rebase_ 將在執行任何其他操作之前執行自動`git checkout <branch>`。否則它仍然在當前分支上。如果< upstream>未指定，上游在分支中配置。< name> .remote和branch。將使用< name> .merge選項（詳見 [git-config [1]](https://git-scm.com/docs/git-config) ）和`--fork-point`假設選項。如果您當前不在任何分支上，或者當前分支沒有配置上游，則rebase將中止。由當前分支中的提交進行的所有更改，但不在< upstream>中。被保存到臨時區域。這是`git log <upstream>..HEAD`顯示的同一組提交;或`git log 'fork_point'..HEAD`，如果`--fork-point`有效（參見下面`--fork-point`的說明）;如果指定了`--root`選項，則按`git log HEAD`。當前分支重置為< upstream>或< newbase>如果提供了--onto選項。這與`git reset --hard <upstream>`（或< newbase>）具有完全相同的效果。 ORIG_HEAD設置為在重置之前指向分支的尖端。之前保存到臨時區域的提交將按順序逐個重新應用于當前分支。請注意，HEAD中的任何提交都會引入與HEAD中的提交相同的文本更改。< upstream>被省略（即，將跳過已經在上游接受的具有不同提交消息或時間戳的補丁）。合并失敗可能會阻止此過程完全自動化。您必須解決任何此類合并失敗并運行`git rebase --continue`。另一種選擇是繞過導致合并失敗的提交`git rebase --skip`。要查看原始<分支>并刪除.git / rebase-apply工作文件，改為使用命令`git rebase --abort`。假設存在以下歷史記錄，并且當前分支是“主題”： ``` A---B---C topic / D---E---F---G master ``` 從這一點來看，以下任一命令的結果： ``` git rebase master git rebase master topic ``` 將會： ``` A'--B'--C' topic / D---E---F---G master ``` **注意：**后一種形式只是`git checkout topic`的簡寫，后跟`git rebase master`。當rebase退出`topic`時，將保留簽出分支。如果上游分支已經包含您所做的更改（例如，因為您郵寄了上游應用的補丁），那么將跳過該提交。例如，在以下歷史記錄中運行`git rebase master`（其中`A'`和`A`引入相同的更改集，但具有不同的提交者信息）： ``` A---B---C topic / D---E---A'---F master ``` 將導致： ``` B'---C' topic / D---E---A'---F master ``` 以下是如何將基于一個分支的主題分支移植到另一個分支，假設您使用`rebase --onto`從后一分支分叉主題分支。首先讓我們假設您的_主題_基于分支_下一個_。例如，_主題_中開發的功能取決于_下一個_中的某些功能。 ``` o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic ``` 我們想從分支 _master_ 分叉_主題_;例如，因為_主題_所依賴的功能被合并到更穩定的_主_分支中。我們希望我們的樹看起來像這樣： ``` o---o---o---o---o master | \ | o'--o'--o' topic \ o---o---o---o---o next ``` 我們可以使用以下命令獲取此信息： ``` git rebase --onto master next topic ``` --onto選項的另一個例子是重新定義分支的一部分。如果我們有以下情況： ``` H---I---J topicB / E---F---G topicA / A---B---C---D master ``` 那么命令 ``` git rebase --onto master topicA topicB ``` 會導致： ``` H'--I'--J' topicB / | E---F---G topicA |/ A---B---C---D master ``` 當topicB不依賴于topicA時，這很有用。也可以使用rebase刪除一系列提交。如果我們有以下情況： ``` E---F---G---H---I---J topicA ``` 那么命令 ``` git rebase --onto topicA~5 topicA~3 topicA ``` 會導致刪除提交F和G： ``` E---H'---I'---J' topicA ``` 如果F和G在某種程度上存在缺陷，或者不應該成為topicA的一部分，那么這很有用。注意 - -onto和< upstream>的參數。參數可以是任何有效的commit-ish。如果發生沖突， _git rebase_ 將在第一個有問題的提交時停止，并在樹中留下沖突標記。您可以使用 _git diff_ 來定位標記（<<<<<<<<<<<<<<<<<<<<<<<<對于您編輯的每個文件，您需要告訴Git沖突已經解決，通常可以這樣做 ``` git add <filename> ``` 手動解決沖突并使用所需的分辨率更新索引后，您可以繼續使用 ``` git rebase --continue ``` 或者，您可以撤消 _git rebase_ ``` git rebase --abort ``` ## 組態 ``` rebase.useBuiltin ``` 設置為`false`以使用 [git-rebase [1]](https://git-scm.com/docs/git-rebase) 的舊版shellcript實現。默認情況下是`true`，這意味著在C中使用內置的重寫。 C重寫首先包含在Git版本2.20中。如果在重寫中發現任何錯誤，此選項可用于重新啟用舊版本。此選項和 [git-rebase [1]](https://git-scm.com/docs/git-rebase) 的shellscript版本將在以后的某個版本中刪除。如果您發現某些理由將此選項設置為`false`而非一次性測試，則應將行為差異報告為git中的錯誤。 ``` rebase.stat ``` 是否顯示自上次rebase以來上游改變的差異。默認為False。 ``` rebase.autoSquash ``` 如果設置為true，則默認啟用`--autosquash`選項。 ``` rebase.autoStash ``` 設置為true時，在操作開始之前自動創建臨時存儲條目，并在操作結束后應用它。這意味著您可以在臟工作樹上運行rebase。但是，謹慎使用：成功重組后的最終存儲應用程序可能會導致非平凡的沖突。 [git-rebase [1]](https://git-scm.com/docs/git-rebase) 的`--no-autostash`和`--autostash`選項可以覆蓋此選項。默認為false。 ``` rebase.missingCommitsCheck ``` 如果設置為“warn”，git rebase -i將在刪除某些提交時打印警告（例如刪除了一行），但是rebase仍將繼續。如果設置為“error”，它將打印上一個警告并停止rebase，然后可以使用 _git rebase --edit-todo_ 來糾正錯誤。如果設置為“忽略”，則不進行檢查。要在沒有警告或錯誤的情況下刪除提交，請使用待辦事項列表中的`drop`命令。默認為“忽略”。 ``` rebase.instructionFormat ``` [git-log [1]](https://git-scm.com/docs/git-log) 中指定的格式字符串，用于交互式rebase期間的待辦事項列表。格式將自動在格式之前添加長提交哈希。 ``` rebase.abbreviateCommands ``` 如果設置為true，`git rebase`將在待辦事項列表中使用縮寫的命令名稱，結果如下： ``` p deadbee The oneline of the commit p fa1afe1 The oneline of the next commit ... ``` 代替： ``` pick deadbee The oneline of the commit pick fa1afe1 The oneline of the next commit ... ``` 默認為false。 ``` rebase.rescheduleFailedExec ``` 自動重新安排失敗的`exec`命令。這僅在交互模式下（或提供`--exec`選項時）才有意義。這與指定`--reschedule-failed-exec`選項相同。 ## OPTIONS ``` --onto <newbase> ``` 創建新提交的起點。如果未指定--onto選項，則起點為< upstream>。可以是任何有效的提交，而不僅僅是現有的分支名稱。作為特殊情況，如果只有一個合并庫，則可以使用“A ... B”作為A和B的合并基礎的快捷方式。您最多可以省略A和B中的一個，在這種情況下，它默認為HEAD。 ``` <upstream> ``` 上游分支進行比較。可以是任何有效的提交，而不僅僅是現有的分支名稱。默認為當前分支的已配置上游。 ``` <branch> ``` 工作分支;默認為HEAD。 ``` --continue ``` 解決合并沖突后重新啟動重定位過程。 ``` --abort ``` 中止rebase操作并將HEAD重置為原始分支。如果< branch>在rebase操作開始時提供，然后HEAD將重置為< branch>。否則，HEAD將重置為啟動rebase操作時的位置。 ``` --quit ``` 中止rebase操作但HEAD不會重置回原始分支。結果，索引和工作樹也保持不變。 ``` --keep-empty ``` 在結果中保留不改變其父項的任何提交。另見下面的不兼容的選項。 ``` --allow-empty-message ``` 默認情況下，使用空消息進行的rebasing提交將失敗。此選項會覆蓋該行為，允許對具有空消息的提交進行重新定位。另見下面的不兼容的選項。 ``` --skip ``` 跳過當前修補程序重新啟動重定位過程。 ``` --edit-todo ``` 在交互式rebase期間編輯待辦事項列表。 ``` --show-current-patch ``` 在交互式rebase中顯示當前補丁，或者由于沖突而停止rebase。這相當于`git show REBASE_HEAD`。 ``` -m ``` ``` --merge ``` 使用合并策略進行rebase。當使用遞歸（默認）合并策略時，這允許rebase知道上游側的重命名。請注意，通過從< upstream>頂部的工作分支重放每個提交來進行rebase合并。科。因此，當合并沖突發生時，報告為_我們的_的那一方是迄今為止重新命名的系列，從< upstream>開始，而_他們的_是工作分支。換句話說，雙方交換。另見下面的不兼容的選項。 ``` -s <strategy> ``` ``` --strategy=<strategy> ``` 使用給定的合并策略。如果沒有`-s`選項_，則使用git merge-recursive_ 。這意味著--merge。因為 _git rebase_ 重放來自< upstream>頂部的工作分支的每個提交。使用給定策略的分支，使用_我們的_策略簡單地清空< branch>中的所有補丁，這沒有多大意義。另見下面的不兼容的選項。 ``` -X <strategy-option> ``` ``` --strategy-option=<strategy-option> ``` 通過< strategy-option>通過合并策略。這意味著`--merge`，如果沒有指定策略，則`-s recursive`。注意_我們的_和的逆轉，如上所述`-m`選項。另見下面的不兼容的選項。 ``` -S[<keyid>] ``` ``` --gpg-sign[=<keyid>] ``` GPG簽名提交。 `keyid`參數是可選的，默認為提交者標識;如果指定，它必須粘在沒有空格的選項上。 ``` -q ``` ``` --quiet ``` 安靜。意味著--no-stat。 ``` -v ``` ``` --verbose ``` 要冗長。意味著 - 停止。 ``` --stat ``` 顯示自上次rebase以來上游更改的差異。 diffstat也由配置選項rebase.stat控制。 ``` -n ``` ``` --no-stat ``` 不要將diffstat顯示為rebase過程的一部分。 ``` --no-verify ``` 此選項繞過pre-rebase掛鉤。另見 [githooks [5]](https://git-scm.com/docs/githooks) 。 ``` --verify ``` 允許運行pre-rebase掛鉤，這是默認值。此選項可用于覆蓋--no-verify。另見 [githooks [5]](https://git-scm.com/docs/githooks) 。 ``` -C<n> ``` 確保至少< n>周圍環境的線在每次更改之前和之后匹配。當存在較少的周圍環境線時，它們都必須匹配。默認情況下，不會忽略任何上下文。另見下面的不兼容的選項。 ``` --no-ff ``` ``` --force-rebase ``` ``` -f ``` 單獨重放所有重新提交的提交，而不是快速轉發未更改的提交。這可以確保重新分支的整個歷史記錄由新提交組成。在恢復主題分支合并之后，您可能會發現這很有用，因為此選項使用新提交重新創建主題分支，因此可以成功重新合并而無需“恢復恢復”（請參閱?? [revert-a-faulty-merge如何 - 詳情請](howto/revert-a-faulty-merge.html)）。 ``` --fork-point ``` ``` --no-fork-point ``` 使用reflog在< upstream>之間找到更好的共同祖先。和< branch>在計算由< branch>引入的提交時。當--fork-point激活時，將使用 _fork_point_ 代替< upstream>計算rebase的提交集，其中 _fork_point_ 是`git merge-base --fork-point <upstream> <branch>`命令的結果（參見 [git-merge-base [1]](https://git-scm.com/docs/git-merge-base) ）。如果 _fork_point_ 最終為空，則< upstream>將被用作后備。如果是< upstream>或--root在命令行中給出，則默認為`--no-fork-point`，否則默認為`--fork-point`。 ``` --ignore-whitespace ``` ``` --whitespace=<option> ``` 這些標志被傳遞給應用補丁的 _git apply_ 程序（參見 [git-apply [1]](https://git-scm.com/docs/git-apply) ）。另見下面的不兼容的選項。 ``` --committer-date-is-author-date ``` ``` --ignore-date ``` 這些標志傳遞給 _git am_ 以輕松更改重新提交的提交日期（參見 [git-am [1]](https://git-scm.com/docs/git-am) ）。另見下面的不兼容的選項。 ``` --signoff ``` 添加Signed-off-by：預告片到所有重新提交的提交。請注意，如果給出了`--interactive`，那么只有標記為要挑選，編輯或重新編號的提交才會添加預告片。另見下面的不兼容的選項。 ``` -i ``` ``` --interactive ``` 列出即將重新定位的提交。讓用戶在變基之前編輯該列表。此模式也可用于拆分提交（請參閱下面的SPLITTING COMMITS）。可以通過設置配置選項rebase.instructionFormat來更改提交列表格式。自定義指令格式將自動將長提交哈希添加到格式之前。另見下面的不兼容的選項。 ``` -r ``` ``` --rebase-merges[=(rebase-cousins|no-rebase-cousins)] ``` 默認情況下，rebase將簡單地從todo列表中刪除合并提交，并將重新提交的提交放入單個線性分支中。使用`--rebase-merges`，rebase將通過重新創建合并提交來嘗試保留要重新提交的提交中的分支結構。必須手動解決/重新應用這些合并提交中的任何已解決的合并沖突或手動修改。默認情況下，或者當指定`no-rebase-cousins`時，沒有`<upstream>`作為直接祖先的提交將保留其原始分支點，即git [1](git-log) 的`--ancestry-path`選項將被排除的提交默認情況下會保留原始血統。如果打開`rebase-cousins`模式，則此類提交將改為`<upstream>`（或`<onto>`，如果指定）。 `--rebase-merges`模式在精神上與`--preserve-merges`類似，但與此選項相反，在交互式rebase中效果很好：可以隨意重新排序，插入和刪除提交。目前只能使用`recursive`合并策略重新創建合并提交;只能通過顯式`exec git merge -s <strategy> [...]`命令使用不同的合并策略。另請參見下面的“重新合并和不兼容的選項”。 ``` -p ``` ``` --preserve-merges ``` 通過重放合并提交引入的提交來重新創建合并提交，而不是展平歷史記錄。不保留合并沖突解決方案或手動修改合并提交。這在內部使用`--interactive`機器，但明確地將它與`--interactive`選項結合使用通常不是一個好主意，除非你知道你在做什么（參見下面的BUGS）。另見下面的不兼容的選項。 ``` -x <cmd> ``` ``` --exec <cmd> ``` 附加“exec< cmd>”在每行創建最終歷史記錄中的提交之后。 < CMD>將被解釋為一個或多個shell命令。任何失敗的命令都會中斷rebase，退出代碼為1。您可以通過使用`--exec`的一個實例和幾個命令來執行多個命令： ``` git rebase -i --exec "cmd1 && cmd2 && ..." ``` 或者通過提供多個`--exec`： ``` git rebase -i --exec "cmd1" --exec "cmd2" --exec ... ``` 如果使用`--autosquash`，則不會為中間提交附加“exec”行，并且只會出現在每個squash / fixup系列的末尾。這在內部使用`--interactive`機器，但可以在沒有顯式`--interactive`的情況下運行。另見下面的不兼容的選項。 ``` --root ``` 重新引用從< branch>可到達的所有提交，而不是用< upstream>來限制它們。這允許您在樹枝上重新定義根提交。與--onto一起使用時，它將跳過< newbase>中已包含的更改（而不是< upstream>）而沒有--onto它將在每次變化時運行。當與--onto和--preserve-merges一起使用時，_所有_根提交將被重寫為< newbase>作為父母代替。另見下面的不兼容的選項。 ``` --autosquash ``` ``` --no-autosquash ``` 當提交日志消息以“squash！...”（或“fixup！...”）開頭，并且todo列表中已經存在與相同`...`匹配的提交時，自動修改rebase -i的待辦事項列表因此，標記為壓縮的提交在修改提交之后立即生效，并將移動的提交的操作從`pick`更改為`squash`（或`fixup`）。如果提交主題匹配，或者`...`引用提交的哈希，則提交與`...`匹配。作為后備，提交主題的部分匹配也起作用。創建fixup / squash提交的推薦方法是使用 [git-commit [1]](https://git-scm.com/docs/git-commit) 的`--fixup` / `--squash`選項。如果使用配置變量`rebase.autoSquash`默認啟用`--autosquash`選項，則此選項可用于覆蓋和禁用此設置。另見下面的不兼容的選項。 ``` --autostash ``` ``` --no-autostash ``` 在操作開始之前自動創建臨時存儲條目，并在操作結束后應用它。這意味著您可以在臟工作樹上運行rebase。但是，謹慎使用：成功重組后的最終存儲應用程序可能會導致非平凡的沖突。 ``` --reschedule-failed-exec ``` ``` --no-reschedule-failed-exec ``` 自動重新安排失敗的`exec`命令。這僅在交互模式下（或提供`--exec`選項時）才有意義。 ## 不兼容的選擇以下選項： * --committer-日期是執筆者最新 * - 忽略日期 * --whitespace * - 忽略空白 * -C 與以下選項不兼容： * - 合并 * - 戰略 * --strategy選項 * --allow空消息 * - [無糖] autosquash * --rebase，合并 * --preserve-合并 * - 互動 * --exec * --keep空 * --edit-待辦事項 * - 與--onto組合使用時此外，以下兩對選項不兼容： * --preserve-merges和--interactive * --preserve-merges和--signoff * --preserve-merges和--rebase-merges * --rebase-merges和--strategy * --rebase-merges和--strategy-option ## 行為差異后端的行為有一些微妙的差異。 ### 空提交無論提交是否為空（沒有相對于其父開始的更改）或結束為空（所有更改已在其他提交中上游應用），am后端將丟棄任何“空”提交。默認情況下，交互式后端會丟棄提交，該提交開始為空，如果命中達到空的提交，則會暫停。交互式后端存在`--keep-empty`選項，允許它保持空的提交。 ### 目錄重命名檢測在合并和交互式后端中啟用了目錄重命名啟發式掃描。由于缺少準確的樹信息，在后端禁用目錄重命名檢測。 ## 合并戰略合并機制（`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 rebase_ 的含義。另請參閱下面的從上游回收中恢復。當運行git-rebase命令時，它將首先執行“pre-rebase”掛鉤（如果存在）。您可以使用此掛鉤進行健全性檢查，如果不合適則拒絕該掛鉤。有關示例，請參閱模板pre-rebase hook腳本。完成后，< branch>將是現在的分支。 ## 交互模式以交互方式重新綁定意味著您有機會編輯已重新生成的提交。您可以重新排序提交，并可以刪除它們（清除壞的或其他不需要的補丁）。交互模式適用于此類工作流程： 1. 有個好主意 2. 破解代碼 3. 準備一系列提交 4. 提交其中第2點由幾個實例組成 a）經常使用 1. 完成值得承諾的事情 2. 承諾 b）獨立修正 1. 意識到某些東西不起作用 2. 修復它 3. 提交它有時在b.2中修復了這個問題。不能修改為它修復的不太完美的提交，因為該提交深深埋藏在補丁系列中。這正是交互式rebase的用途：在大量的“a”和“b”之后使用它，通過重新排列和編輯提交，并將多個提交壓縮成一個。使用您要保留的最后一次提交啟動它： ``` git rebase -i <after-this-commit> ``` 編輯器將被激活當前分支中的所有提交（忽略合并提交），這些提交在給定的提交之后。您可以將此列表中的提交重新排序到您的內容，然后您可以刪除它們。該列表看起來或多或少像這樣： ``` pick deadbee The oneline of this commit pick fa1afe1 The oneline of the next commit ... ``` 在線描述純粹是為了您的樂趣; _git rebase_ 不會查看它們但是在提交名稱（本例中為“deadbee”和“fa1afe1”），所以不要刪除或編輯名稱。通過使用命令“edit”替換命令“pick”，您可以告訴 _git rebase_ 在應用該提交后停止，以便您可以編輯文件和/或提交消息，修改提交，并繼續變基。要中斷rebase（就像“編輯”命令一樣，但不首先選擇任何提交），使用“break”命令。如果您只想編輯提交的提交消息，請使用命令“reword”替換命令“pick”。要刪除提交，請將命令“pick”替換為“drop”，或者只刪除匹配的行。如果要將兩個或多個提交折疊成一個，請使用“squash”或“fixup”替換第二個和后續提交的命令“pick”。如果提交具有不同的作者，則折疊的提交將歸因于第一次提交的作者。折疊提交的建議提交消息是第一次提交的提交消息和具有“squash”命令的提交消息的串聯，但是省略了使用“fixup”命令提交的提交消息。 _git rebase_ 將在“pick”替換為“edit”或命令由于合并錯誤而失敗時停止。完成編輯和/或解決沖突后，您可以繼續`git rebase --continue`。例如，如果要重新排序最后5次提交，那么HEAD~4的內容將成為新的HEAD。要實現這一點，你可以像這樣調用 _git rebase_ ： ``` $ git rebase -i HEAD~5 ``` 并將第一個補丁移動到列表的末尾。如果您有這樣的歷史記錄，您可能希望保留合并： ``` X \ A---M---B / ---o---O---P---Q ``` 假設您要將從“A”開始到“Q”的側分支重新綁定。確保當前HEAD為“B”，然后調用 ``` $ git rebase -i -p --onto Q O ``` 重新排序和編輯提交通常會創建未經測試的中間步驟。您可能希望通過運行測試來檢查歷史編輯沒有破壞任何內容，或者至少使用“exec”命令（快捷鍵“x”）在歷史記錄的中間點重新編譯。您可以通過創建像這樣的待辦事項列表來實現： ``` pick deadbee Implement feature XXX fixup f1a5c00 Fix to feature XXX exec make pick c0ffeee The oneline of the next commit edit deadbab The oneline of the commit after exec cd subdir; make test ... ``` 當命令失敗時（即退出非0狀態），交互式rebase將停止，以便您有機會解決問題。您可以繼續`git rebase --continue`。 “exec”命令在shell中啟動命令（在`$SHELL`中指定的命令，或者如果未設置`$SHELL`則在默認shell中啟動），因此您可以使用shell功能（如“cd”，“>”， “;”......）。該命令從工作樹的根目錄運行。 ``` $ git rebase -i --exec "make test" ``` 此命令允許您檢查中間提交是否可編譯。待辦事項清單變得像這樣： ``` pick 5928aea one exec make test pick 04d0fda two exec make test pick ba46169 three exec make test pick f4593f9 four exec make test ``` ## 分裂委員會在交互模式下，您可以使用“編輯”操作標記提交。但是，這并不一定意味著 _git rebase_ 希望此編輯的結果恰好是一次提交。實際上，您可以撤消提交，也可以添加其他提交。這可以用于將提交拆分為兩個： * 使用`git rebase -i <commit>^`啟動交互式rebase，其中< commit>是您要拆分的提交。實際上，只要包含該提交，任何提交范圍都可以。 * 使用“編輯”操作標記要拆分的提交。 * 編輯提交時，執行`git reset HEAD^`。結果是HEAD被一個重繞，索引也隨之而來。但是，工作樹保持不變。 * 現在將更改添加到您希望在第一次提交中擁有的索引。您可以使用`git add`（可能是交互式）或 _git gui_ （或兩者）來做到這一點。 * 使用現在適當的提交消息提交now-current索引。 * 重復最后兩步，直到工作樹干凈。 * 使用`git rebase --continue`繼續變基。如果您不完全確定中間修訂版是否一致（它們是編譯的，通過測試套件等），您應該使用 _git stash_ 來隱藏每次提交，測試后尚未提交的更改，如果需要修復，則修改提交。 ## 從UPSTREAM REBASE恢復重新定位（或任何其他形式的重寫）其他人基于其工作的分支是一個壞主意：它下游的任何人都被迫手動修復其歷史記錄。本節介紹如何從下游的角度進行修復。然而，真正的解決方法是首先避免重新定位上游。為了說明，假設您處于某人開發_子系統_分支的情況，并且您正在處理依賴于此_子系統_的_主題_。您最終可能會得到如下歷史記錄： ``` o---o---o---o---o---o---o---o master \ o---o---o---o---o subsystem \ *---*---* topic ``` 如果_子系統_針對 _master_ 進行了重新設置，則會發生以下情況： ``` o---o---o---o---o---o---o---o master \ \ o---o---o---o---o o'--o'--o'--o'--o' subsystem \ *---*---* topic ``` 如果你現在像往常一樣繼續開發，并最終將_主題_合并到_子系統_，那么來自_子系統_的提交將永遠保持重復： ``` o---o---o---o---o---o---o---o master \ \ o---o---o---o---o o'--o'--o'--o'--o'--M subsystem \ / *---*---*-..........-*--* topic ``` 這樣的副本通常是不受歡迎的，因為它們使歷史變得混亂，使得更難以遵循。為了清理，您需要將_主題_上的提交移植到新的_子系統_提示，即rebase _主題_。這會產生漣漪效應：_主題_下游的任何人也被迫改變，依此類推！有兩種修復方法，將在以下小節中討論： ``` Easy case: The changes are literally the same. ``` 如果_子系統_ rebase是一個簡單的rebase并且沒有沖突，就會發生這種情況。 ``` Hard case: The changes are not the same. ``` 如果_子系統_ rebase發生沖突，或使用`--interactive`省略，編輯，壓縮或修復提交，則會發生這種情況;或者如果上游使用`commit --amend`，`reset`或`filter-branch`中的一個。 ### 容易的情況僅在_子系統_上的更改（基于差異內容的修補程序ID）在rebase _子系統_之前和之后的字面上相同時才有效。在這種情況下，修復很容易，因為 _git rebase_ 知道跳過已經存在于新上游的更改。所以，如果你說（假設你在_話題_） ``` $ git rebase subsystem ``` 你將最終得到固定的歷史 ``` o---o---o---o---o---o---o---o master \ o'--o'--o'--o'--o' subsystem \ *---*---* topic ``` ### 艱難的案例如果_子系統_更改與rebase之前的更改不完全相符，事情會變得更復雜。 | 注意 | 雖然即使在困難的情況下，“簡單案件恢復”有時似乎也是成功的，但它可能會產生意想不到的后果。例如，通過`git rebase --interactive`刪除的提交將**復活**！ | 我的想法是手動告訴 _git rebase_ “舊的_子系統_結束，你的_主題_開始了”，也就是說，他們之間的舊合并基礎是什么。您必須找到一種方法來命名舊_子系統_的最后一次提交，例如： * 使用_子系統_ reflog：在 _git fetch_ 之后，_子系統_的舊提示位于`subsystem@{1}`。隨后的提取將增加數量。（參見 [git-reflog [1]](https://git-scm.com/docs/git-reflog) 。） * 相對于_主題_的提示：知道你的_主題_有三次提交，_子系統_的舊提示必須是`topic~3`。然后，您可以通過說（對于reflog案例，假設您已經在_主題_上）將舊的`subsystem..topic`移植到新的提示： ``` $ git rebase --onto subsystem subsystem@{1} ``` “硬案例”恢復的連鎖反應特別糟糕： __主題_下游的所有人_現在也必須執行“硬案例”恢復！ ## 重新合并交互式rebase命令最初設計用于處理單個補丁系列。因此，從todo列表中排除合并提交是有意義的，因為開發人員可能在處理分支時合并當時的`master`，只是最終將所有提交重新綁定到`master`上（跳過合并提交））。但是，開發人員可能想要重新創建合并提交的正當理由是：在處理多個相互關聯的分支時保留分支結構（或“提交拓撲”）。在下面的示例中，開發人員處理主題分支，該分支重構按鈕的定義方式，以及使用該重構實現“報告錯誤”按鈕的另一個主題分支。 `git log --graph --format=%s -5`的輸出可能如下所示： ``` * Merge branch 'report-a-bug' |\ | * Add the feedback button * | Merge branch 'refactor-button' |\ \ | |/ | * Use the Button class for all buttons | * Extract a generic Button class from the DownloadButton one ``` 開發人員可能希望在保留分支拓撲的同時將這些提交重新綁定到較新的`master`，例如，當第一個主題分支預期比第二個主題分支更早地集成到`master`中時，比如解決與更改為使其成為`master`的DownloadButton類。可以使用`--rebase-merges`選項執行此rebase。它將生成一個如下所示的待辦事項列表： ``` label onto # Branch: refactor-button reset onto pick 123456 Extract a generic Button class from the DownloadButton one pick 654321 Use the Button class for all buttons label refactor-button # Branch: report-a-bug reset refactor-button # Use the Button class for all buttons pick abcdef Add the feedback button label report-a-bug reset onto merge -C a1b2c3 refactor-button # Merge 'refactor-button' merge -C 6f5e4d report-a-bug # Merge 'report-a-bug' ``` 與常規交互式rebase相比，除`pick`之外還有`label`，`reset`和`merge`命令。執行該命令時，`label`命令將標簽與當前HEAD相關聯。這些標簽創建為worktree-local refs（`refs/rewritten/<label>`），將在rebase完成時刪除。這樣，鏈接到同一存儲庫的多個工作樹中的rebase操作不會相互干擾。如果`label`命令失敗，則立即重新安排，并提供有用的消息如何繼續。 `reset`命令將HEAD，索引和工作樹重置為指定的修訂版。它類似于`exec git reset --hard <label>`，但拒絕覆蓋未跟蹤的文件。如果`reset`命令失敗，則會立即重新安排，并提供一條有用的消息，說明如何編輯待辦事項列表（這通常在手動將`reset`命令插入待辦事項列表并包含拼寫錯誤時發生）。 `merge`命令會將指定的修訂版合并到當時的HEAD中。使用`-C <original-commit>`，將使用指定合并提交的提交消息。當`-C`更改為小寫`-c`時，成功合并后將在編輯器中打開該消息，以便用戶可以編輯該消息。如果`merge`命令因合并沖突以外的任何原因而失敗（即合并操作甚至沒有開始），則立即重新安排。此時，`merge`命令將**始終**使用`recursive`合并策略進行常規合并，而`octopus`用于章魚合并，無法選擇不同的合并策略。要解決這個問題，可以使用`exec`命令顯式調用`git merge`，使用標簽是worktree-local refs的事實（例如，ref `refs/rewritten/onto`將對應于標簽`onto`）。注意：第一個命令（`label onto`）標記提交重新定位的修訂版本;名稱`onto`只是一個約定，作為`--onto`選項的點頭。也可以通過添加`merge <merge-head>`形式的命令從頭開始引入全新的合并提交。此表單將生成暫定的提交消息，并始終打開編輯器以允許用戶編輯它。這可能是有用的，例如當一個主題分支最終解決一個以上的問題，并希望分成兩個甚至更多的主題分支。考慮這個待辦事項列表： ``` pick 192837 Switch from GNU Makefiles to CMake pick 5a6c7e Document the switch to CMake pick 918273 Fix detection of OpenSSL in CMake pick afbecd http: add support for TLS v1.3 pick fdbaec Fix detection of cURL in CMake on Windows ``` 此列表中與CMake無關的一個提交很可能是通過修復切換到CMake引入的所有錯誤來實現的，但它解決了一個不同的問題。要將此分支拆分為兩個主題分支，可以像下面這樣編輯待辦事項列表： ``` label onto pick afbecd http: add support for TLS v1.3 label tlsv1.3 reset onto pick 192837 Switch from GNU Makefiles to CMake pick 918273 Fix detection of OpenSSL in CMake pick fdbaec Fix detection of cURL in CMake on Windows pick 5a6c7e Document the switch to CMake label cmake reset onto merge tlsv1.3 merge cmake ``` ## BUGS `--preserve-merges --interactive`提供的待辦事項列表不代表修訂圖的拓撲結構。編輯提交和重寫他們的提交消息應該可以正常工作，但嘗試重新提交提交往往會產生違反直覺的結果。在這種情況下使用`--rebase-merges`。例如，嘗試重新排列 ``` 1 --- 2 --- 3 --- 4 --- 5 ``` 至 ``` 1 --- 2 --- 4 --- 3 --- 5 ``` 通過移動“選擇4”線將導致以下歷史記錄： ``` 3 / 1 --- 2 --- 4 --- 5 ``` ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件