The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Verify |
| Maturity | Viable |
| Content Last Reviewed | 2025-05-16 |
Thanks for visiting this category direction page on Merge Trains in GitLab. This page belongs to the Pipeline Execution group of the Verify stage and is maintained by Rutvik Shah (E-Mail).
This direction page is a work in progress, and everyone can contribute:
We aim to help you balance speed with reliability, keeping your pipelines green. This ultimately supports the stability of collaboration across branches and GitLab has introduced Merge Trains as the mechanism to accomplish this. When merge trains are used, each merge request joins as the last item in that train. Each merge request is processed in order and is added to the merge result of the last successful merge request. The merge request adds its changes, and starts the pipeline immediately under the assumption that everything is going to pass. If the merge request fails, it is kicked out of the train and the next merge request continues the pipeline of the last successful merge result.
For FY26 (ending February 2026):
We will be maintaining our Merge Trains functionality with a focused approach:
This strategic decision allows us to strengthen the core functionality while ensuring a dependable experience for current users.
We have currently scheduled investigation for a bug that causes MRs to be marked as "merged" while their commits are missing from the target branch for Fast Forward merges
No features or bug fixes were shipped in last 3 months.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
This category is currently at the "Viable" maturity level, and our next maturity target is "Complete" (see our definitions of maturity levels. We currently have basic capabilities and want to continue and extend these in future milestones.
Key deliverables to achieve this are:
GitLab pioneered Merge Train functionality for CI/CD establishing early market leadership. While there are multiple solutions offering similar capabilities, GitLab's solution offers a more mature implementation that has been proven scalable for large development teams and complex CI/CD workflows.
GitHub's Merge Queue is a feature that automates the process of merging pull requests into a repository by placing them in a queue and running checks against the latest version of the codebase.
Aviator is the most comparable offering against Merge Trains, promising to "keep builds green forever", much like how we positioned Merge Trains in 2020 during their release.
marge-bot is a popular open source program that works with GitLab to manage merge requests.
Mergify is another offering that integrates with GitHub repositories and multiple CI providers to supporty queued pull requests.
Graphite offers similar capabilities as Merge Trains
Check out our Ops Section Direction "Who's is it for?" for an in depth look at the our target personas across Ops. For Merge Trains, our "What's Next & Why" are targeting the following personas, as ranked by priority for support:
In an effort to dogfood our own features, we are actively working on using merge trains internally on gitlab-org.