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:
- Create a feature branch.
- Develop the feature.
- Open a pull request.
- The feature is reviewed.
- Once the feature is ready, kick off your deployment process.
- 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