Develop Branch dans Git — ce que c'est, objectif et principes de fonctionnement

Qu'est-ce que Develop Branch dans Git

Develop Branch (branche de développement) est une branche de longue durée dans Git Flow qui sert de hub central pour l'intégration du code de tous les développeurs. Les branches feature y sont fusionnées après la fin du développement et la revue de code.

Le code dans develop est toujours dans un état prêt à créer une release, bien qu'il ne soit pas encore déployé en production. Cela signifie que toutes les fonctionnalités dans develop ont passé la revue, les tests et les vérifications d'intégration, mais attendent encore leur cycle de release.

Contrairement à main, où chaque version de code est une release, develop contient un flux continu de modifications. Les commits dans develop apparaissent au fur et à mesure que les branches feature sont fusionnées, ce qui peut se produire plusieurs fois par jour.

Selon Vincent Driessen, 2010, develop est un élément clé d'un modèle de branchement réussi, car il sépare le travail de brouillon des versions prêtes pour la release.

Différences entre develop et main branch

Comprendre les différences entre develop et main est essentiel pour un workflow Git Flow correct. Ces branches ont des fonctions différentes et des exigences de stabilité différentes.

La séparation en develop et main permet à l'équipe d'intégrer continuellement du nouveau code sans risquer la stabilité de la version de production. Les développeurs peuvent voir leur code dans develop immédiatement après l'approbation du PR, même avant la release officielle.

Rôle de develop dans Git Flow

Dans le modèle Git Flow, develop occupe une place centrale entre les branches feature (source des modifications) et les branches release (préparation à la release). Comprendre cette hiérarchie est la base d'un branchement efficace.

• Feature → Develop — chaque fonctionnalité terminée est fusionnée dans develop via une Pull Request avec revue de code.
• Develop → Release — lorsque suffisamment de modifications sont accumulées pour une release, une branche release est créée à partir de develop.
• Release → Main + Develop — après la préparation finale, la branche release est fusionnée dans main (release) et de nouveau dans develop (corrections de bugs).
• Hotfix → Main + Develop — les corrections critiques sont créées à partir de main et fusionnées dans les deux branches.

Cette structure garantit que develop contient toujours le code le plus récent avec toutes les nouvelles fonctionnalités, tandis que main contient uniquement du code de production vérifié. Ceci est particulièrement important pour les projets mobiles avec de longs cycles de révision dans l'App Store et Google Play.

Relation de develop avec les autres branches Git Flow

Develop sert de lien central entre les branches feature, release et hotfix. Comprendre les directions de fusion est essentiel pour prévenir les conflits et la perte de commits.

Exigences de qualité du code dans develop

La qualité du code dans develop doit être élevée, mais pas absolue. Contrairement à main, où chaque erreur signifie un hotfix urgent, develop permet des imperfections mineures qui seront corrigées avant la release.

Exigences minimales pour le code avant la fusion dans develop :

• Compilation — le code doit compiler sans erreur. Une compilation cassée dans develop bloque le travail de toute l'équipe.
• Tests unitaires — tous les tests existants doivent réussir. Le nouveau code doit être couvert par des tests à au moins 70%.
• Style de code — le code doit être conforme aux normes de formatage et de nommage acceptées par l'équipe.
• Pas d'API obsolète — l'utilisation de méthodes obsolètes n'est pas autorisée dans le nouveau code.

Les vérifications automatisées dans le pipeline CI/CD doivent s'exécuter à chaque push dans develop. Si la compilation casse, le développeur responsable doit corriger le problème dans l'heure ou annuler son commit.

Vérifications CI/CD pour develop

La configuration de GitHub Actions pour develop garantit que chaque PR passe par des vérifications automatisées avant la fusion. Un pipeline typique comprend la compilation, les tests et le linting.

# GitHub Actions — vérification de develop après fusion
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Règles de fusion dans develop

La fusion dans develop doit suivre des règles strictes pour maintenir la stabilité de la branche d'intégration. La violation de ces règles entraîne des conflits, des compilations cassées et une perte de temps pour l'équipe.

• Uniquement via Pull Request — le push direct dans develop est interdit. Toutes les modifications passent par une revue de code.
• Minimum une approbation — le PR doit être approuvé par au moins un développeur non impliqué dans la tâche.
• Squash merge — il est recommandé de fusionner tous les commits de la branche feature en un seul lors de la fusion dans develop pour un historique propre.
• PR à jour — avant la fusion, le PR doit être mis à jour par rapport au dernier commit de develop (rebase ou merge).

La règle du PR à jour est particulièrement importante. Si une branche feature a été créée il y a une semaine et que develop a avancé de 50 commits, la fusion directe pourrait entraîner des conflits qu'il est préférable de résoudre dans le contexte du PR plutôt que dans develop.

Protection de develop contre les fusions incorrectes

Les règles de protection de branche sont des paramètres au niveau de GitHub, GitLab ou Bitbucket qui empêchent les modifications incorrectes dans develop. Elles garantissent que même un push accidentel ne casse pas la branche d'intégration.

Règles de protection recommandées pour develop :

• Exiger une pull request — interdire le push direct dans develop. Toutes les modifications uniquement via PR.
• Exiger des approbations — minimum 1 à 2 approbations avant de fusionner le PR.
• Exiger des vérifications de statut — bloquer la fusion si le pipeline CI/CD n'a pas réussi.
• Exiger la mise à jour — la branche du PR doit être mise à jour par rapport à develop avant la fusion.
• Restreindre l'accès push — limiter les droits de push dans develop aux seuls développeurs seniors.

La configuration de la protection de develop prend 10 minutes mais évite des semaines d'indisponibilité liées à une branche d'intégration cassée. Pour les projets mobiles avec des équipes multiplateformes, c'est particulièrement pertinent.

Exemples de commandes pour travailler avec develop

Considérons une journée typique d'un développeur : le matin, il met à jour develop, crée une nouvelle branche feature et, après avoir terminé la tâche, fusionne les modifications dans develop.

# Synchronisation matinale de develop
git checkout develop
git pull origin develop

# Création d'une nouvelle branche feature depuis develop
git checkout -b feature/add-push-notifications

# Travail sur la fonctionnalité...
git add . && git commit -m "Add FCM integration"

# Mise à jour de develop pendant le développement
git fetch origin develop
git rebase origin/develop

# Après approbation du PR — mise à jour du develop local
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

La commande git pull dans develop effectue deux opérations à la fois : git fetch (récupère les nouveaux commits du serveur) et git merge (les fusionne avec la branche locale). Pour develop, c'est la méthode de synchronisation standard.

Récupération de develop après une fusion cassée

Si du code qui a cassé la compilation arrive dans develop, il faut agir rapidement. Chaque heure d'indisponibilité de develop est un travail bloqué pour toute l'équipe de développement.

Si du code qui a cassé la compilation arrive dans develop, utilisez git revert pour créer un nouveau commit qui annule les modifications problématiques. N'utilisez pas git reset dans develop — cela réécrit l'historique que les autres membres de l'équipe possèdent déjà.

# Recherche du commit problématique
git log --oneline develop

# Annulation de commit via revert (sûr)
git revert a1b2c3d

# Envoi de la correction vers develop distant
git push origin develop

# Affichage des modifications dans un commit spécifique
git show a1b2c3d --stat