Git Rebase初心者ガイド：シンプルな入門

はじめに

Gitの履歴を見て「これはめちゃくちゃだ」と思ったことがあるなら、あなただけではありません。絡まったブランチラインや冗長なマージコミットは、実際に何がいつ変更されたのかを理解するのを困難にします。ここでgit rebaseの出番です—クリーンで読みやすいコミット履歴を維持するのに役立つ強力なツールです。

このガイドでは、リベースが何をするのか、マージとどう違うのか、そして日常のワークフローでいつ使用するのかを学びます。今日から使い始められる実践的な例に焦点を当て、避けるべき重要な落とし穴を強調します。

Git Rebaseとは？

git rebaseを履歴の書き換えと考えてください—ただし良い意味での書き換えです。リベースするとき、あるブランチからコミットを取得し、別のブランチの上でそれらを再生します。まるで異なる地点から作業を開始したかのようになります。

物語を書いているとしましょう。同僚がまだ第2章を編集している間に、あなたは第3章を書き始めます。同僚が完了したとき、あなたは以下のいずれかを選択できます：

• マージ：「同僚の第2章の変更をここに挿入」という注釈を追加
• リベース：第2章が既に完成した後に第3章を開始したかのように書き直し

リベースアプローチは「マージノイズ」なしに、よりクリーンな物語を提供します。

なぜGit Rebaseを使うのか？

履歴を線形でクリーンに保つ

線形履歴は本のように読めます—一つのコミットが明確な順序で次のコミットに続きます。これにより以下が容易になります：

• バグがいつ導入されたかを追跡する
• フィーチャーの進化を理解する
• プルリクエストでコード変更をレビューする

リベースなしでは、履歴は「Merged branch ‘main’ into feature-xyz」と繰り返し述べるマージコミットで埋め尽くされ、実際に行われた作業が見えなくなります。

開発者がRebaseを選ぶとき

開発者は主に2つの状況でリベースを使用します：

1. 最新状態の維持：フィーチャーブランチにmainからの最新更新が必要
2. 作業の磨き上げ：他の人にレビューしてもらう前にコミットをクリーンアップしたい

どちらのシナリオも、皆の生活を楽にするクリーンで線形な履歴の維持に役立ちます。

Git Rebase vs Merge：主な違い

根本的な違いは以下の通りです：

Mergeは2つのブランチを結合する新しいコミットを作成します：

A---B---C (main)
     \   \
      D---E---M (your-feature)

Rebaseはターゲットブランチの上にあなたのコミットを再生します：

A---B---C (main)
         \
          D'---E' (your-feature)

リベースが新しいコミット（D’とE’）を作成するのに対し、マージはマージコミット（M）を追加することに注目してください。リベースの結果は線形でクリーンですが、マージは正確な履歴を保持する代わりに複雑さを追加します。

Git Rebaseの一般的な使用例

フィーチャーブランチの更新

チームがmainに更新をプッシュしている間にフィーチャーで作業している場合、それらの変更を取り込むには：

git checkout your-feature-branch
git rebase main

これにより、最新のmainの上にあなたのコミットが再生され、マージコミットなしでブランチを最新に保てます。

プルリクエスト前のコミットクリーンアップ

作業を共有する前に、コミットを整理したい場合があります。インタラクティブリベースでは以下が可能です：

git rebase -i HEAD~3

これによりエディタが開き、以下が可能になります：

• 複数の「作業中」コミットを1つにスカッシュ
• 論理的な流れのためにコミットを並び替え
• 明確性のためにコミットメッセージを編集

例えば、以下を：

- Fix typo
- WIP: add login
- More login stuff
- Fix tests

以下に変換：

- Add user login functionality with tests

重要な警告：Rebaseしてはいけない場合

ゴールデンルール：共有ブランチはRebaseしない

他の人が作業しているブランチは絶対にリベースしないでください。リベースすると、異なるSHA-1ハッシュを持つ新しいコミットが作成されます。他の誰かが古いコミットを持っている場合、Gitは混乱し、重複したコミットを作成します。

リベース安全：あなたのローカルフィーチャーブランチ
絶対リベース禁止：main、develop、または他の人が使用するブランチ

フォースプッシュのリスクを理解する

リベース後、しばしばフォースプッシュが必要になります：

git push --force-with-lease origin your-feature-branch

--force-with-leaseフラグは--forceより安全です。最後のプル以降に他の誰かが変更をプッシュしていないかをチェックするためです。それでも、自分が所有するブランチのみフォースプッシュしてください。

Git Rebaseを始める

練習のためのシンプルなワークフローです：

1. mainからフィーチャーブランチを作成
2. いくつかのコミットを作成
3. その間にmainが更新される
4. フィーチャーブランチをリベース：

   git checkout feature-branch
   git rebase main

5. コンフリクトが発生した場合、解決して続行：

   git add .
   git rebase --continue

共有されたものをリベースする前に、ローカルブランチから始めて自信を築いてください。

まとめ

Git rebaseは、クリーンで線形なコミット履歴を維持するための強力なツールです。マージではなくコミットを再生することで、チーム全体に利益をもたらすより読みやすいプロジェクト履歴を作成できます。ゴールデンルールを覚えておいてください—プッシュしていない、または他の人が使用していないブランチのみをリベースする—そうすれば一般的な落とし穴を避けられます。

今日からフィーチャーブランチで練習を始めてください。線形履歴の明確さを体験すれば、それなしでどうやって作業していたのか不思議に思うでしょう。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.