Two green changes merged to a green main can produce a red main.

This is not a commonly known fact. Just to take an example of GitHub, this check is disabled by default:

> Require branches to be up to date before merging

> Whether pull requests targeting a matching branch must be tested with the latest code.

> Two green changes merged to a green main can produce a red main.

I'm sure this happens occasionally, but I've never experienced it, and it seems to be rare enough that it's not that big of a concern. Especially since it'll be easily remedied by either just fixing the error or just reverting one or both of the changes.

It's definitely an issue if you're treating main as 'good to deploy'. Also with more devs the chance of this happening is pretty good. Definitely want to enforce a branch is up to date before allowing merge (though with a lot of devs this can become difficult) not sure if there is some sort of merge/test pipeline solution out there.

It completely depends on your organization's merge volume and your codebase's complexity. I've seen it happen many times working on a large monolith. But requiring a passing integration branch build before merging to master, or a merge queue, solves that.

> Require branches to be up to date before merging

Because this really doesn't scale well with the number of developers.

For larger teams the solution is to use a merge queue, e.g. https://shopify.engineering/successfully-merging-work-1000-d...

I haven't tried it, but GitHub is now offering such feature in public-beta: https://github.blog/changelog/2023-02-08-pull-request-merge-...