Gitの履歴操作
チームによってGitの履歴操作のルールは違います。
代表的な３つのGitの履歴操作方法を紹介します。
最後に注意点も記述しているのでお見逃しなく。
1. merge
他のブランチの変更をそのまま統合する方法で、マージコミットを生成し、履歴がそのまま保持されます。
Pro
- 履歴をそのまま保持できる
- 各ブランチでの変更が明確に分かる
- 他のメンバーと協力して作業しているときに安全
- 履歴にマージコミットが残るので、どのタイミングで統合されたかが分かりやすい
Con
- マージコミットが増えて履歴が複雑になる
- 履歴が直線的にならず、ブランチが混ざる
- 履歴が冗長になることがある（無駄なマージコミットが増える）
2. rebase
他のブランチの変更を自分のブランチの先頭に適用する方法で、履歴を直線的に整理できますが、履歴が書き換えられます。
Pro
- 履歴が直線的になり、理解しやすくなる
- マージコミットが生成されないため、履歴がすっきりする
- 履歴が一貫しているので、後からの追跡が容易
- 自分の作業ブランチを最新のリモートに合わせて整理できる
Con
- 履歴が書き換えられるため、公開後にリベースを行うと問題が生じる可能性がある
- 初心者には操作が少し難しい（特にコンフリクト時）
- 他のメンバーと共有した後にリベースを行うと、履歴が混乱する可能性がある
3. squash
複数のコミットを1つにまとめて、履歴を整理し、不要な中間コミットを排除します。
Pro
- 複数のコミットを1つにまとめて履歴を整理できる
- 細かいコミットが不要な場合にスッキリとまとめられる
- コードレビューがしやすくなる（1つのまとまったコミットでレビューできる）
- 無駄な中間コミットを履歴から排除できる
Con
- 各コミットの詳細が失われ、履歴が単純化されすぎる可能性がある
- 履歴の透明性が低下し、後から変更の理由や流れを追いづらくなることがある
- 途中の変更がまとめられるので、どの段階でどんな作業をしたかが分かりにくくなる
注意点
コミット履歴を直線的（linear）にしたいならば、rebaseやsquashが推奨されますが、上記のproとconの記載通り注意しないといけない点があります。
それはrebaseするとコミット履歴が書き換えられるという点です。
どういうことかというと以下の図の通りです。
一度プッシュされたブランチでrebaseしてしまうと、remoteとlocalのリポジトリでコミットの不一致が起きます。他のメンバーがそのブランチで作業しているならなお最悪です。
そのためrebaseをする際は十分に注意を払い、既にプッシュされたブランチではrebaseは行わないというルールを設けましょう。