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
| Branch | Description |
|---|---|
master | Branch MUST be deployable to production server anytime so the code there MUST be free of critical errors. If something is in
|
develop | In most cases it reflects the codebase from staging server. Sometimes the staging server MAY include code from other branches (e.g.
|
feature/* | Branch SHOULD be used for creating all the new features. The name SHOULD reflect the feature meaning, e.g.
|
bugfix/* | Branch SHOULD include all the scheduled fixes for existing issues that could take more time.
|
hotfix/* | Branch SHOULD include only small fixes like typos, missing semicolon or other cases that are not changing more than few lines.
|
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.
|
update/* | Branch SHOULD include changes related to maintenance updates. Each branch MUST be named according to
|
Other
| Category | Description |
|---|---|
| Commits | You 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. |
| Messages | You MUST write clear commit messages. You SHOULD base on this article. |
| Naming | Branches names MUST be written in kebab-case and have exact meaning. |
Leave a Reply