マージ方法

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

プロジェクトに選択するマージ方法は、マージリクエストの変更を既存のブランチにマージする方法を決定します。

このページの例では、コミットA、C、Eを含むmainブランチと、コミットB、Dを含むfeatureブランチを想定しています。

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
   accTitle: Diagram of a merge
   accDescr: A Git graph of five commits on two branches, which will be expanded on in other graphs in this page.
   commit id: "A"
   branch feature
   commit id: "B"
   commit id: "D"
   checkout main
   commit id: "C"
   commit id: "E"

プロジェクトのマージ方法を設定する

上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
設定 > マージリクエストを選択します。
これらのオプションから、目的のマージ方法を選択します。
- マージコミット
- 半線形履歴によるマージコミット
- 早送りマージ
マージ時にコミットをスカッシュするで、コミットを処理するデフォルトの動作を選択します。
- 許可しない: スカッシュは実行されず、ユーザーは動作を変更できません。
- 許可: スカッシュはデフォルトでオフになっていますが、ユーザーは動作を変更できます。
- 推奨: スカッシュはデフォルトでオンになっていますが、ユーザーは動作を変更できます。
- 必須: スカッシュは常に実行され、ユーザーは動作を変更できません。
変更を保存を選択します。

マージコミット

デフォルトでは、ブランチがmainにマージされると、GitLabはマージコミットを作成します。コミットがマージ時にスカッシュされるかどうかに関係なく、個別のマージコミットが常に作成されます。この方法では、スカッシュコミットとマージコミットの両方がmainブランチに追加される可能性があります。

マージコミット戦略を使用する場合、これらの図は、featureブランチがmainにどのようにマージされるかを示しています。これらはコマンドgit merge --no-ff <feature>と同等であり、GitLab UIでMerge commitをマージ方法として選択します:

フィーチャーブランチがマージコミットメソッドでマージされた後、mainブランチは次のようになります。

%%{init: { 'gitGraph': {'logLevel': 'debug', 'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main', 'fontFamily': 'GitLab Sans'}} }%%
gitGraph
   accTitle: Diagram of a merge commit
   accDescr: A Git graph showing how merge commits are created in GitLab when a feature branch is merged.
   commit id: "A"
   branch feature
   commit id: "B"
   commit id: "D"
   checkout main
   commit id: "C"
   commit id: "E"
   merge feature

比較すると、スカッシュマージは、featureブランチからのすべてのコミットの仮想コピーであるスカッシュコミットを作成します。元のコミット（BおよびD）はfeatureブランチで変更されずに残り、次にスカッシュされたブランチにマージするためにmainブランチでマージコミットが作成されます。

