Gitの履歴は「アート」である：RebaseとCherry-pickで紡ぐ、極限のクリーン・ヒストリー術
エンジニアにとって、Gitのコミット履歴は単なる作業ログではない。それは「プロジェクトの進化の軌跡」という名のドキュメントだ。
履歴がスパゲッティのように絡まり、マージコミットが乱立するリポジトリは、バグの温床であり、デバッグの難易度を倍増させる。今日は、現場のテックリードとして、私がチームに叩き込んでいる「Gitを自由自在に操り、歴史を美しく保つための極限技術」を伝授する。
—
1. なぜ「一直線」にこだわるのか？
マージコミットの嵐（`Merge branch ‘main’ into …`）は、コードの追跡可能性を破壊する。我々が目指すべきは、リニアな履歴だ。
Rebaseの真髄：過去を書き換えるのではなく「再定義」する
`git merge` は歴史を保存するが、`git rebase` は歴史を再構築する。
機能ブランチの開発中、`main`が進んだら迷わず `rebase` を使え。
鉄則：作業ブランチでこれを叩く
git fetch origin
git rebase origin/main
これにより、あなたの作業は「常に最新のmainの先端から開始された」かのように配置される。コンフリクト解決は一度で済み、ログを `git log –oneline –graph` で見た時、一本の美しい線が浮かび上がるはずだ。
—
2. Cherry-pick：外科手術のように必要な変更だけを抽出する
「Aブランチのあの機能だけ欲しいが、Bブランチ全体をマージするとゴミが混ざる」。そんな時は `cherry-pick` の出番だ。
実践的活用：デプロイ事故の個別修正
Hotfixを特定のブランチにだけ適用したい時、あるいは実験的な機能を本流から切り出したい時、`cherry-pick` は最も安全なメスとなる。
特定のハッシュだけを現在のブランチに適用
git cherry-pick
コンフリクトが怖い？それなら -n (no-commit) オプションだ
git cherry-pick -n
これで一度ステージングに上がり、内容を確認してからコミットできる
—
3. 開発スピードを加速させる「神・設定」と隠し芸
現場の生産性を劇的に上げるには、CLIを「自分の手足」にする必要がある。
必須の `.gitconfig` 設定
以下の設定を `.gitconfig` に入れることで、操作ミスを減らし、視認性を最大化する。
[alias]
# ログを美しく表示する（必須）
lg = log –color –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit
# 強制プッシュの事故を防ぐ（–force-with-lease は絶対条件）
pushf = push –force-with-lease
# 直前のコミットを修正する手間を省く
fix = commit –amend –no-edit
[rebase]
# rebase時に自動でスタッシュを適用する（神機能）
autostash = true
[pull]
# rebaseをデフォルトにして、マージコミットを撲滅する
rebase = true
必携プラグイン：`fzf` でGit操作を爆速にする
[fzf](https://github.com/junegunn/fzf) を使って、ブランチ切り替えやログ検索をコマンドラインで完結させろ。
fzfを使ったブランチ切り替え（aliasに設定推奨）
git checkout $(git branch | fzf)
これだけで、数千あるブランチの中から瞬時に目的の作業場所に到達できる。
—
4. チームを統率する「コミット・エチケット」
ツールを知っていても、運用が乱れれば意味がない。チームで合意しておくべきルールは以下の通りだ。
1. コミット単位は「機能」単位：`git add -p` を使い、変更点を論理的に分割せよ。
2. コミットメッセージは「命令形」で：`Add user authentication` のように、「何をしたか」を短く記載する。
3. マージ前にRebase：共有リポジトリにプッシュする前に、必ず最新の `main` で `rebase` すること。
4. `–force-with-lease` の徹底：`–force` は禁忌だ。共有ブランチを破壊しないために、必ず `lease` を使う。
—
最後に：なぜそこまでやるのか？
「動けばいい」というコードは、数ヶ月後に負債となる。しかし、「美しく整理された履歴」を持つコードは、後から来たメンバーの理解を助け、CI/CDパイプラインの安定性を担保し、何より障害発生時の原因特定スピードを劇的に高める。
Gitを単なる保存場所ではなく、「コードの歴史を設計するキャンバス」として扱え。そのこだわりが、あなたの書くコードの品質、ひいてはエンジニアとしての価値を決定づけるのだから。
さあ、今すぐ `git lg` を叩いて、君の現在のリポジトリを覗いてみてくれ。そこに未来の成功が見えるか？ それとも混沌があるか？ 答えは、君の指先にある。