プログラムのコード管理をAWSのCodeCommitで実施することが多いのですが、プルリクに対するマージ処理を正しく理解しておこうと思い、以下の3種類のマージ方法について少し調べてみました。
（ついでにプルリクの処理手順もまとめています。）
- 早送りマージ
- スカッシュマージ
- 3方向マージ
参考文献
コンソール上でのプルリク処理の流れ
プルリクの作成
| No | 画面 | 備考 |
|---|---|---|
| AWSコンソール上でCodoCommitを開いている前提です | ||
| 1 |  |
プルリクエストの作成を選択 |
| 2 |  |
ターゲット、ソースを選択してから比較を実施ソース：更新済みのブランチターゲット：更新を取り込みアップデートするブランチ |
| 3 |  |
説明等を記載してからプルリクの作成を実施 |
| 4 |  |
プルリクの作成ができました |
ブランチの関係
ソース：更新済みのブランチターゲット：更新を取り込みアップデートするブランチ
プルリクのマージ処理の実施
| No | 画面 | 備考 |
|---|---|---|
| 1 |  |
|
| 2 |  |
1.マージ戦略を選択します2. ソースブランチの削除の有無を選択します |
ここでは早送りマージを選択 |
||
| 3 |  |
成功しました。 |
2.でソースブランチの削除の有無を選択しますが、複数のブランチへマージを実施する想定が無い場合は削除するべきです。
- ブランチが多いと、プルリク作成時にターゲットブランチやソースブランチを探す際に視認性が低下します。
- 別途、手作業でブランチを削除することもできますが、後でブランチ一つづつに対し「削除可能か？」等を判断するのが手間になることが多いです。
マージ戦略の比較
| No | 名称 | コマンド |
|---|---|---|
| 1 | 早送りマージ | merge-branches-by-fast-forward |
| 2 | スカッシュマージ | merge-branches-by-squash |
| 3 | 3方向マージ | merge-branches-by-fast-forward |
AWSのCodeCommitコンソール上では以下のように表示されています。
AWSの CodeCommitコンソール上の表示
実際に3種類のマージを実施した際のブランチツリーがいかになります。
gitのブランチツリーでの見え方 
早送りマージ
コマンドフォーマット
aws codecommit merge-branches-by-fast-forward --source-commit-specifier (ソースブランチ名) --destination-commit-specifier (ターゲットブランチ名) --repository-name MyDemoRepo (リポジトリ名)
特徴
オプション設定が少ないことからもわかるように、あまり記録が残らない方法。
イメージ
ソースブランチが通ったルート上を通ってターゲットブランチを進める（ターゲットブランチがソースブランチに追いつく）？
スカッシュマージ
コマンドフォーマット
aws codecommit merge-branches-by-squash --source-commit-specifier (ソースブランチ名) --destination-commit-specifier (ターゲットブランチ名) --author-name "(マージ担当者の名前)" --email "(マージ担当者のメールアドレス)" --commit-message "(マージに関する説明)" --repository-name MyDemoRepo (リポジトリ名)
特徴
- ターゲットブランチ上の複数のコミットをまとめた新しいコミットが作成される
- 作成された新しいコミットが、ターゲットブランチのみにマージされる
- ターゲットブランチとソースブランチは別々のルートを進む（合流することはない）
イメージ
- ソースブランチ上に複数のコミットがあるときに、コミットを1つにまとめたうえでターゲットブランチに渡す
3方向マージ
コマンドフォーマット
aws codecommit merge-branches-by-fast-forward --source-commit-specifier (ソースブランチ名) --destination-commit-specifier (ターゲットブランチ名) --author-name "(マージ担当者の名前)" --email "(マージ担当者のメールアドレス)" --commit-message "(マージに関する説明)" --repository-name MyDemoRepo (リポジトリ名)
特徴
- ターゲットブランチとソースブランチは最後に合流する
イメージ
- ソースブランチ上の更新がターゲットブランチに引き継がれる
まとめ
プルリクの処理手順とマージ戦略による違いを簡単にまとめてみました。- 個人的には「どこからマージされたか？誰がマージしたか？」が一目瞭然な
3方向マージが好きですが、線が複雑になりがちなので好まない人もいると思います。- git上でのプログラムの管理（ブランチ戦略、マージ戦略）はチーム等で様々で良いと思いますが、チーム内では統一されていないと見ずらいですね。
