This document defines Git naming conventions for branches and commit messages. It is designed with a purpose to support task and sprint management using ClickUp.

I. Branch overview

  1. main

Serves as the Holy Grail of Git branches within our project. It represents the production-ready branch that always contains stable and working code. Any team member can confidently use this branch to run the project without encountering issues. Similar to the Holy Grail, which was sought after as the ultimate treasure, the main branch holds the culmination of our development efforts, ensuring reliability and readiness for deployment.

  1. stage

The stage branch acts as the development branch where all changes, including new features, bug fixes, and other updates, are integrated and tested. This branch serves as the proving ground for code before it is deemed stable enough to be merged into the main branch.

  1. release/yymmdd (y - year, m - month, d - day)

The release branch follows the naming convention release/yymmdd (where y is the year, m is the month, and d is the day). This branch is created from the main branch and serves as a dedicated branch for preparing a new production release. It allows the team to finalize features, perform thorough testing, and make any necessary last-minute adjustments without disrupting ongoing development work. Once the release is thoroughly vetted and ready, it is merged back into the main branch and deployed to production.

II. Naming Branches and Commit Messages

For branch and commit message naming we use ClickUp task ID principle. We're going to use the ClickUp task ID 86bzma9gg as a reference. Branches should be named using the format type_of_change/task_id.

III. Types of Changes

  1. FEATURE (FEAT): A feature branch is used for developing new functionalities or enhancements in the project. It involves implementing new components, modules, or services that add value to the project. Example: feature/86bzma9gg or feat/86bzma9gg.
  2. BUG: A bug branch is designated for fixing errors or defects found in the project. This branch focuses on resolving issues that prevent the project from functioning as expected. Example: bug/86bzma9gg.
  3. FIX: A fix branch is similar to a bug branch but is often used for minor corrections or adjustments that do not constitute major bugs. This might include small tweaks or refinements. Example: fix/86bzma9gg.
  4. CHORE: A chore branch is used for maintenance tasks and non-functional updates. This includes activities like code refactoring, updating dependencies, or improving documentation. Example: chore/86bzma9gg.

By categorizing branches this way, we maintain a clear structure and purpose for each type of change, ensuring efficient and organized development workflows.