はじめに

きれいな履歴にこだわりすぎない

直線的な履歴にこだわる必要はない。merge だけで安全にチーム開発できる理由

履歴が多くて困ることは基本的にない

git log --graph でマージの分岐が見えると「履歴が汚い」と感じるかもしれません。

しかし、履歴が多くて困ることは基本的にありません。

Git は膨大な履歴を扱う前提で設計されています。

Linux カーネルのリポジトリには 100 万以上のコミットがありますが、日常の操作に支障はありません。

分岐が気になるときは表示側で絞り込めば十分です。

bash

# 分岐を省略して直線的に表示
git log --oneline --first-parent

# 最新 20 件だけ
git log --oneline -20

rebase と cherry-pick はコミットハッシュが変わる操作です。

そのため以下のリスクがあります。

リスク	説明
force push が必要	プッシュ済みブランチをリベースすると `--force-with-lease` が必要になる
チームの履歴と不整合	他のメンバーが同じブランチを使っていると混乱を招く
コンフリクト解決が増える	リベースはコミット1つずつ再適用するため、同じ競合を何度も解くことがある

「履歴をきれいにする」メリットに対して、これらのリスクは割に合わないことが多いです。

チーム開発で必要なブランチ操作は merge だけでほぼカバーできます。

rebase や cherry-pick が必要になる場面は実際にはまれです。

特別な理由がない限り、安全な merge を選んでおけば間違いありません。

具体的な手順は 3-way マージを避けるブランチ運用を参照してください。