Does anyone know the pros and cons of GitHub's approach?
EG: If two engineers have two different PRs open modifying `index.html`, how does that go to canary?
This seems like a bit tough for getting work done if you have enough people all waiting around for this
The main benefit is, other developers can rely on the master branch even more. They will know there will not be a revert on the master branch they just pulled one hour ago and already started coding on.
Agreed that any codes can be added/removed but those are 100% valid changes in github flow.
This means master is a history of proven stable builds. And in an emergency you don't have to think about what to roll back to, it's by default master.
It's just a convention, it does not have any real benefits or downsides. You could do the same with another branch named stable, or with tags.
> a record of every version that was seen by actual users
This is covered by the release branches and also by the CD pipeline.
Seems one can deploy up to ... Say, 24/3? times per day? If 3 h in between
(trabant00 thanks for explaining :-))
This sounds rather terrifying to me as well. Hopefully there's some sort of system for keeping around all those individual branches that made it out to prod, however briefly, for future debugging/auditing purposes if you ever need them.
It's never fun to have to be doing "what code was running at this time" investigations, but every once in a while it's the only way to really get to the root of something.