,

Git flow at Coditive

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 coditiveflow. 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 coditiveflow 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.

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.

Are you searching for developers who genuinely care about your business? Do you need expert consultations in WordPress, Vue, Nuxt, or Laravel, top-tier coding, or thorough audits to boost your success? Look no further! We’ve got you covered.

Topics

AJAX Attribute inheritance backup bounce rate code smell Coditive Contact Form cronjobs database formatting rules GIT Git Flow GitHub Flow GitLab Flow JavScript loading speed MAMP message broker nuxt nuxt3 overlays PHP PHP rules plugin Popups Post Draft Preview RabbitMQ schedule Simple Customizations for WooCommerce Simple Floating Contact Form software development ux Vue.js web development WooCommerce WordPress WordPress CLI WordPress Gutenberg Wordpress plugins WordPress updates WP-CLI wp-cron