Branching Strategy

Introduction

Understanding the branching strategy is crucial for seamless collaboration and version management within the Alliance Business Suite (ABS) project. This document outlines the branching strategy we follow for developing and releasing features, fixes, and updates.

Main Branches

main

This is the production branch, and it's always deployable. Code that lands in main has been thoroughly tested and is considered stable.

develop

This is the development branch where features, improvements, and fixes are merged. The code in develop should always be in a deployable state but may contain bugs and unfinished features.

Feature Branches

Feature branches are branched off from develop and are used to implement new features or improvements. Their names should describe the feature or improvement being implemented.

  • feature/<feature-name>: for example, feature/authentication-improvements

Hotfix Branches

Hotfix branches are created from the main branch and are meant to fix issues that cannot wait for the next release cycle.

  • hotfix/<issue-name>: for example, hotfix/security-vulnerability

Release Branches

When develop reaches a state that it can be released, a release branch is created off develop.

  • release/<version-number>: for example, release/2.0

Once the code is ready, it is merged into main and tagged with the version number.

Personal Branches

In addition to these common branches, each developer can have personal branches. These branches should be named after the developer and can be used for experimental code or tasks that don't directly relate to current feature development.

  • <your-name>: for example, Daniel

Merging Strategy

  • Feature branches are merged into develop.
  • Hotfix branches are merged into both main and develop.
  • Release branches are merged into main and tagged. They can also be merged back into develop if necessary.

Branch Policies

We've configured branch policies for main and develop to ensure:

  1. Minimum one code reviewer.
  2. All build and test policies pass.
  3. No direct commits; only pull requests are allowed.

Tools and Commands

You'll be primarily using git commands to manage branches. Here's a quick refresher:

  • Create a new branch: git checkout -b <branch-name>
  • Switch to an existing branch: git checkout <branch-name>
  • Update your local branches: git fetch origin
  • Delete a local branch: git branch -d <branch-name>

Conclusion

Following this branching strategy will help maintain an efficient, organized, and conflict-free codebase. Please adhere to this strategy for a consistent development experience across the team.

For more details about version control, refer to our Version Control page.

Feel free to contribute to this document to keep it updated and relevant.