Git Flow

Git Flow and Deployment Strategy

Overview

This document outlines the branching strategy, versioning scheme, and deployment workflow for the project.

Branches

Main Branches

• main - Production-ready code

  • Reflects the current production environment
  • Only receives merge commits from develop
  • Protected branch with strict merge requirements

• develop - Staging environment

  • Integration branch for features
  • Receives squash & merge commits from feature branches
  • Continuously deployed to staging environment

Release Branches

• release-v{X} - Temporary branches for future major/minor versions
  • Created when development begins on version n+2 while version n is still in progress
  • Example: Create release-v2 to begin work on V2 while MVP (V1) is being completed
  • Features for the future version are temporarily merged here
  • Once the current version is released and develop transitions to the new version, these branches can be merged or replaced

Hotfix Branches

• hotfix/* - Emergency production fixes
  • Branched from main
  • Merge via merge commit to main
  • Also merge via merge commit to develop to keep branches in sync

Merge Strategies

Source	Destination	Merge Type
Feature branches	develop	Squash & Merge
develop	main	Merge Commit
hotfix	main	Merge Commit
hotfix	develop	Merge Commit

Release Schedule

• Production (main): Approximately every 3 months
• Staging (develop): Continuous deployment on every commit

Versioning

Format: [MAJOR/MINOR].[PATCH]

• MAJOR/MINOR increments: Triggered by features
• PATCH increments: Triggered by fixes, chores, documentation, refactors, CI/CD changes, etc.

Versioning follows semantic versioning principles with automation via GitVersion and semantic-release.

Deployment Workflow

The production deployment process follows these automated steps:

1. Merge to Main

   • Merge develop into main using a merge commit
   • This triggers the CI/CD pipeline

2. Generate Version Tag

   • GitVersion generates a new version tag based on commit history and versioning rules
   • Tag is created and pushed to the repository

3. Generate Release Notes

   • semantic-release automatically generates release notes based on commits
   • Notes are published to the GitHub release page
   • The release corresponds to the generated version tag

4. Deploy to Production

   • Deployment to production environment is automatically triggered following release notes generation
   • Deployment uses the generated version tag for traceability

Git Flow example :

---
config:
  theme: redux-dark-color
---
gitGraph
    %% Commit initial sur main taggé v1.0
    commit id: "last merge commit" tag: "v1.0"
    
    %% Création de develop depuis main
    branch develop
    checkout develop
    commit id: "init dev"
    
    %% Création de feature 1 et feature 2 depuis develop
    branch feature-1
    checkout develop
    branch feature-2
    
    %% Un commit sur feature 2
    checkout feature-2
    commit id: "commit feat2"
    
    %% Merge de feature 2 sur develop (squash merge)
    checkout develop
    merge feature-2 id: "squash feat2"
    
    %% Un commit sur feature 1
    checkout feature-1
    commit id: "commit feat1"
    
    %% Rebase de feature 1 sur develop (Simulé chronologiquement)
    commit id: "rebase (feat2)"
    
    %% Merge de feature 1 sur develop
    checkout develop
    merge feature-1 id: "squash feat1"
    
    %% develop est mergé sur main avec le tag v2.0
    checkout main
    merge develop id: "merge commit develop" tag: "v2.0"

Loading

---
config:
  theme: redux-dark-color
---
gitGraph
    %% Commit initial sur main taggé v1.0
    commit id: "last merge commit" tag: "v1.0"
    
    %% Création de develop depuis main
    branch develop
    checkout develop
    commit id: "init dev"
    
    %% Création de feature 1 et feature 2 depuis develop (qui a maintenant son propre point)
    branch feature-1
    checkout develop
    branch feature-2
    
    %% Un commit sur feature 2
    checkout feature-2
    commit id: "commit feat2"
    
    %% Merge de feature 2 sur develop (squash merge)
    checkout develop
    merge feature-2 id: "squash feat2"
    
    %% Création de hotfix 1 depuis main
    checkout main
    branch hotfix/my-fix-1
    checkout hotfix/my-fix-1
    commit id: "commit hotfix"
    
    %% Merge de hotfix 1 sur main avec tag v1.1
    checkout main
    merge hotfix/my-fix-1 id: "merge commit hotfix" tag: "v1.1"
    
    %% Merge de hotfix 1 sur develop
    checkout develop
    merge hotfix/my-fix-1 id: "merge hotfix on dev"
    
    %% Un commit sur feature 1
    checkout feature-1
    commit id: "commit feat1"
    
    %% --- AJOUTS ET CORRECTIONS ---
    %% Rebase de feature 1 sur develop (Simulé chronologiquement par un commit d'alignement)
    commit id: "rebase (feat2+hotfix)"
    
    %% Merge de feature 1 sur develop (merge commit)
    checkout develop
    merge feature-1 id: "squash feat1"
    %% -----------------------------
    
    %% Branche feature-3 tirée de develop
    branch feature-3
    
    %% Branche release-v3 (tirée de develop) avec un commit direct (feature 4)
    checkout develop
    branch release-v3
    checkout release-v3
    commit id: "squash feat4"
    
    %% feature-3 a un commit, puis est mergée sur develop
    checkout feature-3
    commit id: "commit feature-3"
    checkout develop
    merge feature-3 id: "squash feat3"
    
    %% develop est mergé sur main avec le tag v2.0
    checkout main
    merge develop id: "merge commit develop" tag: "v2.0"
    
    %% release-v3 rebase develop
    checkout release-v3
    commit id: "rebase develop"
    
    %% release-v3 est mergée sur develop
    checkout develop
    merge release-v3 id: "merge commit release-v3"

Loading