Gitブランチが分岐したとき：mergeかrebaseか

例と前提条件

例はorigin/mainを追うmainで、ローカル2個とリモート1個のコミットがあります。実際のブランチとupstream名を確認します。fetchはリモート追跡参照を更新しますが、現在のブランチに自動統合しません。別名のremoteやupstream未設定ならコマンドの名前を調整してください。

変更前に状態を確認する

statusとbranch -vvを読み、fetch originします。HEAD...origin/mainの左右の数は各側だけのコミット数です。グラフと差分も読みます。2対1という数だけでは同じ関数を編集したか分かりません。古いリモート参照や数だけで診断しないでください。

git status --short
git branch -vv
git fetch origin
git rev-list --left-right --count HEAD...origin/main
git log --oneline --graph --decorate HEAD origin/main

参照または別のチェックアウトを保つ

統合前にローカル先端のrescue/before-syncを作り、未コミットの変更は別に保存します。ブランチは確定済み履歴を保ち、stashは追跡・未追跡・無視ファイルで保存範囲が異なります。保存結果を確認します。無関係な編集を抱えた統合は競合と復元の理解を難しくします。

git branch rescue/before-sync HEAD

最初の手順

履歴を保つべき場合、特にローカルコミットが共有済みならmergeを選びます。merge origin/mainは取得したupstreamと現在のブランチを統合し、分岐なら通常は両親を記録します。公開前に差分とプロジェクトのチェックを確認します。merge完了だけでコードの正しさは保証されません。

git merge origin/main

別の結果を意図して選ぶ

チームが書き換えを許すローカルコミットならrebaseを選べます。rebase origin/mainは取得した先端に変更を再適用し、通常IDが変わります。他の人が古いIDに依存しているかもしれません。直線的なグラフだけを理由に共有ブランチを書き換えたり保護ルールを回避したりしないでください。

git rebase origin/main

制限と例外

mergeの競合ではstatusを読み、解決してステージし、統合を完了します。条件を満たす場合merge --abortで中止できます。rebaseでは現在の競合を解決しrebase --continueを使い、複数回停止する場合があります。rebase --abortは進行中のrebaseを中止します。手順を混ぜないでください。

git status
git merge --abort

git rebase --abort

競合と後片付け

reset --hard origin/mainは一般的な解決ではありません。ブランチ独自のローカル履歴をその参照から除き、追跡ファイルも上書きし得ます。これは作業を捨てる別の判断です。このガイドは必要な履歴を統合します。捨てたい場合は先にコミットを読み、必要なコピーを保存する別手順を使います。

結果を確認する

最終グラフ、状態、origin/mainとの差分とプロジェクトチェックを確認します。fetch後にremoteが進むと通常のpushは拒否され得ます。もう一度取得して状態を確認し、自動的にforce pushへ切り替えないでください。統合の影響をレビューするまで救出参照を残します。

git status --short
git log -8 --oneline --graph --decorate
git diff origin/main HEAD

よくある質問

pullが戦略を求めるのは、fetchに統合の選択が加わるためです。mergeでもrebaseでも競合は起きます。rebaseが常に優れているわけではなく、共有済みかとチームの履歴方針が判断の基準です。

FluxGitで操作を確認する

FluxGitの履歴と差分の表示で、操作と関連コミットを確認してください。この例のブランチ、共有履歴、ローカルファイルのチェックは維持します。現在利用できるビルドと対応プラットフォームはダウンロードページで確認できます。

Git公式ドキュメント

• git-fetch
• git-merge
• git-rebase
• git-pull