Guide for Git branching.
This project follows the branching model articulated in "A successful Git branching model".
-
The
master
branch is protected. -
The
master
branch should only include source code which is stable, tested, and peer reviewed. In short, the source code should always reflect a "production-ready" state. -
Each commit on the
master
branch should have an associated tag.$ git tag -a v2.0.0 $ git push origin --tags
- The
develop
branch is protected. - The
develop
branch should only include code which is tested, peer reviewed, and passes continuous integration tests. - The source code should always reflect the latest development changes for the next release.
-
A feature branch should use the naming convention:
feature/<name>
. -
A feature branch should branch from the
develop
branch.$ git checkout -b feature/<name> develop
-
Once a feature is complete, squash commits into a single commit.
-
In order to merge a feature branch into the
develop
branch, submit a pull request against thedevelop
branch. -
Before merging a feature branch into the
develop
branch, the source code must be peer reviewed and pass continuous integration tests.
-
A release branch should use the naming convention:
release-<major>.<minor>.<patch>
. -
The release number should follow semantic versioning.
-
A release branch should branch from the
develop
branch.$ git checkout -b release-2.0.0 develop
-
Active development should not occur on a release branch. A release branch is a preparation branch (vetting, testing, updating meta data, et cetera) before merging into the
master
branch. -
Once a release branch is complete, submit a pull request against the
master
branch. -
Before merging the release branch into the
master
branch, the changes must be peer reviewed and pass continuous integration tests. -
Once merged into
master
, submit a pull request against thedevelop
branch to retain the changes made in the release branch.
-
A hotfix branch should use the naming convention:
hotfix/<name>
. -
The purpose of a hotfix branch is to immediately patch a bug on the
master
branch. Accordingly, a hotfix branch should branch from themaster
branch.$ git checkout -b hotfix/<name> master
-
The hotfix branch should increment the "patch" version number.
-
Once a hotfix is complete, squash commits into a single commit.
-
Submit a pull request against the
master
branch. -
Before merging a hotfix branch into the
master
branch, the changes must be peer reviewed and pass continuous integration tests. -
Once merged into
master
, if a release branch currently exists, submit a pull request against therelease
branch. Otherwise, submit a pull request against thedevelop
branch. By merging a hotfix into a release branch, the hotfix changes should be propagated to thedevelop
branch upon merging the release branch into thedevelop
branch.
- All feature pull requests should be rebased against the latest
develop
branch. - All feature pull requests should be submitted against the
develop
branch.
This document may be reused under a Creative Commons Attribution-ShareAlike License.