Skip to content

Gitflow

Jump to bottom
Artem Chubchenko edited this page Jul 9, 2019 · 1 revision

Main Branches

According to gitflow, we use two main branches:

  • master, which contains production-ready code that can be deployed at any arbitrary point in time
  • develop, which include the most recent published changes needed for the next release

Supporting Branches

Feature Branches

  • May branch off from: develop
  • Must merge back into: develop
  • Branch naming convention: feature/<ISSUE_KEY> (e.g. feature/PEO-14)

Feature branches are used to develop new features for the upcoming or a distant future release. Each feature branch is used to implement a single task.

Release Branches

  • May branch off from: develop
  • Must merge back into: develop and master
  • Branch naming convention: release/<VERSION> (e.g. release/1.0.1)

Release branches support the preparation of a new production release. They allow for minor bug fixes and preparing metadata for a release (version number, build dates, etc.).

Hotfix Branches

  • May branch off from: master
  • Must merge back into: develop and master
  • Branch naming convention: hotfix/<VERSION> (e.g. hotfix/1.0.2)

This branch is created for handling emergencies − it allows to fix something in production quickly.

Bugfix Branches

  • May branch off from: release or develop
  • Must merge back into: release or develop
  • Branch naming convention: bugfix/<ISSUE_KEY> (e.g. bugfix/PEO-23)

These branches are created in case the release requires bug fixes.

Version naming rules

We follow semantic versioning forgiving versions to the release and hotfix branches. Each version contains three version numbers − MAJOR.MINOR.PATCH. Here's what each of them means:

  • MAJOR - code is incompatible or contains significant changes
  • MINOR - code has been changed, but the changes are backward compatible
  • PATCH - bug fixes have been made

Main rules to follow

  • all commit message follows guidelines
  • never make commits to the master branch
  • one task, one feature branch
  • new functions must be added only to the develop branch

Pull Request

It must contain the description of the task and a link to the task from the task management tool. Also, a pull request should be opened at any time (even if work is not finished) to discuss changes with the team.

Mail rules to follow:

  • always open a pull request on the first day you started working on a task
  • you need to push new changes to a remote repository on a daily basis
  • always mark your pull request with the appropriate label
  • assign team members for review, when changes are done
  • use squash and merge type for merging all pull requests
  • delete branch after the pull request is merged

Labels

Use labels to mark your pull request type:

  • FEATURE
  • RELEASE
  • BUGFIX
  • HOTFIX

Use labels to mark your pull request state:

  • WIP
  • NEED REVIEW
  • REVIEWED
  • HOLD

Code Review

  • All changes were tested by the author of the pull request
  • Make a self-review before sending a pull request to code review

After all the changes are performed and tests passed successfully, add NEED REVIEW label to pull request. The idea behind Code Review is not only to find bugs but to get all team acquainted with a new code.

Each pull request must have enough approves to be merged into the branch:

  • bugfix - a minimum of 2 approver required
  • feature - a minimum of 2 approver required
  • hotfix - a minimum of 2 approver required
  1. A Step-by-Step Guide to the RubyGarage Git and Release Management Workflow
  2. Semantic Versioning 2.0.0
  3. How to Write a Git Commit Message
Clone this wiki locally