OneFlow - a Git branching model and workflow

http://endoflineblog.com/oneflow-a-git-branching-model-and-workflow

Adam Ruka

Purpose

• Cooperate and keep clean history.
• Standardize feature addition and release processes.

Outline

• First commit:
  • README.md
  • LICENSE
  • CHANGELOG.md
• Workflow:
  • Features.
  • Releases.
  • Hotfixes.

Readme

• Why to add README.md?
• What is the project about.
• How to contribute.
• How to run the project.
• What dependencies needed.
• Also benefits the owner.

License

• Why to add LICENSE?
• Using project by others.

Changelog

• Why to keep a CHANGELOG.md?
• What is Semantic Versioning?
  • X.Y.Z
  • Major (backward incompatible).
  • Minor (feature).
  • Patch (hotfix).

Workflow

• Features.
• Releases.
• Hotfixes.

How not?

Why not?

Why not?

• Hell a lot of long-live branches.
  • More than 1 is hell a lot.
• Too complicated.
• Too chaotic.

OneFlow advantages

• Single long-live branch, therefore simple.
• Clean history, therefore useful.

How can it look like?

GitFlow/OneFlow comparison

OneFlow: Main branch

• Only long-live branch.
• Let’s call it master.

OneFlow: Feature branch

• New features and bugfixes for upcoming release.

• Cooperation, can be push forced.

• Checkout from master.

• Merge to master.

Feature branch picture

OneFlow: Release branch

• Prepare project to be released.

• Start from proper commit on master.

• Merge to master.

Release branch picture

OneFlow: Hotfix branch

• For critical defect solutions.

• Start from last version tag.

• Merge to master.

Hotfix branch picture

So, like that…

Licenses

• https://opensource.org/licenses/

Versioning

• https://semver.org/
• https://keepachangelog.com/en/1.0.0/

Branching model

• http://endoflineblog.com/oneflow-a-git-branching-model-and-workflow
• https://nvie.com/posts/a-successful-git-branching-model/

Contributed images

• http://numergent.com/images/dev/git-flow.png
• http://gitgraphjs.com/