The 'merged once deployed to production' thing, yes, I know even if advocated by GitHub, seems extremely weird to me. It does seem they have a staging check first, which is good.<p>It seems you'd want to merge it first, so that you know it when merged with "all the things" on master, so it more closely mirrors what you are going to get once it's merged in.<p>So they could just merge first, and then if staging passes in their CI system, automatically deploy to prod, which is the way many orgs do it.<p>My point is though, you'd want to deal with the merge fun (if any) first, else you are deciding to test branches (pull requests) that only have ALL of the commits from master (rebased, etc), so it's easier to just make sure they hop on master first, else you might "remove" something from prod for a while until it's merged in. Not good.<p>They may have some things to deal with that, but in this case, it doesn't seem like something I'd recommend for most people, and feels weird and organically evolved. One branch may not have the commits another has and both could be deployed without merging, leaving the github deployed code state fluctuating back and forth as one commit drops out and another drops in, before finally both are in at the same time.<p>I wonder how this is handled?