rebase — なぜ履歴が「書き換わる」のかのサンプルコード — Gitの内部構造から理解する

1rebaseでハッシュが変わる瞬間(実機の記録)

実際にrebaseして前後を記録した出力です。変更内容(notes.txt を1行追加)は全く同じなのに、parentが変わったためコミットのIDが別物になっています。これがrebaseの本質です。

# rebase する前
$ git rev-parse HEAD
834a495cf6979b968683d61dc22f2a654f2214c6
$ git rev-parse HEAD^
dd2818b6f87da96757d1cd70f43e293660aece49    ← 親は dd2818b

$ git rebase main

# rebase した後
$ git rev-parse HEAD
bacb6891d489f7fbf0c0c81ca4464a4b77539306    ← 別のコミットになった
$ git rev-parse HEAD^
459f52836739f6ed2cd608b98559f1662b75aa61    ← 親が付け替わった

# 変更内容は同じ
$ git show --stat --format='' HEAD
 notes.txt | 1 +

# → 差分は同じでも、parentが違うのでハッシュが変わる

2なぜハッシュを維持できないのか

commitのIDは parent 行を含むテキスト全体から計算されます。だから親を付け替えると、必ず別のIDになります。「変えないでほしい」と願っても原理的に無理だと計算で確認できます。

Python

import hashlib

def commit_id(tree, parent, message):
    body = f"tree {tree}\nparent {parent}\n\n{message}\n".encode()
    header = f"commit {len(body)}".encode() + b"\x00"
    return hashlib.sha1(header + body).hexdigest()

tree = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"   # 中身は全く同じ
message = "メモを追加"                                 # メッセージも同じ

before = commit_id(tree, "dd2818b" + "0" * 33, message)
after  = commit_id(tree, "459f528" + "0" * 33, message)

print("rebase前(親 dd2818b):", before)
print("rebase後(親 459f528):", after)
print()
print("tree(ファイルの中身)もメッセージも同一。違うのは parent だけ")
print("それでもIDは完全に別物 → 同じハッシュを保つのは原理的に不可能")

31つ書き換えると、その先が全部作り直される

3つ連なったコミットの真ん中を書き換えると、それ以降も芋づる式に変わります。rebase -i で古いコミットを編集したときに「そこから先が全部別IDになる」理由がこれです。

Python

import hashlib

def build(messages, first_parent=None):
    ids, parent = [], first_parent
    for m in messages:
        body = f"parent {parent}\n{m}".encode()
        h = hashlib.sha1(body).hexdigest()[:12]
        ids.append((m, h))
        parent = h
    return ids

original = build(["A: 土台", "B: 機能追加", "C: テスト", "D: 仕上げ"])
edited   = build(["A: 土台", "B: 機能追加(修正)", "C: テスト", "D: 仕上げ"])

print(f"{'メッセージ':22}{'元のID':14}{'書き換え後':14}")
print("-" * 56)
for (m1, h1), (m2, h2) in zip(original, edited):
    mark = "" if h1 == h2 else "  ← 変わった"
    print(f"{m1:22}{h1:14}{h2:14}{mark}")

print("\nBだけを直したのに、C と D のIDまで変わっている")
print("→ 既にpushしてある場合、他の人の履歴と食い違う")
print("  これが「共有ブランチでrebaseするな」の理由")

4古いコミットは消えていない

rebase後も、元のコミットはオブジェクトDBに残っています。参照されなくなっただけです。reflogでハッシュを見つければ、いつでも元の状態に戻せます。

# rebase後、古いコミットはどうなったか
$ git cat-file -t 834a495cf6979b968683d61dc22f2a654f2214c6
commit                        ← まだDBに存在する

# ただし、どのブランチからも辿れなくなっている
$ git branch --contains 834a495
(何も出ない)

# reflog を見れば、HEADが過去に指した先が分かる
$ git reflog
bacb689 rebase (finish): returning to refs/heads/topic
bacb689 rebase (pick): メモを追加
459f528 rebase (start): checkout main
834a495 commit: メモを追加          ← rebase前の状態

# 元に戻したいとき
$ git reset --hard 834a495

5mergeとrebaseで履歴の形がどう変わるか

同じ作業をmergeした場合とrebaseした場合で、履歴の見え方を並べます。どちらが正しいという話ではなく、「既存コミットを残すか、作り直すか」という性質の違いです。

# ── merge した場合 ─────────────────
$ git log --graph --oneline
*   9f3c1a2 Merge branch 'feature'
|\
| * e4d92c8 ログイン処理を追加     ← IDは変わらない
* | 0361ab2 ログアウト処理を追加
|/
* dd2818b READMEに使い方を追加

#   分岐と合流が事実として残る。既存コミットのIDは不変

# ── rebase した場合 ────────────────
$ git log --graph --oneline
* 7b2e5f1 ログイン処理を追加       ← e4d92c8 から作り直された
* 0361ab2 ログアウト処理を追加
* dd2818b READMEに使い方を追加

#   一直線で読みやすい。ただしIDは別物になっている
#   → pushしていない自分だけのブランチなら rebase して良い
#     共有済みブランチは merge にする

サンプルコードで身につける: rebase — なぜ履歴が「書き換わる」のか

1rebaseでハッシュが変わる瞬間(実機の記録)

2なぜハッシュを維持できないのか

31つ書き換えると、その先が全部作り直される

4古いコミットは消えていない

5mergeとrebaseで履歴の形がどう変わるか