Azure DevOps Git リポジトリの Pull Request をマージする際、マージのやりかたが４種類あります。それらの使い分けと注意事項をメモ。
Merge types の種類
Complete, abandon, or revert pull requests のところに説明がありますが、Merge type には以下の4種類があります。
- Basic merge (no fast-forward)
- 常に merge commit を作ります。fast-forward はしません。すべての commit は維持されます。
- Squash merge
- 全コミットを1コミットに squash します。ブランチは直線になります。
- Rebase and fast-forward
- リベースして fast-forward します。ブランチは直線になります。
- Rebase with merge commit
- リベースしますが、マージするときに merge commit を作ります。
困ること
ここでちょっと困るのは、Git のデフォルトのマージ戦略が無いということです。
Git のデフォルト戦略は、「fast-forward 可能なら fast-forward するが、そうでない場合は merge commit を作る」です。これと同じことは Azure DevOps ではできません。
なので、同じことをしたいなら、「Basic merge」か「Rebase and fast-forward」のいずれかを人間が判断して決めなければなりません。はっきり言ってくそ面倒です。
このポリシ作ってよ ＞Microsoftさん
使い分け方針
これはプロジェクトごとに方針が異なると思います。できるだけブランチを直線にしたいなら「Rebase and fast-forward」を中心に使うことになりますし、逆にこれを気にせず常にマージコミット作りたいなら「Basic merge」を使うことになります。
私はできるだけブランチを直線にしたいので、以下のような方針を取っています。ちなみに採用している Git ブランチ戦略は、git-flow です。
- feature ブランチをマージするときは「Rebase and fast-forward」
- develop ブランチを main ブランチにマージするようなケースは「Basic merge」