GitLab「Merge Trains」で競合地獄に終止符を。並列マージを安全に自動化する極意
こんにちは。現場で泥臭いデプロイや競合トラブルと戦い続けている皆さん、お疲れ様です。
チーム開発で「Aさんの機能とBさんの機能がマージされた瞬間に競合した」「CIが通ったはずなのに、マージ後に壊れた」なんて経験、一度はありますよね？ 忙しいチームほど、この「マージ後の修正」で貴重な開発時間が削られていくものです。
今日は、そんな悪夢を解消し、「並列マージを直列の信頼性で実現する」GitLabの秘奥義、Merge Trains（マージトレイン）についてお話しします。これをマスターすれば、あなたのチームのデプロイ頻度は劇的に上がり、ストレスは驚くほど減ります。
—
1. Merge Trainsとは何か？――「待ち行列」による安全の担保
通常、GitLabでマージボタンを押すと、その瞬間のコードがチェックされます。しかし、同時に複数のマージが行われると、「Aがマージされた後の状態」を知らずに「B」をマージすることになり、結果として破壊が起きるのです。
Merge Trainsは、この問題を「キュー（行列）」によって解決します。
1. マージボタンを押すと、そのブランチは「列車（Train）」の最後尾に並ぶ。
2. 前の車両（他のマージ予定のコード）が正常にビルド・テスト完了した状態をベースに、自分のコードが結合・テストされる。
3. 全員がテストをパスした順番で、自動的にマージされる。
つまり、「マージ後の状態を事前にシミュレーションし、衝突を完全に排除する」という最強の安全装置なのです。
—
2. 最短で導入する：Merge Trainsの基本設定
まずは、あなたのGitLabリポジトリでこれを有効にする手順です。特別なインストールは不要。GitLabの設定を少し変えるだけです。
ステップ1：マージメソッドの変更
Merge Trainsは「Fast-forward merge」や「Merge commit」と組み合わせて使います。プロジェクト設定から以下を確認してください。
1. Settings > Merge requests に移動。
2. Merge method を「Merge commit with semi-linear history」または「Fast-forward merge」に設定。
- 現場の知見： 歴史を汚さず、かつ追跡可能な「Semi-linear history」を強く推奨します。
3. Enable Merge Trains にチェックを入れる。
ステップ2：CIパイプラインの調整（最重要！）
Merge Trainsを動かすには、`.gitlab-ci.yml` で「どの環境でテストするか」を定義する必要があります。
.gitlab-ci.yml
stages:
- test
Merge Trainsは「merged results」という特殊なパイプラインを使用します
test:
stage: test
script:
- echo “テスト実行中…”
- ./run-tests.sh
rules:
# マージリクエストが発生している時のみ実行
- if: $CI_PIPELINE_SOURCE == “merge_request_event”
—
3. HelloWorld的・動作確認：本当に安全か確かめる
設定ができたら、以下の手順で動作を確認してみましょう。
1. 2つのMRを作成する： 同じファイルの一部を書き換えるMRを2つ用意します。
2. 同時にマージボタンを押す：
- 1つ目のMRが「Trainに並びました」と表示されます。
- 2つ目のMRが「Trainの2両目に並びました」と表示されます。
3. 結果を観察する：
- 1つ目がCIをクリアすると自動でマージされます。
- 2つ目が「1つ目がマージされた後のコード」に対してCIを開始します。
これで、競合があれば2つ目のMRがCIで失敗し、自動的に「マージ不可」となります。マージしてから壊れる、という悲劇が物理的に不可能になるのです。
—
4. 現場で震えるほど役立つ「極限の最適化」テクニック
Merge Trainsを導入する際、初心者が陥りがちな罠と、それを回避するプロの知見を授けます。
① CIの実行時間を削る（重要）
Merge Trainsはテストを何度も回すため、CIが重いと「列車」が全く進みません。
- 知見： 重いテストはキャッシュ戦略（`cache:key`）を極め、不要なユニットテストは「並列実行（Parallelism）」で時間短縮してください。CIが遅いとMerge Trainsはただの足枷になります。
② 「マージコミット」の可読性を保つ
Merge Trainsは自動でコミットを生成します。ログが複雑にならないよう、マージ設定で「Squash commits」を併用しましょう。これで、メインブランチには「機能単位の綺麗なコミット」だけが残ります。
③ 失敗時のトリアージ
列車が脱線（CI失敗）したとき、GitLabは自動的にそのMRをキューから外します。
- 知見： 「なぜ失敗したのか」をMRのステータスから即座に判断できるよう、失敗したテスト結果はArtifactとして保存し、Slack通知と連携させましょう。
—
最後に：なぜこれが必要なのか
エンジニアにとって最も価値があるのは「コードを書いている時間」であり、「競合を解決してGitと格闘する時間」ではありません。
Merge Trainsは、単なる自動化ツールではありません。「チーム全員が、他人の作業を恐れずにマージできる」という心理的安全性を担保するためのインフラです。
これを導入すれば、あなたのチームは「競合チェック」という無駄な儀式から解放され、より本質的なプロダクト改善に集中できるはずです。さあ、今すぐ設定をONにして、チームの生産性を一段上のステージへ引き上げてください。
応援していますよ。何か詰まったら、いつでも聞いてくださいね。