科技 · 實用指南
Git變基跳過提交？重放前先審核修補程式
提交雜湊被跳過不等於程式碼遺失。先區分上游等價修補、重放後為空、手動跳過與GitHub合併限制，再改寫歷史。
Git報告跳過已套用提交時，先把改動與實際變基的目標上游比較。預設變基可省略上游已有的乾淨挑選修補，即使提交ID不同。不要只為恢復舊提交數量而加參數重跑。
指南圍繞原始頂點、目標頂點及確切跳過修補建立證據記錄，並區分本地Git行為與GitHub拉取請求按鈕。警告本身不能診斷託管平台的合併限制。
記錄操作並找回原始頂點
保存完整警告、跳過ID、原始命令、Git版本與目標分支。執行`git status`確認變基是否仍在進行。自動已套用警告、重放後為空與手動跳過衝突提交是不同事件，應記錄實際是哪種，不要都叫遺失提交。
變基完成後查看`git reflog show --date=iso YOUR_BRANCH`，以真實分支名替換YOUR_BRANCH，按操作順序辨認原始頂點。記下確切舊雜湊及目標雜湊，不假設固定reflog索引總是所需狀態。reflog是本地記錄且可能到期；原始物件不可用時，停止並尋找其他保留副本。
針對正確上游檢查修補等價
以記錄的上游和原始分支頂點執行`git cherry -v UPSTREAM_HASH OLD_TIP_HASH`，將名稱替換為已核雜湊。減號表示上游存在等價修補，加號表示沒找到。Git文檔的比較忽略空白及行號，不是比提交訊息或舊ID。也要閱讀實際跳過修補；標記是等價證據，不證明全部預期結果。
命令只檢查已提交修補，不含未提交編輯，也不能證明後續提交沒有撤銷改動。檢查相關檔案與預期行為。本站在隔離Git 2.51.1樣例中確認挑選過的功能標減號、變基時省略，但最終檔案保留；另一未匹配提交也保留。有限示例不代表測試了你的倉庫。
比較序列，再決定是否重放
操作完成且基點、頂點明確時，查看`git range-diff OLD_BASE_HASH..OLD_TIP_HASH NEW_BASE_HASH..NEW_TIP_HASH`，以實際範圍替換四個占位符。結合上游修補比較閱讀未匹配與變更條目。新主題範圍缺少修補，可能是它已在新基點；缺一條不等於程式碼遺失。range-diff是供人閱讀的比較輸出，非恢復命令或穩定機器驗收格式。
Git說明`--reapply-cherry-picks`改變的是對乾淨上游等價修補的預先省略。重放提交仍可能為空，由`--empty`控制該階段。兩者均不保證恢復行為。確實發現缺失時，先保留目前工作並確認所需歷史再恢復，不以再次變基、硬重設或強推作診斷。
把GitHub按鈕當作獨立分支
本地變基成功但GitHub拒絕Rebase and merge時，收集拉取請求基點、頂點雜湊、提交數與確切平台訊息。當前GitHub倉庫限制文檔將此方式限定100個提交。超限是可核實的獨立條件；未超限亦不證明其他合併要求已滿足。沒有證據，不認定本地跳過警告造成平台拒絕。
每項預期改動都應有說明：已由上游承載、明確決定移除或仍需審核恢復。檢查最終檔案和專案必要驗證，再依允許的合併策略處理平台限制。保留新舊頂點、命令、跳過ID、比較與未解釋改動交給維護者。關閉提示或恢復提交數量不是驗收。
