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 | 2024-01-23 |
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 an overview of our plans for Merge Trains, see epic Merge Trains Vision and check out this overview video:
Our top vision item is Merge Trains should support fast forward merge as this will eliminate the frequent need for manually rebasing. We have heard from many developers that a large portion of their day is dedicated to this activity, and with this functionality, Merge Trains will take care of this for them.
Beyond that we want to provide Developers and DevOps Engineers a better way to visualize and administer the merge train.
In FY24, we plan to proceed with work to enable Fast-forward merge support for merge trains. We have heard from users that while Merge Trains are great they often need to re-run the same pipeline to get the correct SHA value into a package prior to release. Reducing the number of pipelines required to merge a change by one means shipping value to customers faster.
Besides continuing our work on adding support for fast forward and semi-linear merge method for merge trains, we are conducting a research study to improve Merge Trains usability.
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:
It looks like GitLab is the first to provide this functionality, although GitHub has annouced a public beta for Merge Queue which includes fast-forward merge train support and visualizations of the queue.
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. Today, Merge Queues seem to support parity of Merge Trains for GitHub repositories.
Mergify is another offering that integrates with GitHub repositories and multiple CI providers to supporty queued pull requests.
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:
The most popular request is the epic gitlab&4911. When selecting to work with Fast Forward Merge without using merge trains, a user is offered to rebase master manually, in case master has advanced. Merge Train supporting fast forward merge would reconstruct the merge train and re-run pipelines automatically.
In an effort to dogfood our own features, we are actively working on using merge trains internally on gitlab-org gitlab#195. A piece of functionality our internal team has requested after working with Merge Trains for a while is API support for merge trains to auto-merge, gitlab#32655.