Skip to content
Search

GitHub flow

lastmod 2022-10-26created 2022-10-268 edits

Scott chacon says in GitHub Flow that although Git flow is a good approach, he found it too complex to use at GitHub, so instead of using it they use an approach called GitHub Flow. It also includes the concept of automation. Where automation is not in place, the related tasks can simply be done manually.

As the flow is simple, the rules are simple too. As long as the role for the master branch is clear, the other branches are left alone. It also recommends using the pull request feature.

Features

  • Designed for use in systems where the release branch is not clearly defined.
  • This seems to be due to the nature of GitHub's service. It runs a service without the concept of a release, and since web services are losing the concept of releases, it should be convenient to use.
  • Does not distinguish between a hotfix and the smallest feature. Either way, both are tasks a developer has to fix. The only difference is which has the higher priority.

So how do you use it?

The master branch is deployable at any time.
The master branch is always up to date and is the branch deployed to Product in a stable state. Strict roles are applied to this branch.
When branching off master to start new work, give the branch a name that clearly says what it does.
Unlike git flow, there are no feature or develop branches. So name branches for adding new features or fixing bugs with a detailed description of the work being done. That way, it is easy to see on the Github page what work is in progress.
Push to the remote branch frequently.
This is the approach most opposite to git flow. Always upload what you are working on to the remote so others can check it too.
The advantage of this method is that even if a hardware problem causes your work in progress to be lost, you can get the source from the remote and keep working.
Create a pull request when you need feedback or help, and when you are ready to merge.
A pull request is a system that helps with code review.
So use it to share your code and get it reviewed. Of course, once it is ready to merge, you can also request that it be merged into the master branch.
Merge into master after the feature has been reviewed and signed off.
Since the feature goes straight into product, merge it only after sufficient discussion with the stakeholders.
Once merged and pushed to master, it must be deployed immediately.
What seems to be the core of GitHub Flow: set it up so that whenever a merge into master happens, it is deployed automatically using hubot.

Cons

GitHub flow assumes that you can deploy to production every time you merge a feature branch. This is possible in some cases, such as SaaS applications, but there are also cases where it is not, such as:

  • You cannot control the timing of a release. For example, an iOS application that is released only after passing App Store validation. <- Not sure whether this concept should be considered correct...
  • When there are deployment windows1. For example, the operations team has a deployment window from 10 AM to 4 PM on workdays, but code may be merged at other times as well. <- ???

In such cases, you can create a production branch that reflects the deployed code.

Flows

Favorite site

References

  1. Source text: You have deployment windows ↩

author Zer0 sitemap