正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

マージ方法

  • プラン: 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"

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

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

マージコミット

デフォルトでは、ブランチが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は以下を提供します:

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

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

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

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

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

このオプションは:

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

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