リポジトリの履歴は「美しい一本の線」であるべきだ：`git pull –rebase` を極めるメンタルモデル
優秀なエンジニアはコードを書くが、一流のエンジニアは「履歴」を設計する。
チーム開発において、`git pull` を安易に叩いて大量の「Merge branch ‘main’ of …」という無意味なマージコミットが混入する光景は、もはや技術的負債だ。履歴はプロジェクトの航海日誌であり、それがスパゲッティ状態では、後からバグを追跡する（`git bisect`）際に地獄を見ることになる。
今回は、Gitの履歴を線形（Linear）に保ち、チームの生産性を一段引き上げるための「rebase」の極意を伝授する。
—
1. メンタルモデル：なぜ `rebase` なのか？
多くのエンジニアが `git pull` を使うとき、それは `git fetch` してから `git merge` を行っている。これが「非線形な履歴」を作る元凶だ。
`git pull –rebase` の本質は「自分の変更を、最新の履歴の上に積み直す」ことにある。
視覚的理解
- Mergeの場合: 2つの履歴が合流し、ダイヤモンド型のグラフができる。
- Rebaseの場合: 自分のコミットを一時的に保存し、最新のメインブランチの先端に自分のコミットを「一つずつ」適用し直す。
結果、履歴は常に一本の線となり、どこで機能が追加されたのかが数学的に明らかになる。
—
2. 現場で震えるほど役立つ「黄金の設定」
毎回 `–rebase` と打つのは非効率だし、忘れれば事故の元だ。まずは以下のコマンドで、デフォルトの挙動をリベースに変更せよ。
pullする際は常にrebaseを行う（チーム推奨設定）
git config –global pull.rebase true
rebase中にコンフリクトが発生しても、自動的にスタッシュを適用する設定
git config –global rebase.autoStash true
なぜ `rebase.autoStash` が神なのか？
作業中に急な割り込みが入った際、`git add .` を忘れて `git pull` を叩くとエラーで止まる。`autoStash` をオンにしておけば、Gitが勝手にローカルの変更を退避し、rebase後に自動で戻してくれる。これだけで、コンテキストスイッチのコストが激減する。
—
3. コンフリクトは「恐れるな、分解しろ」
rebase中にコンフリクトが起きると「怖い」と感じる人がいるが、それはGitが「君の変更を正しく適用するために、どこが競合しているか確認してくれ」と丁寧に聞いてくれているだけだ。
究極のトラブルシューティング・フロー
1. `git rebase –abort`: 迷ったらこれ。いつでもリベース開始前の平和な状態に戻れる。
2. `git status`: 競合ファイルを確認。
3. `git add
4. `git rebase –continue`: これを繰り返す。
極意: `rebase` は「コミットの再適用」である。コンフリクト解消は、そのコミット単位で行うため、結果として「より小さく、より正確なコミット」に洗練される。
—
4. 開発スピードを加速させる「魔法のツール」
コマンドラインだけで戦うのは美学だが、視認性はツールに頼れ。
おすすめプラグイン: `git-delta`
標準の `git diff` は見にくい。`delta` を導入すると、シンタックスハイライト付きで差分が劇的に読みやすくなる。
.gitconfig の構成例:
[core]
pager = delta
[interactive]
diffFilter = delta –color-only
[delta]
navigate = true # n/Nでファイル間を移動可能
light = false # ダークモード用
line-numbers = true
—
5. チームで共有すべき「リポジトリの作法」
個人のスキルだけでは履歴は綺麗にならない。`.gitconfig` をプロジェクトルートに配置し、CIでチェックする仕組みを作るのがテックリードの仕事だ。
推奨する `.gitconfig` の構成:
[alias]
# 直近のコミットを整理する
lg = log –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit
# 強制的に最新に追従しつつ、ローカルの変更を逃さない
sync = !git fetch && git rebase origin/main
チームへの提言
1. `git merge –no-ff` の禁止: マージコミットを作るな。PRは `squash merge` で取り込み、メインブランチを常にクリーンに保て。
2. `git push –force-with-lease` の徹底: `force` ではなく `–force-with-lease` を使え。他人のコミットを誤って消し飛ばすリスクを回避できる、プロの最低限の礼儀だ。
—
最後に：履歴は君の「背中」である
コードは動けば良いものではない。後から読む人間（未来の自分を含む）にとって、履歴が読みやすいことは、最高のドキュメントよりも価値がある。
今日から `git pull` を打つ指を止めて、`rebase` を選択してほしい。その小さな一歩が、チーム全体の開発速度を劇的に変えるはずだ。
履歴を磨け。それが、一流への入り口だ。