DevOps Server のGitリポジトリのマージの種類ごとの動作について紹介します。

概要

Gitリポジトリでプルリクエストを完了しブランチをマスターに合流させる際にマージをしますが、Gitリポジトリのマージの種類を選択できます。 マージの種類による動作の違いを紹介します。

マージ (早送りなし)

「すべてのコミットを保持する非線形履歴」との説明があります。

ブランチ(青線)が下図の場合


マージをするとブランチがマージされて新しいマージコミット（下図の青丸）が作成されます。
マージコミットには変更情報は含まれず、変更内容は元のブランチのコミットが使われます。


ブランチのコミットがそのまま使われるため、変更の記録がすべて残り追跡や履歴を細かく調べられます。また、ブランチを削除した場合でもブランチ先にブランチでのコミット情報が残るため、ブランチの削除後にもコミット内容を参照することができます。
一方で、「非線形履歴」となるため、ツリーのグラフは複雑になります。

スカッシュ コミット

「ターゲットへのコミットが一つだけの線形履歴」との説明があります。

ブランチ(青線)が下図の場合


スカッシュコミットをすると、ブランチのマージがすべて一つのコミットに集約されます。


マージ先にコミットが作成され、集約されたコミットが実行されます。


変更内容がマージ先に作成されますので、線形の履歴となるのでツリーのグラフはシンプルになり閲覧性は良くなります。 ブランチでのコミット履歴もブランチを削除しなければ参照可能ですが、ブランチを削除した場合はコミット履歴を参照できなくなります。 また、マージの記録は残りますが、マージ先のブランチではブランチでのコミットを分解できないため、ブランチでのコミットのある時点に戻ることができません。

リベースと早送り

「ターゲットへのソースコミットをリベースし、早送りする」との説明があります。

ブランチ(青線)が下図の場合


最初にリベースが実行され、ブランチの分岐がマージ先の先頭からの分岐に変わります。


マージコミットは作成されず、ブランチにも変更は発生しません。


このマージ方法の場合コミットがマージ先にさし変わるため、履歴が一本になりグラフがシンプルになり閲覧性が良くなります。 一方でリポジトリの状態によってはリベースができない場合があるため、操作が実行できない場合があります。

半線形マージ

「ターゲットへのソースコミットをリベースし、2つの親のマージを作成する」との説明があります。

リベースとマージを組み合わせた動作になります。
ブランチ(青線)が下図の場合


最初にリベースが実行され、ブランチの分岐がマージ先の先頭からの分岐に変わります。


次に、リベースされたプルリクエストがマージ先にマージされます。


子のマージの方法の場合、グラフは一本にはなりませんが変更履歴は線形になり、履歴の閲覧性は良くなります。また、ブランチが発生したこともマージ先で確認でき、それぞれのコミットを参照することもできます。