Branching and Release Management Guide

Overview

This guide outlines the naming conventions, branching strategy, and merging process for our Git repository.

Branch Naming Conventions

Feature Branches

• Naming Convention: feature/<workstream>_<version>
  • Example: feature/streamlit_UI0_1.0, feature/textract_1.5

Branching Strategy

Creating Feature Branches

1. From Release Branch: Create a feature branch from release/uat_<version>
   • Example: To develop Streamlit UI1 v1.5, create feature/streamlit_UI1_1.5 from release/uat_1.0

Merging Process

Merging to DEV

1. Initial Merge: Once the feature is ready, merge the feature branch into DEV.
2. Verification: Ensure the functionality is verified in DEV.

Merging to UAT

1. Approval Requirement: Merge to UAT requires approval from default reviewers (Anup / Priya / Umang).
2. Post-Approval Merge: After approval, merge the same feature branch that was verified in DEV into UAT.

Merging to PROD

1. Final Merge: Once the feature is tested and approved in UAT, merge it into PROD.
2. Complete Versions: Deployment to PROD should only be done with complete versions (e.g., v1.0, v2.0) with an appropriate release branch in place.

State of Branches

After Initial Release (v1.0)

Workstream	DEV	UAT	PROD
Streamlit	1.0	1.0	1.0
Textract	1.0	1.0	1.0
DevOps	1.0	1.0	1.0
Data	1.0	1.0	1.0

After Streamlit 1.5 and Textract 1.5

Workstream	DEV	UAT	PROD
Streamlit	1.5	1.5	1.0
Textract	1.5	1.5	1.0
DevOps	1.0	1.0	1.0
Data	1.0	1.0	1.0

Merge Restrictions

• Workstream Specific Changes: For feature branches, only changes in the respective folder are allowed. Other changes require a separate feature branch. This ensures that workstream changes are deployed to the respective infra.
• Merge Approval: Merging into DEV, UAT or PROD requires approval from default reviewers.

Refer to the branching guide in Confluence for more info on this

---

This guide ensures that all team members follow the best practices for branch management and releases.