ようこそ、Gitの深淵なる世界へ。
私はこれまで、数千人規模のエンジニアが交差する巨大なプロジェクトから、一分の隙も許されない超高速CI/CDパイプラインの構築まで、あらゆる「現場」を渡り歩いてきました。そこで確信したことがあります。
「Gitの履歴が美しいチームは、コードの品質も高く、デリバリー速度も速い」
なぜでしょうか？ それは、コミット履歴が単なる「バックアップ」ではなく、開発者同士の「対話の記録」であり、未来の自分への「地図」だからです。
今日は、初心者の方が一歩踏み出し、中級・上級者への階段を駆け上がるための必須テクニック、`rebase`（リベース）と`cherry-pick`（チェリーピック）を伝授します。これらを使いこなせば、あなたのプルリクエストは劇的に読みやすくなり、チームメンバーから「君のコードは追いかけやすいね」と一目置かれるようになるはずです。
準備はいいですか？ さあ、始めましょう。
—
1. なぜ「美しい履歴」にこだわるのか？
Gitを使い始めたばかりの頃は、とりあえず `git add .` して `git commit -m “update”` を繰り返してしまいがちです。しかし、そのままマージを繰り返すと、履歴はスパゲッティのように絡まり、どの変更がどの機能に対応しているのか、後から追うことが不可能になります。
- Merge（マージ）: 複数の歴史を「合流」させる。履歴に分岐と合流の跡が残る。
- Rebase（リベース）: 歴史を「作り直す」。土台を差し替えて、一直線の履歴を作る。
CI/CDの観点からも、履歴が一直線であることは非常に重要です。不具合が発生した際、どのコミットが原因かを特定する `git bisect`（二分探索）の精度が飛躍的に高まるからです。
—
2. 土台を整える：Gitの基本セットアップ
まずは、プロとして恥ずかしくない基本設定を済ませましょう。ターミナル（CLI）を開いてください。
ユーザー名とメールアドレスの設定（これがコミットの署名になります）
git config –global user.name “Your Name”
git config –global user.email “your-email@example.com”
エディタの設定（rebase -i で使用します。VS Code派なら code –wait）
git config –global core.editor “vim”
ログを見やすくするエイリアス（これだけで世界が変わります）
git config –global alias.graph “log –graph –date=short –decorate –pretty=format:’%C(yellow)%h%Creset %C(magenta)%ad%Creset%C(auto)%d%Creset %s %C(cyan)@%an%Creset'”
これで、`git graph` と打つだけで、歴史の分岐が美しくカラー表示されるようになります。
—
3. 歴史を書き換える魔術：`git rebase`
仕組み：土台のすり替え
あなたが `feature` ブランチで作業している間に、本流の `main` ブランチが更新されたとしましょう。ここで `merge` を使うと「Merge branch ‘main’ into feature」という余計なコミットが残ります。
`rebase` を使うと、あなたの変更を一度「脇に退避」させ、`main` の最新状態の上に、一つずつコミットを「積み直し」ます。
実践：対話的リベース（interactive rebase）
これが今回の真打ちです。「細かいコミットを一つにまとめたい」「コミットメッセージを修正したい」という時に使います。
最新の3つのコミットを整理する場合
git rebase -i HEAD~3
実行するとエディタが開き、以下のようなリストが表示されます。
pick a1b2c3d 機能Aの実装
pick e5f6g7h typo修正（消したい）
pick i9j0k1l 機能Aのテスト追加
Rebase 1234567..i9j0k1l onto 1234567
Commands:
p, pick
s, squash
r, reword
ここで `e5f6g7h` の `pick` を `s` (squash) に書き換えて保存すると、2番目のコミットが1番目に吸収されます。これで、「動作確認中の細かいゴミコミット」を消し去り、完璧な一つの成果物として歴史を整えることができるのです。
—
4. 欲しい実だけを摘み取る：`git cherry-pick`
仕組み：特定のコミットの移植
「別のブランチで書いたあのバグ修正だけ、今すぐこっちのブランチに持ってきたい」という場面があります。ブランチごとマージすると余計な機能まで入ってしまいます。
そんな時、`cherry-pick` は特定のコミット（実）だけを摘み取って、現在のブランチに適用します。
実践：特定のコミットを狙い撃つ
1. 欲しいコミットのハッシュ値を特定（git graphを活用）
git graph
2. そのコミットだけを適用
git cherry-pick a1b2c3d
これで、必要な修正だけが魔法のように現在のブランチに再現されます。
—
5. 現場で震えるほど役立つ「運用の鉄則」
これらの強力な武器を使いこなすために、私が現場で守っている3つの鉄則を共有します。
① 共有済みのブランチでは絶対に `rebase` しない
`rebase` は歴史を書き換えます。すでに GitHub 等に push し、他の人が作業ベースにしているブランチで `rebase` を行うと、他の人の環境で歴史の不整合（コンフリクトの嵐）が起き、チームが崩壊します。「Rebaseは自分の手元（ローカル）だけで完結させる」のが鉄則です。
② コミットは「意味のある最小単位」で
`rebase` でまとめられるからといって、何でもかんでも一気にやるのは禁物です。「ログイン機能の実装」と「ロゴの画像差し替え」は分けるべきです。後で `cherry-pick` しやすくなるからです。
③ Pushする直前に `rebase -i` で整える
作業中は汚くても構いません。しかし、プルリクエストを送る直前に `rebase -i` を行い、レビューする人が読みやすいように物語を整理してください。それがプロの仕事です。
—
6. 動作確認：美しき「Hello World」
最後に、一連の流れを体験してみましょう。
1. 実験用リポジトリ作成
mkdir git-lesson && cd git-lesson
git init
2. 最初のコミット
echo “Hello” > file.txt
git add .
git commit -m “Initial commit”
3. 作業ブランチ作成
git checkout -b feature/cool-stuff
echo “Cool” >> file.txt
git commit -am “Coolな機能を追加”
4. 細かい修正（本来は一つにまとめたい）
echo “Fix typo” >> file.txt
git commit -am “fix: typo”
5. 歴史を整える
git rebase -i HEAD~2
(エディタで2番目を squash にし、メッセージを「Coolな機能を完璧に実装」に変更)
6. 確認
git graph
どうですか？ あなたのターミナルには、無駄な枝分かれのない、美しく整った一直線の歴史が表示されているはずです。
結びに代えて
Gitのコマンドを覚えることは、単なる操作の習得ではありません。それは「自分の思考を整理し、他者に伝える技術」を磨くことと同義です。
`rebase` と `cherry-pick` を使いこなせるようになったあなたは、もう初心者ではありません。自信を持って、その美しい履歴をチームに届けてください。毎日の開発が、驚くほどスムーズで心地よいものに変わることを約束します。
次は、この美しい履歴を前提とした「究極のCI/CDパイプライン」の世界でお会いしましょう。
Happy Committing!