Skip to content

Instantly share code, notes, and snippets.

@ptflp
Created January 23, 2018 17:35
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save ptflp/5b10e6c537d9190f7d32db893aef1fec to your computer and use it in GitHub Desktop.
Save ptflp/5b10e6c537d9190f7d32db893aef1fec to your computer and use it in GitHub Desktop.
workflow

Release management (GitFlow branches)

  • master - We consider master to be the main branch where the source code of HEAD always reflects a production-ready state.
  • develop - This branch always reflects a state with the latest delivered development changes for the next release.
  • features/<feature> - Start developing new features by creating a new branch based on develop. Once your feature is completed merge your feature back to develop (you have to create merge-request to the develop branch, and do NOT remove the source branch).
  • release/<version> - After all features for the release are in develop branch, you can create a release branch using version. Our version string will strictly follow PEP-440 standard and we could associate. version string format sample:
Version Sample
major.minor 1.0
major.minor.patch 1.0.2
alpha, beta 1.0a, 1.0b
release candidate 1.0rc1, 1.0rc2

Everyone who is working on release should always be extra careful about what to push. Strictly peer review their code before push. Once the release complete the code be merge to develop, and master branch. Release TAG <version> will be created out of master branch. Production only accept deploy from TAG.

  • hotfix/<version> - In case of production issue, we will create hotfix/<version> out of master branch. After issue has been resolved, we will merge code back to both develop, master and create new release TAG with a patch version.

Branches scheme

More information about branches and releases

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment