Git flow in BOLD_

Git is one of the most important parts of the modern development process. It allows to track the changes in the codebase effectively, makes teamwork easier and provides the features that help to solve problems by reverting changes or getting back to other versions.

This article is not the introduction to GIT itself, but it’s an explanation for the rules that we proposed in our company to make the development process easier, especially when the team grows. Let’s call them boldflow. This workflow is based on a few of the most popular flows – “Git Flow”, “GitHub Flow”, “GitLab Flow”. You can read about these in this article on GitKraken.

Quoting the article “None of these workflows are set in stone and can, and should, be modified to fit your specific environment and needs.“, the boldflow is a mix of existing rules with added some new ones that we believe will help our work. The rules may change in time as we discover new and better ways of development.

The rules use keywords such “MUST”, “SHOULD”, “SHALL” that are explained in RFC 2119.

Branches

BranchDescription
master

Branch MUST be deployable to production server anytime so the code there MUST be free of critical errors. If something is in master it is on production server. Branch SHOULD be deployed immediately after merging – within the same workday at worst.


  • Code MUST reflect the production codebase.
  • Code MUST be deployable to production anytime.
  • Branch SHOULD be merged with a new features only via pull request from develop, hotfix/* or sync/* branches.
develop

In most cases it reflects the codebase from staging server. Sometimes the staging server MAY include code from other branches (e.g. feature/feature-name), and it’s allowed but the information about that MUST be passed to the project team.


  • Code SHOULD reflect the staging codebase.
  • Branch SHOULD be merged with a new features only via pull request from other supporting branches.
feature/*

Branch SHOULD be used for creating all the new features. The name SHOULD reflect the feature meaning, e.g. feature/block-contact, not feature/blocks-creation.


  • Code SHOULD be branched from develop.
  • Branch MUST be merged to develop via pull request.
  • Pull request MUST be reviewed by developer itself and at least one more.
bugfix/*

Branch SHOULD include all the scheduled fixes for existing issues that could take more time.


  • Code SHOULD be branched from develop.
  • Branch MUST be merged to develop via pull request.
hotfix/*

Branch SHOULD include only small fixes like typos, missing semicolon or other cases that are not changing more than few lines.


  • Code SHOULD be branched from develop.
  • Code MUST be merged to develop via pull request then merged to master via pull request from develop.
sync/*

Branch SHOULD only add changes related to synchronizing environments. If for some reason there is a change in the production code that is not in the repository (e.g. plugin updates) but should be, then use this branch to reflect changes.


  • Code SHOULD be branched from develop.
  • Branch MUST be merged to develop via pull request then merged to master via pull request from develop.
update/*

Branch SHOULD include changes related to maintenance updates. Each branch MUST be named according to YYYMMDD format where YYYY represents current year, MM month number with leading zero and DD stands for day of month with leading zero. Eg. update/20010307


  • Code SHOULD be branched from master.
  • Branch SHOULD be merged to develop via pull request. Then to push changes to master create a new pull request from develop (see rules described above).
  • Branch MUST be named according to YYYMMDD format of date when the update was made.

Other

CategoryDescription
CommitsYou MUST commit your changes regulary – at least once a day for each project that you’re working on. It is better to commit not finished feature to your branch and finish it the next day than to lose progress.
MessagesYou MUST write clear commit messages. You SHOULD base on this article.
NamingBranches names MUST be written in kebab-case and have exact meaning.

Add the first comment and start a discussion

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Cookies

Service namePurposeSettings
Cookies funkcyjneCookies required for the operation of the website.