%%{init: { 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main', 'fontFamily': 'GitLab Sans'}} }%%
gitGraph
   accTitle: Diagram of of a squash merge
   accDescr: A Git graph showing repository and branch structure after a squash commit is added to the main branch.
   commit id:"A"
   branch feature
   checkout main
   commit id:"C"
   checkout feature
   commit id:"B"
   commit id:"D"
   checkout main
   commit id:"E"
   branch "B+D"
   commit id: "B+D"
   checkout main
   merge "B+D"

スカッシュマージグラフは、GitLab UIのこれらの設定と同等です。

マージ方法: マージコミット。
マージ時にコミットをスカッシュは、次のいずれかに設定する必要があります:
- 必須。
- 許可または推奨のいずれかで、スカッシュはマージリクエストで選択する必要があります。

スカッシュマージグラフは、これらのコマンドとも同等です。

git checkout `git merge-base feature main`
git merge --squash feature
git commit --no-edit
SOURCE_SHA=`git rev-parse HEAD`
git checkout main
git merge --no-ff $SOURCE_SHA

半線形履歴によるマージコミット

マージごとにマージコミットが作成されますが、ブランチは早送りマージが可能な場合にのみマージされます。これにより、マージリクエストビルドが成功した場合、マージ後もターゲットブランチビルドが成功することが保証されます。このマージ方法を使用して生成されたコミットグラフの例:

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Diagram of a merge commit
  accDescr: Shows the flow of commits when a branch merges with a merge commit.
  commit id: "Init"
  branch mr-branch-1
  commit
  commit
  checkout main
  merge mr-branch-1
  branch mr-branch-2
  commit
  commit
  checkout main
  merge mr-branch-2
  commit
  branch squash-mr
  commit id: "Squashed commits"
  checkout main
  merge squash-mr

Merge commit with semi-linear historyメソッドを選択してマージリクエストページにアクセスすると、早送りマージが可能な場合にのみ受け入れることができます。早送りマージが不可能な場合、ユーザーにはリベースのオプションが与えられます。（半）線形マージ法でのリベースを参照してください。

この方法は、マージコミットメソッドと同じGitコマンドと同等です。ただし、ソースブランチがターゲットブランチの最新ではないバージョン（mainなど）に基づいている場合は、ソースブランチをリベースする必要があります。このマージ方法では、すべてのブランチがどこから始まり、マージされたかを確認できるようにしながら、よりクリーンな履歴を作成できます。

早送りマージ

場合によっては、ワークフローポリシーで、マージコミットのないクリーンなコミット履歴が義務付けられることがあります。このような場合、早送りマージが適切です。早送りマージリクエストを使用すると、マージコミットを作成せずにリニアなGit履歴を保持できます。

早送りマージは、ターゲットブランチ（mainなど）が、ソースブランチのベースコミットから分岐していない場合にのみ可能です。ターゲットブランチにソースブランチにない新しいコミットがある場合は、まずソースブランチをリベースする必要があります。

早送りマージ（--ff-only）設定が有効な場合、ブランチが早送りマージできる場合にのみマージが許可されます。早送りマージが不可能な場合は、リベースのオプションが提供されます。詳細については、(半線形)線形マージメソッドでのリベースを参照してください。

スカッシュなし

スカッシュが無効な場合、ソースブランチからのすべてのコミットは、個別のコミット履歴を維持したまま、直接ターゲットブランチに追加されます。

マージ前。mainがコミットAにあり、featureにコミットB、C、およびDが含まれる場合:

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Branch state before fast-forward merge
  accDescr: Shows main branch at commit A, with feature branch containing commits B, C, and D.
  commit id: "A (main)"
  branch feature
  commit id: "B"
  commit id: "C"
  commit id: "D"

早送りマージ後、mainはコミットDを指し、フィーチャーブランチからのすべてのコミットが含まれます:

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Result after fast-forward merge without squashing
  accDescr: Shows linear history with all individual commits B, C, and D now on main branch.
  commit id: "A"
  commit id: "B"
  commit id: "C"
  commit id: "D (main)"

この方法はgit merge --ff-only <source-branch>と同等です。

スカッシュあり

スカッシュが有効な場合、ソースブランチからのすべてのコミットは、まず単一のコミットに結合され、その後ターゲットブランチに早送りされます。

マージ前。mainがコミットAにあり、featureにコミットB、C、およびDが含まれる場合:

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Branch state before fast-forward merge with squashing
  accDescr: Shows main branch at commit A, with feature branch containing commits B, C, and D.
  commit id: "A (main)"
  branch feature
  commit id: "B"
  commit id: "C"
  commit id: "D"

スカッシュを伴う早送りマージ後、mainにはB、C、およびDからのすべての変更を含む単一のコミットが含まれるようになりました:

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Result after fast-forward merge with squashing
  accDescr: Shows linear history with commits B, C, and D combined into one squashed commit on main branch.
  commit id: "A"
  commit id: "B+C+D (main)"

この方法はgit merge --squash <source-branch>に続いてgit commitと同等です。

（半）線形マージ法でのリベース

これらのマージ方法では、ソースブランチがターゲットブランチで最新の状態になっている場合にのみマージできます。

半線形履歴によるマージコミット。
早送りマージ。

早送りマージは不可能だが、コンフリクトのないリベースが可能な場合、GitLabは以下を提供します。

/rebaseクイックアクション。
ユーザーインターフェースでリベースを選択するオプション。

両方の条件が当てはまる場合は、早送りマージの前にローカルでソースブランチをリベースする必要があります。

ターゲットブランチがソースブランチよりも先行しています。
コンフリクトのないリベースは不可能です。

スカッシュ自体がリベースと同等と見なされる場合でも、スカッシュの前にリベースが必要になる場合があります。

マージ前の自動リベース

この機能の利用は機能フラグによって制御されます。詳細については、履歴を参照してください。

半線形の履歴を持たせたマージコミットまたは早送りマージメソッドを使用する場合、マージ前の自動リベースを有効にできます。この設定が有効な場合、ソースブランチがターゲットブランチより遅れている場合、GitLabはマージ時に自動的にソースブランチをターゲットブランチにリベースします。手動でリベースしたり、リベースが完了するのを待ったりすることなく、マージできます。

サーバーサイドのリベースは、コミットからGPG署名を削除します。プロジェクトで署名されたコミットが必要な場合、自動リベースが適切かどうかを検討してください。

自動リベース:

元のソースブランチを変更せずに、ソースブランチのサーバーサイドリベースを作成します。
ターゲットブランチを早送りして、リベースされたコミットを含めます。
リベースされた結果に対してCI/CDパイプラインを再実行しません。
リベースがマージコンフリクトなしで完了できる必要があります。

自動リベース後にCI/CDパイプラインが再実行されないため、マージされた結果が前回のパイプライン実行と異なる場合があります。マージ前にリベースされた結果を検証するには、マージトレインを使用してください。

マージ前の自動リベースを有効にする

前提条件:

プロジェクトのメンテナーまたはオーナーのロール。
プロジェクトのマージ方法は、半線形の履歴を持たせたマージコミットまたは早送りマージに設定されている必要があります。

自動リベースを有効にするには:

上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
設定 > マージリクエストを選択します。
マージ方法セクションで、マージ前の自動リベースを有効にするを選択します。
変更を保存を選択します。

CI/CDパイプラインなしでリベース

CI/CDパイプラインをトリガーせずにマージリクエストのブランチをリベースするには、マージリクエストレポートセクションからパイプラインなしのリベースを選択します。

このオプションは:

早送りマージは不可能だが、コンフリクトのないリベースが可能な場合に使用できます。
パイプラインが完了しているオプションが有効になっている場合は使用できません。

CI/CDパイプラインなしでリベースすると、頻繁なリベースが必要な半線形ワークフローのプロジェクトでリソースを節約できます。

スカッシュとマージ