This message was deleted.

In the last 4 or so jobs I've worked, which all used git, this is how people developed. A single main/master/mainline branch and pushing to it triggers the start of a partially automatic (rarely fully automatic) pipeline. The end of the pipeline is a production deployment. Development is done on short lived branches which when ready you create a pull request or code review. Passing code review lets you merge to main or the trunk. This is sometimes enforced but if not it's expected. I will admit there are rare exceptions with a few services or clients when branches exist for different environments / stages like beta or stage or production. Those are part of the pipeline roll out or deployment up to production. I and most developers I've worked with really don't like this non trunk based development approach but often the choice was made before any current developers were here and change is very hard.

Only long lived branch is main/master/name-it-like-you-want. Development in 99% of cases is done on short lived feature branches. Very rarely (remaining 1%) we have medium lived (integration) branches for bigger features where several people work in parallel on different parts of feature. In that case devs work on their branches and then opens PRs to merge their work to integration branch and at the very end there's one big PR to merge integration branch into main.

We have a project (API with pipeline tests and deployment), where we work in pairs and commit directly to

main

. The majority of the github repos have branch protection with short lived branches and PRs.

Feature branches for all PRs and merge to main

I've worked on teams with trunk-based development over the past several years. Devs would create short-lived feature/fix branches and post PRs/MRs for review + CI. If CI passed and PR got approval then it was merged to trunk where a CD pipeline would deliver it to either prod or staging. Committing directly to the trunk in a team bigger than some really low number (2?) sounds scary to me, especially if it's a high velocity team.

Can you define what a "merge queue" means?

A queue where the PRs are placed in and then, one by one, integrated with the trunk on a "staging" area. You can configure your tests to run after this integration as well, and right before merging to trunk.

Oh, interesting

Yep - I've been there (being forced to update my branch many times). It's painful and inefficient IMO.

It could introduce risk though. For example, I'm right now thinking about some of our very large terraform repos. We've already had incidents where people use CI to trigger terraform apply and didn't carefully look at changes they didn't intend to make, that caused an outage. Something their code changes didn't show.

Hmm, true. In that case, I would recommend CI on the PR itself. Have the CI pipeline post a comment with the TF's plan, and someone review that.

That already is done ^^