GitHub Flow and Releases

Question

We are relatively new to git in general. We've been using it for about 6 months and have used GitHub and BitBucket. We've tried to learn as much as is possible by using GitBash so we can get under the core of git.

We're at the stage where we really want to consider our branching strategy and hence I've been doing some research.

In my opinion, GitFlow is overly complicated for our requirements. We work on perhaps 20 different projects in total, and each project may only have releases every 2 months or so. Having looked at GitHub Flow, this seems a pretty straight forward option that would meet our needs - however it does seem to have a flaw that I'd like peoples opinions on.

Anything in the master branch is deployable. We deploy to UAT/QA environments, where that release may remain for 3-4 weeks, depending on how long it takes the client and/or us to sign everything off. In the meantime, someone else may need to work on something completely different. At this stage, based on Github Flow's flow, if that user took a branch from Master they would include the changes that actually at this point in time are still in the QA environment. So, is it that I have misunderstood the first point of GitHub Flow - i.e. anything in the master branch is deployable - does that perhaps only ring true if the code has been through QA etc?

If that's the case, does the flow actually look more like?:

• Take a branch from Master
• Commit changes in branch (only back to branch at this stage)
• Merge branch with a separate branch called "Develop"
• Release to QA/UAT
• When Release is approved, merge branch with Master and deploy?

I think it's specifically Point 1 in GitHub Flow that is confusing us - we surely shouldn't push back to Master when the release is still in QA - that would make the Master branch potentially unstable and certainly not what is currently in Production.

Answer 1

According to what I'm seeing on the git-flow cheat sheet and Driessen's original model, you've got a few things wrong.

While I haven't used the git-flow workflow myself, from what I can tell, master only gets merged to when the release is ready, and NOT before. This way, master always reflects what's in Prod - develop is what serves as the "main" development branch from which feature branches are pulled and merged. So, a successful git-flow workflow looks something like this (assuming all of these branches exist beforehand unless mentioned otherwise):

1. Create a feature branch (which we'll call topic) from develop
2. Work on topic for a while
3. Merge topic back into develop
4. Do this a few more times until you're ready for release
5. Create a new branch, QA-releaseno, from develop
6. Do QA/UAT on QA-releaseno, committing bugfixes as necessary (you can also merge QA-releaseno back into develop as many times as you please)
7. When you're ready to release, merge QA-releaseno into both master and develop, tag a release on master, and delete QA-releaseno

Additionally, what you seem to have done is to conflate git-flow and Chacon's GitHub flow. GitHub flow, at least in its simplest form, works like this:

1. Spin off a new topic branch (here called topic) from master
2. Work on topic (if you're working on it for a long time, merging master back into it periodically is a good idea)
3. Do QA on topic
4. Put out a pull request (PR) from topic to master
5. Once the PR has been code-reviewed to everyone's satisfcation, merge topic back to master
6. Release master immediately, or at least decently quickly

This workflow is designed for teams and organizations that are on a fast release cycle (multiple times per week). QA is done not at the application level, but at the level of an individual feature, task, or ticket. Because the release cycle has immediate (or at least fast) feedback, master will always reflect what's in production.