IREX - Bonnes pratiques de gestion des branches GitLab

Sommaire

• 1. Introduction
• 2. Objectif
• 3. Les branches principales
• 4. Les branches secondaires
• 5. Fast-Forward et correctifs MUAT
• 6. Règles de nommage
• 7. Voir aussi

Introduction

Dans tout projet logiciel, la manière dont on gère les branches peut faire la différence entre un flux de travail fluide et une véritable pagaille. Sans cadre clair, on finit vite avec des correctifs urgents poussés directement en production, des divergences difficiles à rattraper et un historique illisible. L’objectif de ce guide est de présenter une convention simple et cohérente pour gérer efficacement les branches dans les projets IREX. Vous verrez qu’avec quelques règles bien posées, on peut réduire drastiquement les risques de conflits et améliorer la collaboration entre développeurs.

Objectif

Standardiser l’utilisation des branches afin d’assurer :

• Une meilleure collaboration entre développeurs,
• Une traçabilité claire du code,
• Une séparation nette entre développement, tests et production,
• Une réduction des conflits et des risques lors des mises en production.

Les branches principales

main

Rôle : branche de production. Elle contient uniquement du code validé et déployé en production.

• Branche protégée : pas de push direct
• Modifications uniquement via Merge Request depuis rc
• Reflète l’état actuel du service en production

rc (Release Candidate)

Rôle : environnement de pré-production (tests UAT).

• Reçoit les MRs depuis dev
• Utilisée pour les tests d’acceptation utilisateurs (MUAT)
• Les correctifs détectés en MUAT suivent le cycle : task/* → dev → rc

Bonne pratique : garder rc le plus proche possible de main pour limiter les écarts au moment du déploiement.

develop

Rôle : environnement d’intégration de tous les développements.

• Branche protégée : tout passe par MR depuis une branche enfant
• Point central où convergent toutes les fonctionnalités
• Contient du code instable (en cours de travail)

Bonne pratique : mettre à jour develop avant de créer une nouvelle branche.

Les branches secondaires

feature/*

Utilisée pour développer une nouvelle fonctionnalité importante. Issue de dev, fusionnée vers dev.

Exemples : feature/authentification-jwt, feature/dashboard-analytics

task/*

Correspond à une tâche précise issue du suivi (Jira, GitLab Issues…). Issue de dev, fusionnée vers dev.

Exemple : task/add-export-pdf

hotfix/*

Permet de corriger rapidement un bug en production. Issue de main, fusionnée vers main puis reportée dans dev et rc si nécessaire.

Exemples : hotfix/urgent-login-error, hotfix/payment-crash

Fast-Forward et correctifs MUAT

Pour éviter que dev, rc et main ne divergent, il est essentiel de préserver le fast-forward :

• Tous les correctifs doivent suivre le cycle complet : task/* → dev → rc → main
• Éviter de fusionner directement un correctif sur rc ou main
• En respectant cette règle, chaque incrément reste traçable et facile à déployer

Règles de nommage

Un bon nommage facilite la compréhension et la maintenance. Voici le standard proposé :

• feature/nom-fonctionnalite
• task/nom-tache
• bugfix/description
• hotfix/description

Voir aussi

• Déploiement automatique et sécurisé : La révolution DevSecOps qui transforme l'industrie logicielle