git rebase が黙って動かすものと残すもの
結論 git rebase main は、ブランチにあって main に無いコミットを、main の先頭へ 1 本ずつ cherry-pick し直す。git はブランチの派生元を記録しないので、どこから先を載せるかは毎回コミットグラフから求める rebase の後は git merge-base main HEAD が main の先頭を返す。元の分岐点を後で使うなら rebase の前に控える 競合中の --ours は main 側、--theirs は自分のコミット。merge と逆になる 競合しなかったことは、整合していることを意味しない。main が入れた改名や規約は、競合しないファイルには届かない squash merge の後や載せるコミットが 0 件のときは、どこから先を載せるかの推定がずれて、衝突やブランチ先頭の移動が起きる。--onto で起点を明示する autostash の書き戻しが衝突しても、rebase も pull --ff-only も exit 0 で終わる 以下はすべて git 2.55.0 で実測した。pull.rebase や rerere.enabled などの利用者設定で結果が変わるので、GIT_CONFIG_GLOBAL=/dev/null で ~/.gitconfig を読ませずに実行している。 前提: rebase は分岐点から先を作り直す git rebase <upstream> は次の 4 段で動く (man git-rebase)。 今のブランチにあって <upstream> に無いコミットを並べる。<upstream> に同じ変更 (patch-id が一致するコミット) があるものは外す <upstream> の先頭を detach でチェックアウトする 並べたコミットを 1 本ずつ cherry-pick する ブランチをできあがった先頭へ付け替える 1 の範囲は git log <upstream>....