Git Flow

Git flow is "A collection of Git extensions to provide high-level repository operations for Vincent Driessen's branching model". It provides a very effective model of branching that is useful in open source, iterative software design.

See nvie/gitflow for more info and installation instructions. Also, see git-flow cheatsheet for visualisation and reference.

I've borrow this document from zeppelin-solidity's Git Flow

Conventions used in this repository:

Development

• Every development branch must part from the development branch.
• Every development branch must be named as feature/…, bug/…, refactor/…, etc.
• If your branch is planned to fix an open issue, postfix your branch name with the issue number like fix/some-bug-#123.
• Every development PR must be merged against development once ready.
• Development branches must be deleted once merged.

Release

• A release branch must be created from development pointing to the last commit that we expect to include in the release.
• A release branch must be named as release/vX.X.X.
• Once the release branch is ready, a PR must be opened against master.
• A release branch must be audited before merging.
• Once merged against master, a tag vX.X.X must be created pointing to the merge commit in master.
• Finally the release branch must be merged into development.
• Release branches should be deleted once merged.
• The release tag must be published.

Hotfix

• Hotfix branches must be opened from master.
• Once the hotfix branch is ready, a PR must be opened against master.
• Ideally the hotfix should be audited before merging.
• Once merged against master, a tag vX.X.X should be created pointing to the merge commit in master.
• Finally the hotfix branch must be merged into development.
• Hotfix branches must be deleted once merged.

When/Who

• Every 4 weeks.