📚 Git＆GitHub目次
📖 各種目次
🔀 GitHubマージ方法の比較
トピックブランチをベースブランチにマージする3つの方法
1. Create a merge commit（マージコミット作成）
📝 特徴
トピックブランチの全てのコミット履歴を保持し、新しいマージコミットを作成してベースブランチに統合します。
マージ前:
main A---B---C
\
feature D---E---F
⬇️
マージ後:
main A---B---C-------M
\ /
feature D---E---F---/
M = マージコミット
✅ メリット
- 完全な履歴が保持される
- 機能開発の文脈が明確
- revertが容易
- 誰がいつ何を統合したかが分かる
❌ デメリット
- 履歴が複雑になる
- マージコミットが増える
- bisectが困難な場合がある
🎯 適用場面
チーム開発で機能ブランチの開発過程を記録したい場合、複雑な機能開発で履歴の追跡が重要な場合
2. Squash and merge（スカッシュマージ）
📝 特徴
トピックブランチの全てのコミットを1つにまとめ（スカッシュ）、新しいコミットとしてベースブランチに追加します。
マージ前:
main A---B---C
\
feature D---E---F
⬇️
マージ後:
main A---B---C---G
feature ブランチは削除される
G = D+E+Fをまとめた新しいコミット
✅ メリット
- シンプルで直線的な履歴
- 機能単位でのコミット
- bisectが簡単
- 細かいコミットが隠される
❌ デメリット
- 開発過程の履歴が失われる
- 個別のコミットがrevertできない
- 元のコミット作成者情報が曖昧
🎯 適用場面
機能単位での管理を重視する場合、きれいな履歴を維持したい場合、小規模な修正やバグフィックス
3. Rebase and merge（リベースマージ）
📝 特徴
トピックブランチのコミットをベースブランチの最新状態にリベースしてから、Fast-forwardマージを実行します。
マージ前:
main A---B---C
\
feature D---E---F
⬇️
マージ後:
main A---B---C---D'---E'---F'
feature ブランチは削除される
D', E', F' = リベースされた新しいコミット
✅ メリット
- 直線的で綺麗な履歴
- 各コミットが独立して存在
- 個別のコミットがrevert可能
- bisectが最も簡単
❌ デメリット
- コミットハッシュが変更される
- マージの文脈が失われる
- コンフリクト解決が複雑な場合がある
🎯 適用場面
直線的な履歴を重視する場合、各コミットを個別に管理したい場合、オープンソースプロジェクト
📊 選択の指針
🔄 Merge Commit
履歴の追跡性を重視するプロジェクト
🎯 Squash and Merge
機能単位での管理を重視するプロジェクト
📈 Rebase and Merge
綺麗な直線履歴を重視するプロジェクト
