GitHub Flow deploy to production before merging to master: won't a second feature override the first?

Question

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.org

Once 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?

Answer 1

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 pass
• Only one person deploys at a time
• Master is merged into feature branches before deployment

Answer 2

Has this problem happened to you or is it a theoretical question?

Git is "smart enough" when merging to only push the changed code, if there are "problems" it will give you a merge-conflict.

Every new feature is based of the develop branch we don't base features on other features.

One thing we do to minimize merge-conflicts is to merge often and before you start a feature always pull the latest develop. (we never commit to master but always to a develop branch, which will be merged once in a while to the master branch)