1. 導入：なぜマージコミットを減らすべきなのか
開発現場において、git pull を実行するたびに生成される「Merge branch ‘main’ of …」というマージコミットに悩まされたことはありませんか？ チーム開発で複数人が同時に作業していると、マージコミットが頻発し、Gitの履歴が複雑に絡み合ってしまいます。これにより、不具合発生時の調査（git bisectなど）や、変更箇所の特定が非常に困難になります。git pull –rebase を常態化することで、履歴を一直線に保ち、プロジェクトの可読性を劇的に向上させることが可能です。
2. 基礎知識：rebase とは何か
Gitにおける rebase とは、一言で言えば「ベースの付け替え」です。
通常、git pull（デフォルト設定）は、ローカルの変更とリモートの変更を「マージ」して、新しいマージコミットを作成します。一方、rebase を行うと、まずローカルのコミットを一時的に退避させ、リモートの最新状態をローカルに反映させた後、退避させていたローカルのコミットをその上に「積み直す」という動作をします。これにより、履歴が分岐することなく一直線に並び、見た目が非常にすっきりします。
3. 実装：git pull –rebase を自動化する
毎回オプションを打つのは手間ですし、忘れるリスクもあります。Gitの設定を変更することで、pull 時に自動的に rebase を行うように設定するのが一般的です。以下のコマンドを実行することで、リポジトリ単位、あるいはグローバル（PC全体）で設定を適用できます。
4. サンプルプログラム：設定コマンドと運用例
以下のコードブロックをターミナルで実行してください。
現在の設定を確認する（未設定の場合は何も表示されないか空）
git config –get pull.rebase
プロジェクト単位で常態化する（推奨）
git config pull.rebase true
PC内の全リポジトリで常態化したい場合（グローバル設定）
git config –global pull.rebase true
設定後の運用：意識せず pull するだけで rebase が走ります
git pull
5. 応用・注意点：現場で陥りやすい罠
rebase を常態化する上で、以下の点には注意が必要です。
1. プッシュ済みのコミットを rebase しない
既にリモートリポジトリにプッシュした履歴を rebase して書き換えると、チームメンバーの環境と履歴が乖離し、混乱を招きます。rebase は「まだ誰にも共有していない、ローカルにある自分のコミット」に対してのみ行うのが鉄則です。
2. コンフリクトの解決
rebase 中にコンフリクトが発生した場合、手動でファイルを修正し、git add を実行してから git rebase –continue を行う必要があります。もし rebase が複雑になりすぎて混乱した場合は、git rebase –abort でいつでも元の状態に戻せることを覚えておきましょう。
3. 運用ルールの統一
チーム全体で rebase 運用を徹底することが重要です。一人だけデフォルトのマージ運用を続けていると、履歴が混在してしまい、かえって混乱を招く可能性があります。導入の際は、チーム内での認識合わせを行いましょう。
コメント