テクノロジー · 実用ガイド
Git rebaseでコミットが省略された？再適用の前にパッチを確認
ハッシュの省略はコード消失の証明ではない。上流の同等パッチ、再適用後の空コミット、手動skip、GitHubの制限を分けて確認する。
Gitが適用済みコミットの省略を報告したら、実際のリベース先上流と変更を比較する。標準のリベースは、異なるコミットIDでも上流にある同等のクリーンなcherry-pickを省くことがある。古いコミット数を戻すためだけに追加フラグで再実行しない。
このガイドは旧tip、対象tip、省略パッチで証拠を整理する。ローカルGitとGitHubのプルリクエストボタンも別の確認事項で、警告だけではホスト側の合併制限の原因を診断できない。
操作を記録して旧tipを特定
完全な警告、省略ID、元コマンド、Gitバージョン、対象ブランチを保存する。`git status`でリベース途中か確認。適用済みの自動省略、再適用後に空、競合を手動でskipした場合は別で、すべてを消失と扱わず実際の段階を記録する。
完了後は`git reflog show --date=iso YOUR_BRANCH`を実際のブランチ名で実行し、操作順序から元tipを特定する。固定reflog番号を決めつけず、正確な旧・対象ハッシュを記録。reflogはローカルにあり期限切れもある。元オブジェクトがなければ止めて別の保存先を探す。
正しい上流に対してパッチを比較
記録したハッシュで`git cherry -v UPSTREAM_HASH OLD_TIP_HASH`を実行する。マイナスは上流に同等があり、プラスはないことを示す。Gitの比較は空白と行番号を除き、メッセージや旧IDの一致を調べるのではない。省略パッチ自体も読む。印は同等性の証拠で、意図した結果すべての保証ではない。
対象はコミット済みパッチで未コミット編集は含まれず、後続コミットによる取り消しも判断できない。ファイルと期待動作を確認する。隔離したGit 2.51.1の合成例では、cherry-pick済み機能がマイナスで省略されても最終ファイルに残り、別の非同等コミットも残った。読者のリポジトリを試験した結果ではない。
シリーズを比べて再適用の必要性を判断
完了した操作の基点とtipが分かれば`git range-diff OLD_BASE_HASH..OLD_TIP_HASH NEW_BASE_HASH..NEW_TIP_HASH`の4か所を実ハッシュに置き換えて確認する。未対応・変更項目を上流とのパッチ比較と合わせて読む。新topic範囲にないパッチは新baseにある可能性があり、不在だけで消失とはいえない。range-diffは人向けの比較で復旧コマンドや安定した機械判定形式ではない。
`--reapply-cherry-picks`はクリーンな上流同等パッチの事前省略を変更する。再適用後に空になる場合は`--empty`がその段階を制御する。どちらも不足動作の回復を保証しない。実際の不足なら現在の作業を保存し意図した履歴を合意して復旧する。再リベース、hard reset、force pushを診断に使わない。
GitHubボタンは別の分岐
ローカル成功でもGitHubがRebase and mergeを拒否するならPRのbase/headハッシュ、コミット数、正確な表示を記録。現在の公式制限はこの方法を100コミットまでとする。超過は具体的な別の条件だが、100以下でも他の要件が満たされた証明ではない。省略警告がホスト拒否の原因と決めつけない。
全変更について、上流にある、意図して除いた、確認済み復旧が必要のいずれかを説明できるまで確認する。最終ファイルとプロジェクト検証後、許可された合併方針でホスト制限を扱う。旧・新tip、コマンド、省略ID、パッチ比較、不明変更を管理者に渡す。助言を消すことやコミット数回復は完了判定ではない。
