Internal
Git & PR Strategy

Git & PR Strategy

📌 Preface

This page outlines a set of best practices for Git workflow and pull request (PR) management.
The goal is to keep all projects structured, consistent, and understandable for every team member.
Following company-wide routines and procedures ensures efficiency and clarity across all projects.

🚀 Objective

Provide an elegantly structured, standardized workflow that combines:

  • Git Flow for structured branching
  • GitHub Flow for lightweight PR-driven collaboration
  • Conventional Commits for clear, semantic commit messages

🧠 Git Flow Overview

Git Flow is a branching model with a clear structure for collaboration:

  • Master/Main: Production-ready code.
  • Develop: Integration branch for feature development.

Feature Branches:

  • Created from develop.
  • Used to implement new features.
  • Merged back into develop when complete.

Release Branches:

  • Created from develop when preparing a release.
  • Allow final bug fixes and version updates.
  • Merged into both master and develop after release.

Hotfix Branches:

  • Created from master to fix critical production issues.
  • Merged into both master and develop.

🕒 GitHub Flow Overview

GitHub Flow focuses on pull requests for lightweight, branch-based collaboration:

  1. Branch: Create a branch for each new feature or bug fix.
  2. Commit: Make small, focused commits with clear messages.
  3. Pull Request: Open a PR to propose changes and initiate code review.
  4. Discuss & Review: Collaborate via discussion and code reviews.
  5. Deploy: Merge approved PRs into main for deployment.

🎯 Conventional Commits

Standardized commit messages improve clarity and traceability.

Format:

Elements:

  • Type: Purpose of the commit (feat, fix, chore, etc.)
  • Scope: Module or component affected
  • Description: Short, imperative statement in present tense

Example:

feat(user-auth): add registration endpoint

🛠️ Combined Strategy

Integrate Git Flow, GitHub Flow, and Conventional Commits:

1. Overview

  • Master/Main: Production-ready code
  • Release: Integration branch for features

2. Feature Development

  • Create branches from the latest release branch under release/.
  • Use Conventional Commits for all changes.
  • Merge feature into the latest release branch when complete.

3. Release Preparation

  • Create a release branch from develop.
  • Apply Conventional Commits for release updates.
  • Merge into master upon completion.

4. Hotfixes

  • Create hotfix branches from master.
  • Use Conventional Commits for all hotfix changes.
  • Merge into both master and latest release branch.

5. Pull Requests

  • PRs must follow Conventional Commits.
  • Review, discuss, and validate changes before merging.
  • Enforce branch protection for consistency.

📊 Branch Naming Conventions

Prefix Branches:

  • feature/ – new features
  • bugfix/ – bug fixes
  • hotfix/ – critical fixes

Pattern:

/ISSUE-ID_topic-name

Example:

feature/DEV-1492_Outlet-module-settings bugfix/DEV-1492_Outlet-module-settings hotfix/DEV-1492_Outlet-module-settings

Guidelines:

  • Use - between letters and numbers for clarity (DEV-1492)
  • Use _ to separate identifier and topic
  • Use - between words in the topic name (Outlet-module-settings)
  • Keep names readable and consistent for reviewers

📎 Demo Use Case

Assume issue DEV-1492 is assigned:

  1. Create Branch:

feature/DEV-1492_Outlet-module-settings

  1. Development:
  • Follow Conventional Commits for all commits
  • Keep commits small and descriptive
  1. Pull Request:
  • Name PR according to the same pattern
  • Ensure it’s easy to find and review among open PRs

This approach ensures consistency, readability, and smooth collaboration across the team.

FinancialsOverview