Reading about GitHub Flow, I saw that one of the main suggestions after merging to master is that we should immediately deploy, but I don't completely understand the reason for that. Isn't it possible to wait for a couple more features? What it will happen if we wait?

Basically what I'm trying to ask here is for examples of how if I don't follow the flow could affect my software negatively.

  • 3
    That whole methodology seems to be based on the assumption that you're doing CI/CD - maybe read up on those. – jonrsharpe Dec 8 '17 at 23:11
  • Thanks @jonrsharpe, I understand the CI/CD process, the think is that I want to know what could happen because let’s say I could deliver every time that I merge to master, but there’re some cases where I have to wait to other feature, so in my case both are going to be released, and I can do that, but first I want to know which cases were evaluated to avoid a deploy with multiples features on it. – learnercys Dec 8 '17 at 23:33
  • @jonrsharpe: your comment sounds like a good answer. – Doc Brown Dec 9 '17 at 9:08
  • 1
    From your own link you deploy before the merge. – Sign Dec 9 '17 at 15:52
  • 1
    if QA have a lot of features to test all at once, it can be hard to isolate a bug to a specific change, especially if it's a side effect in a different feature. If they test with features as soon as they are ready and merged, it is easier to identify exactly what changes caused the side effect – HorusKol Dec 10 '17 at 2:23

The GitHub Flow “is a lightweight, branch-based workflow […] where deployments are made regularly.” So you should only use this process if:

  • you want to deploy regularly/frequently, and
  • you want a lightweight process.

The suggested process to develop a feature is:

  1. Create a feature branch.
  2. Develop the feature.
  3. Open a pull request.
  4. The feature is reviewed.
  5. Once the feature is ready, kick off your deployment process.
  6. After the feature has been validated in production, merge the feature back into master.

So why should you wait for a couple of features if you can deploy each new feature immediately? If the feature is not ready, you should not deploy it, as simple as that. While the feature is getting ready, the pull request just sits around waiting. When other features are merged into master, then master should be merged into the feature branch (or, depending on your preferences, the feature branch should be rebased on the current master).

This is a very lightweight process, so it is assumed that you do not have to perform extensive QA before release. Your deployment process should perform automated tests, and once the feature is live you are supposed to validate it in production. If there's a problem, you just re-deploy the current state of the master branch.

In my opinion this process is so lightweight that it is almost meaningless. It seems to be most suitable for small teams working on early-stage products where failures in production are acceptable. It's not difficult to imagine how a slightly stricter process would be welcome. You can of course adapt this process to your needs, e.g. by introducing a release manager role who decides which features/pull requests are merged when.

What the GitHub workflow demonstrates very well is how GitHub the product can integrate into such a process, e.g. as a platform for discussions on a pull request. You can find similar material from GitHub's competitors:

The Gitlab Flow and Gitlab Workflow are more in-depth documents, and present different possibilities rather than prescribing a particular process. They mention and contrast the Git flow and GitHub flow with other approaches: “In reaction to git flow a simpler alternative was detailed, GitHub flow. […] But this flow still leaves a lot of questions unanswered regarding deployments, environments, releases and integrations with issues.” But between all those possibilities, they don't offer a clear alternative process.

I find the Git tutorials by Atlassian (Bitbucket) far more nuanced and in-depth, and not as sales-y. In the Simple Git workflow they present the same concepts as the GitHub flow, but focus on Git operations rather than their product. In Git Workflow: Comparing Workflows, they write:

There is no one size fits all Git workflow. […]

The longer a branch lives separate from the production branch, the higher the risk for merge conflicts and deployment challenges. Short-lived branches promote cleaner merges and deploys. […]

A workflow should complement your business’s software development release cycle. […]

That document is well worth reading because it discusses how different workflows are geared towards different goals, and in particular how these goals affect the role of the master branch.

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.