【要約】「マージコミット」と「リベース」でチームが真っ二つに割れたが、血みどろの議論の末に結論が出た話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発チームにおいて、Gitの履歴管理手法を巡る意見の対立が発生した。新メンバーの加入を機に、運用方針が二分されたことが原因である。具体的には以下の課題に直面した。
- ・履歴の複雑化：mergeによるマージコミットの増大が、履歴の視認性を低下させている。
- ・歴史の改ざん：rebaseによるコミットの書き換えが、開発の事実を損なう懸念がある。
- ・運用コストの増大：運用論争がコードレビューを阻害し、開発スピードを低下させている。
// Approach
チームは、作業の性質に応じて手法を使い分けるハイブリッド運用を採用した。個人の作業空間とチームの共有空間を明確に分離するアプローチである。具体的なルールは以下の通りである。
- ・ローカルブランチの更新：git pull --rebase origin main を使用する。これにより、不要なマージコミットを排除し、履歴を直線的に保つ。
- ・本流への統合（小規模な変更）：GitHubの Squash and Merge を使用する。複数のコミットを1つに集約し、mainの履歴を簡潔にする。
- ・本流への統合（大規模な機能）：merge --no-ff を使用する。マージコミットを明示的に作成し、機能統合の文脈を保存する。
// Result
この運用ルールの制定により、チーム内の不毛な議論が解消された。開発者の心理的安全性が確保され、開発プロセスが正常化した。得られた成果は以下の通りである。
- ・開発体験（DX）の向上：個人の作業はrebaseで綺麗に保てる。
- ・履歴の品質維持：共有領域では、何がいつ統合されたかの事実が正確に残る。
- ・デバッグ効率の改善：履歴が整理され、git bisect 等による原因特定が容易になる。
Senior Engineer Insight
> 履歴の「美しさ」と「事実」のトレードオフを、スコープ（個人 vs 共有）で解決した点は極めて合理的である。大規模開発では、履歴の複雑化がデバッグコストに直結する。一方で、事実の欠落は障害発生時の調査を困難にする。本ルールは、個人の自由度を保ちつつ、リポジトリの健全性を維持する優れたプラクティスだ。チームの規模が拡大しても、この境界線さえ明確であれば、運用コストを低く抑えられるだろう。