Branching Style

The BodhiTree Git branching structure.

Purpose

To ensure clear organization, maintainability, and collaboration across teams.

Git branching structure matrix

Branch Type	Naming Convention	Purpose	Branching From	Merging Into	Rules
Production Branch	main	Represents the latest stable release of the project.	Hotfix, Release (initially)	No direct commits	Must always be in a deployable state. Merged only via PRs. No direct commits allowed.
Development Branch	dev	Contains the latest development code.	Feature, Bugfix (initially)	release/version-number	Protected. All features and bugfixes must pass code review before merging.
Feature Branch	feature/feature-name	Develops individual features or enhancements.	dev	dev	Feature must be reviewed and tested before merging. Regularly updated with latest dev.
Bugfix Branch	bugfix/issue-name	Resolves bugs found in the development phase.	dev	dev	Must fix the issue associated with an open bug ticket. Follows similar rules as feature branch.
Release Branch	release/version-number	Prepares the codebase for production release.	dev	main, dev	Only minor bug fixes and release changes are allowed. Should be tagged upon merging to main.
Hotfix Branch	hotfix/hotfix-description	Urgently fixes critical issues in production.	main	main, dev	Created for immediate production fixes. Merges back into dev to propagate changes.

Key Points

1. Production Branch (main):

   • Always deployable and contains the latest production-ready code.

   • No direct commits; merges only from release and hotfix branches.

2. Development Branch (dev):

   • Integrates features and bugfixes.

   • Periodically merged into release for preparation for production.

3. Feature and Bugfix Branches:

   • Each feature/bugfix gets its own branch.

   • Branch from dev and merge back into dev upon completion.

4. Release Branches:

   • Created when preparing for a production release.

   • Only minor fixes or version updates are allowed.

5. Hotfix Branches:

   • Created to handle urgent production fixes.

   • Merges back into both main and dev to ensure the codebase remains in sync.

Merge Rules

• All merges to main or dev should go through pull requests (PRs).

• Code must pass all tests and be reviewed before merging.

• main and dev branches should be protected to prevent accidental commits.

Key Points for Quarterly Releases

Versioning System:

1. The version number is formatted as year.month, where the month reflects the quarter’s primary release.

2. Code Freeze: A code freeze will be enforced two weeks prior to the release date to ensure stability and adequate testing.

3. Testing and Review: The final code for each release will undergo thorough testing and code review before it is merged into the main branch.

4. Tagging: Each release will be tagged in Git with its corresponding version number (e.g., 2024.01).

Merging Process for Releases

1. Release branches (release/version-number) are created from dev and will be merged back into both prod and dev after the release to keep all branches up to date.

2. Hotfixes made after a release will be added directly to prod and merged back into dev to ensure consistency across environments.

---

See also

• Writing a Git Message: the commit message format used on every branch.

• Merge Request Checklist: what a branch needs before it can be merged.

• Versioning Convention: how release numbers are chosen.