10

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.

first feature merged into master

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?

2

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
| improve this answer | |
  • My team decided to merge to master before deploying to production. No branch is merged into master unless it is based on master. After the merge, all other un-merged branches (features still in progress) must rebase onto master before they are eligible for code review, testing (manual and scripted), and eventual merging into master. Once a feature is in master, it's like it's in prod, because master can be deployed at any time. – DarkSigma May 8 '17 at 23:41
  • It just seems like such a bad idea to deploy an application to Production that hasn't been merged with the master branch. You would think if you are moving it to Production you have already tested the change in a test environment. If it then fails in Prod, just roll back to the previous release. I'm sure Github has their reasons, but seems like a lot of extra work and could lead to a situation where you have no idea what is actually in Production. Merges to the master don't always go well if there are conflicts, so you could have code in Prod that doesn't match what you intend ... – Erik Pearson Dec 5 '18 at 16:55
  • @ErikPearson I think the idea is that you need to at least have master merged into the feature branch first. Your build system should not allow you to deploy an unmergable branch. ... Speculating, of course. I don't actually use this workflow. But, it doesn't seem horrendous to me with the right tooling. – svidgen Dec 5 '18 at 17:08
  • Does the term "Production" mean the real live environment, or is it talking about creating something that you can deploy to a production-like environment for final testing; i.e. the artefact (container image?) you're creating is the same one that you'd eventually deploy to production? As with many, I'd understood this flow differently / find deploying something to production ahead of merging counterproductive / feels like it goes against the use of the CI pipeline concept. – JohnLBevan Jun 22 at 15:19
0

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)

| improve this answer | |
  • 2
    You misunderstand my question. It's not about merge-conflicts, and there's no develop branch. I ask about Git Hub flow (see link). My team wants to use this workflow, but don't understand why we would deploy an unmerged feature. Yet that appears to be an innovation of this flow – DarkSigma Mar 7 '17 at 12:28
  • There is always a develop branch. It seems you are calling your develop branch "master". – gnasher729 May 7 '17 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.