?
This document uses PHP Chinese website manual Release
命名
git-rebase - 重新申請?zhí)峤涣硪粋€基本技巧
概要
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
描述
如果指定 <branch> ，git rebase則在執(zhí)行其他任何操作之前將執(zhí)行自動操作git checkout <branch>。否則它將保留在當前分支上。
如果未指定 <upstream> ，則將使用在分支。<name> .remote和分支。<name> .merge 選項中配置的上游（有關詳細信息，請參閱 git-config [1]），且--fork-point假定該選項。如果您當前沒有在任何分支上，或者當前分支沒有配置上游，那么 rebase 會中止。
所有由當前分支提交但不在 <upstream> 中的更改都保存到臨時區(qū)域。這與將要顯示的一組提交相同git log <upstream>..HEAD; 或者通過git log 'fork_point'..HEAD，如果--fork-point處于活動狀態(tài)（請參閱--fork-point下面的說明）; 或者，如果--root指定了選項，則git log HEAD。
如果提供了 --onto 選項，則當前分支將重置為 <upstream> 或 <newbase> 。這與git reset --hard <upstream>（或<newbase>）具有完全相同的效果。ORIG_HEAD 被設置為在復位之前指向分支的尖端。
之前保存到臨時區(qū)域的提交按順序依次重新應用到當前分支。請注意，HEAD 中提交的任何提交與 HEAD .. <upstream> 中的提交相同的文本更改均被省略（即，已經(jīng)接受上游提供不同提交消息或時間戳的補丁將被跳過）。
合并失敗可能會阻止此過程完全自動化。您將不得不解決任何此類合并失敗并運行git rebase --continue。另一種選擇是繞過導致合并失敗的提交git rebase --skip。要檢出原始 <branch> 并刪除 .git / rebase-apply 工作文件，請改用命令git rebase --abort。
假設存在以下歷史記錄，并且當前分支是“topic”：
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。退出topic分支時仍保留退出分支。
如果上游分支已經(jīng)包含您所做的更改（例如，因為您郵寄了上游應用的補?。瑒t該提交將被跳過。例如，運行git rebase master以下歷史記錄（其中A'并A引入相同的一組更改，但具有不同的提交者信息）：
A---B---C topic / D---E---A'---F master
結果會是：
B'---C' topic / D---E---A'---F master
這里是如何將基于一個分支的主題分支移植到另一個分支，假裝你使用后者分支從后一分支分支的主題分支rebase --onto。
首先讓我們假設你topic是基于分支的next。例如，開發(fā)的功能topic取決于可以在其中找到的某些功能next。
o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic
我們想topic從分支中分出來master; 例如，因為topic依賴的功能被合并到更穩(wěn)定的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> 參數(shù)的參數(shù)可以是任何有效的 commit-ish 。
如果發(fā)生沖突，git rebase將停在第一個有問題的提交并在樹中留下沖突標記。您可以使用git diff找到標記（<<<<<<）并進行編輯以解決沖突。對于你編輯的每一個文件，你都需要告訴 Git 沖突已經(jīng)解決，通常這是可以完成的
git add <filename>
手動解決沖突并以所需的分辨率更新索引后，您可以繼續(xù)使用重新綁定過程
git rebase --continue
另外，您也可以撤消git rebase
git rebase --abort
組態(tài)
rebase.stat
是否顯示自上次變基期以來上游變化的差異。默認為 False 。
rebase.autoSquash
如果--autosquash默認設置為 true 啟用選項。
rebase.autoStash
如果--autostash默認設置為 true 啟用選項。
rebase.missingCommitsCheck
如果設置為 “warn” ，則在交互模式下打印有關移除提交的警告。如果設置為 “error” ，請打印警告并停止重設。如果設置為 “ignore” ，則不進行檢查。默認情況下 “ignore” 。
rebase.instructionFormat
自定義提交列表格式，用于重新--interactive綁定。
選項
--onto <newbase>
創(chuàng)建新提交的起點。如果沒有指定 --onto 選項，起點是 <upstream> ?？梢允侨魏斡行У奶峤?，而不僅僅是現(xiàn)有的分支名稱。
作為特例，如果只有一個合并基礎，則可以使用“A ... B”作為 A 和 B 合并基的快捷方式。您最多可以省略 A 和 B 中的一個，在這種情況下，它默認為 HEAD 。
<upstream>
上游分支進行比較?？梢允侨魏斡行У奶峤?，而不僅僅是現(xiàn)有的分支名稱。默認為當前分支的配置上游。
<branch>
工作分部; 默認為 HEAD 。
--continue
解決了合并沖突后重新啟動重新綁定過程。
--abort
中止 rebase 操作并將 HEAD 重置為原始分支。如果 <reb> 操作開始時提供 <branch> ，則 HEAD 將重置為 <branch> 。否則 HEAD 將重置為啟動 rebase 操作時的位置。
--quit
放棄 rebase 操作，但 HEAD 不會重置回原始分支。索引和工作樹也因此保持不變。
--keep-empty
在結果中保留不改變父項的任何提交。
--skip
通過跳過當前補丁重新啟動重新綁定過程。
--edit-todo
在交互式重新綁定期間編輯待辦事項列表。
-m --merge
使用合并策略來重新分配。當使用遞歸（默認）合并策略時，這允許 rebase 知道上游端的重命名。
請注意，通過在 <upstream> 分支頂部重播來自工作分支的每個提交，合并索引合并工作。正因為如此，當合并沖突發(fā)生時，該方報告的ours是迄今為止重新分類的系列，從 <upstream> 開始，并且theirs是工作分支。換句話說，雙方交換。
-s <strategy> --strategy=<strategy>
使用給定的合并策略。如果沒有-s選項git merge-recursive用來代替。這意味著 - 合并。
因為git rebase使用給定的策略，重播每個都會在 <upstream> 分支之上的工作分支提交，所以使用該ours策略只會丟棄 <branch> 中的所有修補程序，這沒有多大意義。
-X <strategy-option> --strategy-option=<strategy-option>
將 <strategy-option> 傳遞給合并策略。這意味著--merge，如果沒有明確說明戰(zhàn)略-s recursive。請注意該選項的逆轉ours和theirs上面所述-m。
-S<keyid> --gpg-sign=<keyid>
GPG 標志提交。該keyid參數(shù)是可選的，并且默認為提交者身份; 如果指定，它必須粘貼到選項沒有空格。
-q --quiet
be quiet。意味著 -- 無統(tǒng)計。
-v --verbose
詳細。意味著--要統(tǒng)計。
--stat
顯示自上次 rebase 以來上游變化的差異。diffstat 也由配置選項 rebase.stat 控制。
-n --no-stat
不要將 diffstat 顯示為 rebase 過程的一部分。
--no-verify
此選項繞過預先重新綁定鉤子。另見 githooks [5]。
--verify
允許預重貼掛鉤運行，這是默認設置。這個選項可以用來覆蓋--no-verify 。另見 githooks [5] 。
-C<n>
確保每次更改之前和之后至少有 <n> 行周圍環(huán)境匹配。當存在較少的周圍環(huán)境線時，它們都必須匹配。默認情況下，不會忽略上下文。
-f --force-rebase
即使當前分支是最新的，并且--force沒有做任何事情的命令也不會返回，強制重新分配。
你可能會發(fā)現(xiàn)這個（或者 --no-ff 帶有交互式底座）在恢復主題分支合并之后很有用，因為這個選項用新提交重新創(chuàng)建了主題分支，所以它可以在不需要“還原返回”的情況下成功地重新建立。在還原-A-錯誤的合并操作方法的詳細說明）。
--fork-point --no-fork-point
計算 <branch> 引入的提交時，使用 reflog 可以在 <upstream> 和 <branch> 之間找到更好的共同祖先。
當 --fork-point 被激活時，fork_point將被用來代替<upstream>來計算 rebase 的提交集合fork_point，git merge-base --fork-point <upstream> <branch>命令的結果在哪里（參見 git-merge-base [1]）。如果fork_point結果為空，<upstream> 將用作后備。
如果在命令行中給出了 <upstream> 或 --root ，則默認為--no-fork-point，否則為默認值--fork-point。
--ignore-whitespace --whitespace=<option>
這些標志被傳遞給git apply應用該補丁的程序（參見 git-apply [1]）。與 --interactive 選項不兼容。
--committer-date-is-author-date --ignore-date
這些標志被傳遞給git am輕松更改重定義的提交的日期（請參閱 git-am [1]）。與 --interactive 選項不兼容。
--signoff
這個標志被傳遞來git am簽署所有重新發(fā)布的提交（參見 git-am [1]）。與 --interactive 選項不兼容。
-i --interactive
列出將要重新分配的提交列表。讓用戶在重新綁定之前編輯該列表。該模式也可用于分割提交（請參閱下面的分割提交）。
提交列表格式可以通過設置配置選項 rebase.instructionFormat 進行更改。自定義的指令格式會自動將格式中的長提交哈希值作為前綴。
-p --preserve-merges
重新創(chuàng)建合并提交，而不是通過重播合并提交引入的提交來平坦化歷史。不保留合并沖突解決方案或手動修改合并提交。
這在--interactive內部使用機制，但--interactive明確地將其與選項結合通常不是一個好主意，除非您知道自己在做什么（請參閱下面的 BUGS ）。
-x <cmd> --exec <cmd>
在每行在最終歷史記錄中創(chuàng)建提交后附加 “exec <cmd>” 。<cmd> 將被解釋為一個或多個 shell 命令。
您可以通過使用幾個命令的一個實例來--exec執(zhí)行幾個命令：
git rebase -i --exec "cmd1 && cmd2 && ..."
或者通過給予多個--exec：
git rebase -i --exec "cmd1" --exec "cmd2" --exec ...
如果--autosquash使用，中間提交不會追加 “exec” 行，并且只會出現(xiàn)在 squash / fixup 系列的末尾。
這在--interactive內部使用機制，但它可以在沒有明確的情況下運行--interactive。
--root
重新規(guī)劃從 <branch> 可訪問的所有提交，而不是用 <upstream> 限制它們。這允許您重新分支分支上的根提交。當與 --onto 一起使用時，它將跳過已包含在 <newbase>（而不是 <upstream> ）中的更改，而不使用 - 將在每次更改時運行。當與 --onto 和 --preserve-merges 一起使用時，all根提交將被重寫為具有 <newbase> 作為父代。
--autosquash --no-autosquash
當提交日志消息以“squash！...”（或“fixup！...”）開始，并且存在一個標題以相同的開頭的提交時，自動修改 rebase -i 的待辦事項列表，以便提交標記為壓扁，在提交被修改后立即出現(xiàn)，并將移動的提交的操作從（或）pick改為。在第一次之后忽略隨后的“fixup！”或“squash！”，以防您提到之前的 fixup / squash 。squashfixupgit commit --fixup/--squash
該選項僅在使用該--interactive選項時有效。
如果該--autosquash選項默認情況下使用配置變量啟用rebase.autoSquash，則此選項可用于覆蓋和禁用此設置。
--autostash --no-autostash
在操作開始之前自動創(chuàng)建臨時存儲條目，并在操作結束后應用它。這意味著你可以在骯臟的工作樹上運行 rebase 。但是，謹慎使用：成功重新綁定后的最終隱藏應用程序可能會導致不平凡的沖突。
--no-ff
使用 -interactive ，cherry-pick 所有重新提交的提交，而不是對未更改的提交進行快速轉發(fā)。這確保了重新分支的整個歷史由新的提交組成。
Without --interactive ，這是 --force-rebase 的同義詞。
在恢復主題分支合并之后，您可能會發(fā)現(xiàn)這很有幫助，因為此選項重新創(chuàng)建了具有新提交的主題分支，因此可以在不需要“還原返回”的情況下成功重新分配（請參閱恢復 - 錯誤 - 合并的方法細節(jié)）。
合并策略
合并機制（git merge和git pull命令）允許merge strategies使用-s選項選擇后端。一些策略也可以采取他們自己的選擇，可以通過給git merge和/或git pull給出-X<option>參數(shù)來傳遞。
resolve
這只能使用3路合并算法來解析兩個頭（即當前分支和您從其中取出的另一個分支）。它試圖仔細檢測交叉融合歧義，并被認為通常是安全和快速的。
recursive
這只能使用3路合并算法來解析兩個頭。當有多個可用于3路合并的共同祖先時，它將創(chuàng)建共同祖先的合并樹并將其用作3路合并的參考樹。據(jù)報道，這會導致更少的合并沖突，而不會因從 Linux 2.6內核開發(fā)歷史記錄中進行的實際合并提交所做的測試而導致混淆。此外，這可以檢測并處理涉及重命名的合并。這是拉取或合并一個分支時的默認合并策略。
該recursive策略可以采取以下選擇：
ours
該選項強制沖突的 hunk 通過支持our版本自動解決。來自另一棵與我們不沖突的樹的變化反映到合并結果。對于二進制文件，整個內容都是從我們這邊拿來的。
這不應與ours合并策略混淆，合并策略甚至不會考慮其他樹包含的內容。它丟棄了其他樹的所有內容，聲明our歷史包含發(fā)生在其中的所有事情。
theirs
這是與ours相反的; 請注意，與此不同的ours是，沒有theirs融合策略來混淆這個合并選項。
patience
使用此選項，merge-recursive花費一點額外的時間來避免由于不重要的匹配行（例如，來自不同功能的括號）而導致的混淆。當要合并的分支瘋狂地分歧時使用它。另請參閱 git-diff [1] --patience。
diff-algorithm=patience|minimal|histogram|myers
告訴merge-recursive使用不同的差異算法，這可以幫助避免由于不重要的匹配行（例如不同功能的花括號）而發(fā)生誤合。另請參閱 git-diff [1] --diff-algorithm。
ignore-space-change ignore-all-space ignore-space-at-eol
為了三路合并的目的，將指定類型的空白的行對待不變?？瞻鬃兓c其他變化混合在一起不會被忽略。另見 GIT-DIFF [1] ，-b，-w和--ignore-space-at-eol。
如果
their版本只對一行引入空白變化，our則使用版本;如果
our版本引入空白變化，但their版本包含實質性更改，their則使用版本;否則，合并按照通常的方式進行。
renormalize
這將在解析三路合并時運行虛擬檢出和檢入文件的所有三個階段。此選項用于合并具有不同干凈過濾器或行結束標準化規(guī)則的分支時使用。有關詳細信息，請參閱 gitattributes [5]中的“合并不同簽入/簽出屬性的分支”。
no-renormalize
禁用該renormalize選項。這覆蓋merge.renormalize配置變量。
no-renames
關閉重命名檢測。另請參閱 git-diff [1] --no-renames。
find-renames=<n>
打開重命名檢測，可選擇設置相似性閾值。這是默認設置。另請參閱 git-diff [1] --find-renames。
rename-threshold=<n>
已棄用的同義詞find-renames=<n>。
subtree=<path>
該選項是一種更高級的subtree策略形式，該策略可以猜測兩個樹在合并時必須如何移動以相互匹配。相反，指定的路徑是前綴（或從開始剝離）以使兩棵樹的形狀匹配。
octopus
這解決了兩個以上負責人的情況，但拒絕執(zhí)行需要手動解決的復雜合并。它主要用于將主題分支主題捆綁在一起。這是拉取或合并多個分支時的默認合并策略。
ours
這可以解析任意數(shù)量的頭，但合并結果樹始終是當前分支頭的樹，有效地忽略了來自所有其他分支的所有更改。它是用來取代側枝的舊發(fā)展歷史。請注意，這與recursive合并策略的 -Xours 選項不同。
subtree
這是一個修改后的遞歸策略。當合并樹 A 和 B 時，如果 B 對應于 A 的子樹，則首先調整 B 以匹配 A 的樹結構，而不是讀取處于相同級別的樹。這種調整也對共同的祖先樹進行。
對于使用3路合并（包括默認值recursive）的策略，如果在兩個分支上進行了更改，但稍后在其中一個分支上進行了恢復，則該更改將出現(xiàn)在合并結果中; 有些人覺得這種行為很混亂。這是因為在執(zhí)行合并時僅考慮頭部和合并基礎，而不是個別提交。因此，合并算法將恢復的更改視為完全沒有更改，而是替換更改的版本。
Notes
您應該了解在git rebase共享的存儲庫上使用的含義。請參閱下面的“從上游重新啟動”中恢復。
當 git-rebase 命令運行時，它會首先執(zhí)行一個 “pre-rebase” 掛鉤（如果存在）。您可以使用此掛鉤進行健全性檢查，并在不合適的情況下拒絕 rebase 。有關示例，請參閱模板 pre-rebase 掛鉤腳本。
完成后，<branch> 將成為當前分支。
交互模式
交互式重新定位意味著您有機會編輯重新提交的提交。您可以對提交進行重新排序，并且可以將其刪除（清除不良或其他不需要的修補程序）。
交互模式適用于這種類型的工作流程：
有一個奇妙的想法
破解代碼
準備一系列提交
提交
point 2. 由幾個實例組成
a）常規(guī)使用
完成值得一提的東西
遞交
b）獨立修復
意識到某些事情不起作用
解決該問題
提交它
有時候在 b.2 中固定的東西。不能修改為它所修復的不完美的提交，因為該提交深深地埋入了補丁系列中。這正是交互式底座的用途：在大量的 “a” 和 “b” 之后使用它，重新安排和編輯提交，并將多個提交壓縮成一個。
按照原樣保留的最后一次提交啟動它：
git rebase -i <after-this-commit>
編輯器將會觸發(fā)當前分支中的所有提交（忽略合并提交），這些提交會在給定的提交之后提交。您可以將此列表中的提交重新排序，直至您的內容為準，并且可以將其刪除。該列表看起來或多或少像這樣：
pick deadbee The oneline of this commit pick fa1afe1 The oneline of the next commit...
在線描述純粹是為了樂趣; git rebase將不會看到它們，而是以提交名稱（本例中為 “deadbee” 和 “fa1afe1” ），因此不要刪除或編輯名稱。
通過使用命令 “edit” 替換命令 “pick” ，您可以告訴git rebase在應用該提交后停止，以便您可以編輯文件和/或提交消息，修改提交并繼續(xù)重新綁定。
如果您只想編輯提交的提交消息，請將命令 “pick” 替換為 “reword” 命令。
要刪除提交，請將 “pick” 命令替換為 “drop” ，或者只刪除匹配的行。
如果要將兩個或多個提交合并為一個，請將第二個提交和后續(xù)提交的命令替換為 “squash ”或 “fixup” 。如果提交具有不同的作者，則折疊提交將歸于第一次提交的作者。對于已提交的提交，建議的提交消息是第一次提交的提交消息和那些使用 “squash” 命令的提交消息的連接，但省略了使用 “fixup” 命令提交的提交消息。
git rebase將 “pick” 替換為 “edit” 或由于合并錯誤而導致命令失敗時停止。當您完成編輯和/或解決沖突時，您可以繼續(xù)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
重新排序和編輯提交通常會創(chuàng)建未經(jīng)測試的中間步驟。您可能需要檢查歷史編輯是否通過運行測試，或至少使用 “exec” 命令（快捷方式 “x” ）在歷史中間點重新編譯來破壞任何內容。你可以通過創(chuàng)建一個像這樣的待辦事項列表來實現(xiàn)：
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狀態(tài)退出），交互式重新分配將停止，讓您有機會解決問題。你可以繼續(xù)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>^，其中 <commit> 是您要分割的提交。實際上，只要包含該提交，任何提交范圍都會執(zhí)行。使用“編輯”操作標記要分割的提交。
當編輯提交時，執(zhí)行
git reset HEAD^。其效果是 HEAD 被倒回1，并且索引也隨之而來。但是，工作樹保持不變。現(xiàn)在將更改添加到您想要在第一次提交中使用的索引中。您可以使用
git add（可能交互式）或git gui（或兩者）來做到這一點。使用現(xiàn)在適合的提交消息提交當前的索引。
重復最后兩個步驟，直到你的工作樹干凈。
繼續(xù)與
git rebase --continue的 rebase 。
如果您不確定中間修訂是否一致（它們會進行編譯，通過測試套件等），您應該使用git stash它在每次提交，測試和修改提交（如果需要修復）后保留尚未提交的更改。
從上游的 rebase 恢復
其他人基于工作的分支（或任何其他形式的重寫）是一個壞主意：它下游的任何人都被迫手動修改其歷史記錄。本節(jié)介紹如何從下游角度進行修復。然而，真正的解決辦法是避免重新擺放上游。
為了說明，假設你處于某人開發(fā)subsystem分支的情況，并且你正在研究一個topic依賴于此的分支subsystem。你可能會得到如下的歷史記錄：
o---o---o---o---o---o---o---o master \ o---o---o---o---o subsystem \ *---*---* topic
如果subsystem重新發(fā)放master，會發(fā)生以下情況：
o---o---o---o---o---o---o---o master \ \ o---o---o---o---o o'--o'--o'--o'--o' subsystem \ *---*---* topic
如果你現(xiàn)在繼續(xù)開發(fā)像往常一樣，并最終合并topic到subsystem，從提交subsystem會永遠保持復制：
o---o---o---o---o---o---o---o master \ \ o---o---o---o---o o'--o'--o'--o'--o'--M subsystem \ / *---*---*-..........-*--* topic
這些重復的東西通常會被忽視，因為它們混淆了歷史，使其難以遵循。為了清理，你需要將提交移植topic到新的subsystem提示中，即 rebase topic。這變成了一種連鎖反應：下游的任何人topic都被迫變質，等等！
有兩種修復方法，將在以下小節(jié)中討論：
簡單案例：這些變化字面上是相同的。
如果這個subsystem rebase 是一個簡單的 rebase 并且沒有沖突，就會發(fā)生這種情況。
困難的情況：變化是不一樣的。
如果subsystem rebase 有沖突或者用于--interactive忽略，編輯，擠壓或修改提交，就會發(fā)生這種情況; 或者如果上游使用的一個commit --amend，reset或filter-branch。
簡單的情況
只有subsystem在 rebase subsystem之前和之后的變化（基于 diff 內容的補丁ID）字面上相同時才有效。
在這種情況下，修復很容易，因為git rebase知道跳過已經(jīng)存在于新上游的變化。所以如果你說（假設你在topic）
$ git rebase subsystem
你會以固定的結果結束
o---o---o---o---o---o---o---o master \ o'--o'--o'--o'--o' subsystem \ *---*---* topic
困難的情況
如果這些subsystem變化與 rebase 之前的變化不完全一致，事情會變得更加復雜。
Note | While an "easy case recovery" sometimes appears to be successful even in the hard case, it may have unintended consequences. For example, a commit that was removed via git rebase --interactive will be resurrected! |
|---|
這個想法是手動告訴git rebase“舊的subsystem結局和你的topic開始”，也就是說，他們之間的舊合并基礎是什么。您必須找到一種方法來命名舊的最后一次提交subsystem，例如：
隨著
subsystemreflog：之后git fetch，舊的一角subsystem是在subsystem@{1}。后續(xù)提取將增加數(shù)量。（請參閱 git-reflog [1]。）相對于提示
topic：知道你topic有三次提交，舊的提示subsystem必須是topic~3。
然后你可以subsystem..topic通過說（對于 reflog 的情況，并假設你已經(jīng)topic），將舊的移植到新的提示中：
$ git rebase --onto subsystem subsystem@{1}“硬性案例”恢復的連鎖反應特別糟糕：everyone下游topic將不得不進行“硬性案例”恢復！
Bugs
提供的待辦事項列表--preserve-merges --interactive不代表修訂圖的拓撲結構。編輯提交和重新提交它們的提交消息應該可以正常工作，但嘗試重新排序提交往往會產(chǎn)生違反直覺的結果。
例如，嘗試重新排列
1 --- 2 --- 3 --- 4 --- 5
至
1 --- 2 --- 4 --- 3 --- 5
通過移動 “pick 4” 行，將導致以下歷史記錄：
3 /1 --- 2 --- 4 --- 5