 A large percentage of a developer's day is spent on updating their branches and rebasing. They are essentially racing their teammates to get their merge requests merged. You added a change and now your merge request is ready for merge. Your pipeline is green, but when you merge it with the target branch, the target branch may have already changed. Merging now could introduce breaking changes to the target branch. GitLab has a powerful feature, merge trains, that always keeps the target branch green. With merge trains enabled, a merge request can be added to the train, which takes care of it until merged. A merge train can be imagined as a queue of MRs that is automatically managed for you. The train ensures that only green merge requests will be merged to the target branch. If a red merge request is detected in the train, it is removed from the train, and pipelines run again on all remaining merge requests to ensure they are green. Let's see a merge train example. Three merge requests, A, B, and C, are added to a merge train in order, which creates three merged results pipelines that run in parallel. The first pipeline runs on the changes from A combined with the target branch. The second pipeline runs on the changes from A and B combined with the target branch. The third pipeline runs on the changes from A, B, and C combined with the target branch. If the pipeline for B fails, it is removed from the train. The pipeline for C restarts with the A and C changes, but without the B changes. If A then completes successfully, it merges into the target branch, and C continues to run. If more merge requests are added to the train, they now include the A changes that are included in the target branch and the C changes that are from the merge request already in the train. To summarize, when the target branch fails, teams are in a panic, and until this is resolved, developers might be on hold for a few hours. Merge trains solves this situation and keeps your main branch always green.