1. Overview
2. Official Branches
3. Release or Staging Branches
4. Project Branches
5. Feature Branches
6. But... Why?

Overview

Configura recommends an adapted version of GitFlow, in which:

• We have release/staging branches.
• Development is done in feature or project branches.
• Merge requests are created to merge the feature or project branch into the staging branch when done.

Here's a simple visual representation of these branches:

Official Branches

Merged from staging branch once the update is released.
Exactly mirrors what’s currently released to users.

• Format
  version/<version number>/official
  
  
• Examples
  • version/11.5/official
  • version/12.0/official

Release or Staging Branches

A Staging Branch is created for each patch/release that is planned, and all BETA/RC builds are based on this branch. Automated Builds can be made from this branch.

This is the branch where changes for that update/release are merged to. This is also where any build for this version is made.

• Format
  release/<version number>/<release identifier>
  
  
• Examples
  • release/11.5/major
  • release/11.5/patch2
  • release/12.0/major

Project Branches

A longer-lived branch, used for a project or specific teams. Workflow in these project branches is governed by the process of the project team, but usually, team members work in feature branches that get merged into project branches.

Each project will have a branch under the project/ folder followed by the project identifier such as name or ticket number. Branches under project/ should be protected by default.

• Format
  project/<project identifier>
  
  
• Examples
  • project/CETC-78767
  • project/12.0-flooring
  • project/CETC-78767-12.0-flooring

Feature Branches

A branch that is ideally small, limited in scope and lifetime. Used for isolating the development of a feature or fix.

Development branches are added under the develop/ folder followed by the issue identifier such as an issue number.

• Format
  develop/<issue identifier>
  
  
• Examples
  • develop/CETC-82885
  • develop/edit-tile
  • develop/CETC-82885-edit-tile

But... Why?

Every group has a standard of naming branches internally known within, even us!
As the administrator of the software, we would need to keep track of everyone's different standards, unnecessarily costing a lot of time to find out branches of interest.

Having a convention comes with the advantage of everyone intuitively knowing what is and is not a branch of interest.

These are some processes that would greatly benefit from this:

• Testing
  Generally, we try to identify compatibility issues between Configura base branches and Partner branches, especially when there is a change that's going to affect Partners.
  
  
• Troubleshooting
  Able to easily reproduce an issue and thus clearly identify sources of bug/crash reports.
  
  
• Future of automated testing
  Having a consistent branch pattern makes it possible to create easily create scripts to execute basic, automated tests across Extensions.