🚀 Git Development Workflow Standards

A comprehensive guide for clean, traceable, and professional Git workflows

(Mono-Repo Project)

---

Overview

This document defines standardized naming conventions for branches, commits, and pull requests.

The goal is to:

• Improve clarity and traceability
• Link work clearly to task IDs (Azure/Asana)
• Make code reviews faster
• Keep Git history clean and professional

---

Branch Naming Convention

Dev Branch Format

<type>(<stack-id>)/<task-id>-<short-description>

Allowed Branch Types

Type	Purpose
feature	New features
bugfix	Bug fixes (non-production)
hotfix	Critical production fixes
refactor	Code restructuring without behavior change
chore	Maintenance tasks (dependencies, configs)
test	Test-related work

Examples

feature(fe)/p-777-admin-layout
feature(be)/p-700-subscription-api

---

Release Branch Format

<type-release>(<stack-id>)/<date>

Release Types

Type	Purpose
production-release	Production releases
staging-release	Staging releases

Examples

production-release(fe)/07-01-26
staging-release(be)/07-01-26

---

Branch Naming Rules

• Use lowercase only
• Use hyphens (-), never underscores
• Keep descriptions short and meaningful
• No spaces allowed

---

Commit Message Convention

Commit Format

<type>(<task-id>): <short description>

Allowed Commit Types

Type	Purpose
feat	New feature
fix	Bug fixes
hotfix	Critical production fixes
refactor	Code restructuring without behavior change
chore	Maintenance tasks (dependencies, configs)
test	Test-related work
revert	Revert previous changes

Examples

feat(p-777): admin layout created
fix(p-777): build issue fixes
refactor(p-985): simplify auth middleware

---

Commit Rules

• One logical change per commit
• Use present tense (add, fix, update)
• Start with lowercase (no capital letters)
• No period at the end

---

Pull Request Convention

PR Title Format

🔹 Development PR

[<stack-tag>] <type>(<task-id>): <clear summary>

Example:

[FE] feat(P-1007): implement admin layout
[FS] feat(P-975): coupon feature

---

🔹 Production/Staging Release PR

[<tag>] <date>: [<stack-tag>] [<task ids>]

Example:

[PRODUCTION] 07/01/26: [FE] [p-1005, p-1002, p-979]
[STAGING] 07/01/26: [BE] [p-2001, p-2003, p-2010]

Release Tags

Tag	Purpose
[PRODUCTION]	Production release PR
[STAGING]	Staging release PR

---

GitHub Labels

Labels help classify and track Pull Requests efficiently based on status, scope, and deployment stage.

Label Categories

Status Labels

Label	Purpose
released	PR already released to production or staging
pending	PR has unreleased commits

Deployment Labels

Label	Purpose
staging	Intended for staging deployment
production	Intended for production deployment

stack Labels

Label	Purpose
FE	Frontend-related PR
BE	Backend-related PR
FS	Fullstack-related PR

---

Quick Reference

Dev Branch Example

┌─────────────────────────────────────────────────────────────┐
│  Branch:  feature(fe)/p-777-admin-layout                    │
│  Commit:  feat(p-777): admin layout created                 │
│  PR:      [FE] feat(p-777): implement admin layout          │
│  Labels:  [FE] [released] [pending]                         │
└─────────────────────────────────────────────────────────────┘

Release Branch Example

┌─────────────────────────────────────────────────────────────┐
│  Branch:  production-release(fe)/07-01-26                   │
│  Commit:  feat(p-777): admin layout created                 │
│  PR:      [PRODUCTION] 07/01/26: [FE] [p-777, p-779]        │
│  Labels:  [FE] [production] [staging]                       │
└─────────────────────────────────────────────────────────────┘

---