In the understanding of GitHub Flow, as seen here, a feature, after code review, is first deployed to production, then merged into master.If there is a second feature branched from the same commit as the first feature, and that too is deployed straight to production, then production will no longer contain the first feature.made at learngitbranching.js.orgOnce c2 is deployed, how can c3 be deployed before merging with c2 or c4?How does GitHub Flow handle this issue?An obvious solution would be to require that a feature must be rebased onto master before it is deployed to production. However, this is prone to human error. If one forgets to rebase, production is now missing a feature.I would especially appreciate answers from those who have experience using GitHub Flow. How do you not have this issue?
GitHub Flow deploy to production before merging to master: won't a second feature override the first?
git
Good news! GitHub has an article about it!They identify three safety measures:Make sure it passes its tests. This is hopefully part of most deployment workflows. But, it's one of the safety measures they stress.Lock the deployment pipeline as-needed: When a feature branch is being deployed or verified on production, no one else can start a deployment.Ensure that every deployed branch contains every already-deployed change-set. How this is done is a little more complicated. Here's what they say:We use the GitHub API to verify this requirement. An endpoint on the  github.com application exposes the SHA1 that is currently running in  production. We submit this to the GitHub compare API to obtain the  merge base, or the common ancestor, of master and the production  SHA1. We can then compare this to the branch that we're attempting to  deploy to check that the branch is caught up. By using the common  ancestor of master and production, code that only exists on a branch  can be removed from production, and changes that have landed on master  but haven't been deployed yet won't require branches to merge them in  before deploying.If it turns out the branch is behind, master gets merged into it  automatically. We do this using the new Merging API that we're  making available today. This merge starts a new CI build like any  other push-style event, which starts a deploy when it passes.The merging API basically performs a standard merge — but does so server-side.Your solution probably doesn't need to be so sophisticated. At the end of the day, you just need reasonable assurance that:Tests passOnly one person deploys at a timeMaster is merged into feature branches before deployment