[bswinnerton]

This is known as “GitHub Flow” (https://guides.github.com/introduction/flow/). I was pretty surprised by it when I first joined GitHub but I’ve grown to love it. It makes rolling back changes much faster than having to open up a revert branch, get it approved, and deploy it. When something goes sideways, just deploy master / main, which is meant to always be in a safe state.

[samc98]

How does this work if two (or more) engineers touch the same file at the same time?

EG: If two engineers have two different PRs open modifying `index.html`, how does that go to canary?

[bswinnerton]

Before every deploy your branch has master merged into it. There’s some clever work by Hubot while you’re in line to deploy to create a version of your branch that has the potential new master / main branch. If conflicts arise you fix them before it’s your turn to deploy.

[rtpg]

how deep does this deploy queue get? And does everything that lands on master have to first be deployed?

This seems like a bit tough for getting work done if you have enough people all waiting around for this

[jules2689]

The deploy queue usually gets to be a couple of "trains" deep which usually includes work from 4-10 devs. This represents a couple of hours. We have had issues with it taking too long, but this work I wrote about has improved that! We continue to try to improve it.

[gowld]

Why would you revert a branch (in source) before deploying it? You already have the old known good version in the history, so you should deploy that.