Git Rebase とマージ: いつ何を使用するか
Git で最も議論されている決定事項の 1 つは次のとおりです。 リベースまたはマージを使用する?両方 あるブランチから別のブランチへの変更を統合しますが、その方法は根本的に異なります。理解する それぞれの違い、長所と短所は、ストーリーを維持するために不可欠です Git をクリーンアップし、チームとして効果的にコラボレーションします。
🎯 何を学ぶか
- リベースとマージの基本的な違い
- リベースをいつ使用するか、いつマージするか
- 早送りマージとマージコミット
- リベースの黄金律
マージの仕組み
Gitのマージ 新しいものを作成する マージコミット それが物語を結びつける 2つの枝の。それは手術です 非破壊的: 元のブランチは来ません 変更されました。
# Situazione iniziale
main: A---B---C
\
feature: D---E
# Merge di feature in main
git checkout main
git merge feature
# Risultato
main: A---B---C-------M
\ /
feature: D---E---
# M è il merge commit che ha due genitori: C ed E# Passa al branch di destinazione
git checkout main
# Mergia il feature branch
git merge feature
# Git crea automaticamente un merge commit
# Messaggio default: "Merge branch 'feature' into main"リベースの仕組み
Gitリベース 書き換えます ブランチのコミットを移動することによる履歴 新しいベースで。マージコミットを作成する代わりに、コミットが到着します。 再適用された 目的の枝の先端に 1 つずつ。
# Situazione iniziale
main: A---B---C
\
feature: D---E
# Rebase di feature su main
git checkout feature
git rebase main
# Risultato
main: A---B---C
\
feature: D'---E'
# D' ed E' sono NUOVI commit con contenuto uguale a D ed E
# ma hash diversi (perché il parent è cambiato)# Passa al feature branch
git checkout feature
# Rebase su main
git rebase main
# I commit di feature vengono riapplicati su main
# Se ci sono conflitti, risolvili e:
git add .
git rebase --continue
# Ora puoi fare fast-forward merge su main
git checkout main
git merge feature # Fast-forward (nessun merge commit)早送りマージ
Un 早送りマージ ターゲット ブランチにコミットがない場合に発生します マージされるブランチと比較して新しい。 Git は単にポインタを「前方に移動」します。 マージコミットを作成します。
# Situazione dopo rebase
main: A---B---C
\
feature: D'---E'
# Fast-forward merge
git checkout main
git merge feature
# Risultato (nessun merge commit)
main: A---B---C---D'---E'
|
feature: 早送りを回避してマージコミットを強制するには:
git merge --no-ff feature主な違い
マージ：
- 分岐履歴: 分岐が分岐したときを表示します
- 非破壊: オリジナルストーリーは保存されています
- 追跡可能: マージがいつ行われたかを正確に確認する
- 安全： 歴史は書き換えられない
- 追加のマージコミットを作成する
リベース:
- 直線的なストーリー: まるで順番に作業したかのように
- 破壊的: コミットの書き換え（新しいハッシュ）
- クリーン： ノイズの多いマージコミットはありません
- 危険: パブリックブランチをリベースしないでください。
- 読みやすい物語
マージを使用する場合
✅ 次の場合にマージを使用します。
- 無傷 公共の支店 (メイン、開発)
- あなたが欲しいのは 歴史を保存する ちょうど枝が分岐したとき
- あなたはで働いています チーム 他の人はすでにブランチを削除しています
- 追跡したい マイルストーン (完成した機能、リリース)
- フォローする Git フロー （アメリカ合衆国
--no-ff構造を維持するため）
# Feature branch completato
git checkout main
git merge --no-ff feature/user-auth
# Merge commit preserva la storia della feature
# Chiaro quando la feature è stata integrata
# Altri sviluppatori vedono la struttura completaリベースを使用する場合
✅ 次の場合にリベースを使用します。
- あなたは取り組んでいます 民間の地方支店
- あなたが欲しいのは 直線的なストーリー クリーン
- メインからの最新の変更で機能ブランチを更新しています。
- 「ノイズの多い」マージコミットを避けたい
- プル リクエストを作成する前に (クリーンなストーリーの場合)
# Il tuo feature branch è indietro rispetto a main
git checkout feature/payment
git rebase main
# Ora il tuo branch ha gli ultimi cambiamenti da main
# Storia lineare, facile da revieware nella PR
# Risolvi conflitti se necessario
# git add .
# git rebase --continueリベースの黄金律
⚠️黄金律
共有パブリックブランチにプッシュされたコミットを決してリベースしないでください。
リベースはコミット ハッシュを変更することで履歴を書き換えます。他の開発者が持っている場合 すでにそれらのコミットに基づいて作業を行っていると、リポジトリに一貫性がなくなり、 次回のプルでは競合や重複が発生します。
# MALE! Altri hanno già pullato main
git checkout main
git rebase feature
# Questo riscrive main, causando problemi per tutti# BENE! feature è solo tuo, nessuno l'ha pullato
git checkout feature
git rebase main
# Aggiorna il tuo branch privato con gli ultimi cambiamenti推奨されるワークフロー
両方の長所を組み合わせたワークフローを次に示します。
# 1. Crea feature branch da main
git checkout -b feature/new-feature main
# 2. Lavora sulla feature
git commit -m "feat: add component"
git commit -m "feat: add tests"
# 3. Nel frattempo, main è andato avanti
# Aggiorna il tuo branch con rebase (branch privato, OK!)
git fetch origin
git rebase origin/main
# 4. Pulizia della storia con interactive rebase (opzionale)
git rebase -i origin/main
# Squash commit WIP, fixup typos, ecc.
# 5. Push del feature branch
git push origin feature/new-feature
# 6. Crea Pull Request su GitHub/GitLab
# 7. Dopo code review, mergia in main CON merge commit
git checkout main
git merge --no-ff feature/new-feature
# Risultato: storia main pulita con milestone chiare線形履歴と分岐履歴
マージの歴史:
* Merge feature B
|\
| * Feature B commit 2
| * Feature B commit 1
* | Main commit 3
* | Main commit 2
|/
* Main commit 1長所: 機能がいつ統合されたかを正確に確認する
と： マージがたくさんあると面倒になる可能性があります
リベースによる履歴:
* Feature B commit 2
* Feature B commit 1
* Main commit 3
* Main commit 2
* Main commit 1長所: 直線的でわかりやすい
と： ブランチがいつ分岐したかに関する情報が失われる
競合: マージとリベース
どちらも競合する可能性がありますが、処理方法が異なります。
# Conflitti durante MERGE
git merge feature
# Risolvi conflitti
git add .
git commit # Completa il merge
# Conflitti durante REBASE
git rebase main
# Risolvi conflitti per ogni commit in conflitto
git add .
git rebase --continue # Vai al prossimo commit
# Ripeti fino alla fine
# Abortire rebase se necessario
git rebase --abortチームの設定
チームが異なれば好みも異なります。いくつかの例:
- Linux カーネル: マージのみ (完全な履歴を保持)
- レール: 機能ブランチの場合はリベース、重要な統合の場合はマージ
- グーグル： リベースによる線形履歴 (トランクベースの開発)
結論
マージとリベースの間に普遍的な「最善の」選択肢はありません。 マージ 保存する
歴史があり、公共の支店でも安全です。 リベース きれいな直線的なストーリーを作成します
しかしコミットを書き換えます。最良の戦略は多くの場合ハイブリッドです。リベースを使用してクリーンな状態を保ちます。
ローカル機能をブランチし、マージします --no-ff 公共ブランチに統合します。
🎯 重要なポイント
- マージ = 非破壊、マージ コミット、分岐履歴を作成します。
- リベース = 履歴の書き換え、マージコミットなし、線形履歴
- 一度もない 共有パブリックブランチをリベースする
- プライベート機能ブランチにはリベースを使用し、パブリック統合にはマージを使用します
- 早送りマージ = 可能な場合はマージ コミットを行わない