Feature Branch dans Git : ce que c'est, comment créer et travailler avec des branches

Qu'est-ce qu'un Feature Branch dans Git

Feature Branch (branche de fonctionnalité) est une branche temporaire dans Git créée à partir de develop pour développer une fonctionnalité spécifique. Contrairement aux branches longue durée main et develop, les branches feature existent pour un temps limité — de quelques heures à quelques semaines.

L'objectif principal de la feature branch est d'isoler les modifications liées à une tâche du reste du code. Le développeur peut expérimenter, faire de nombreux commits et même casser du code dans sa propre branche sans affecter le travail des autres membres de l'équipe.

Une fois le développement terminé, la branche feature est fusionnée dans develop via une Pull Request avec une revue de code obligatoire. Après la fusion, la branche est généralement supprimée pour garder le référentiel propre.

Selon Vincent Driessen, 2010, le modèle Git Flow avec des branches feature est devenu un standard de l'industrie grâce à la séparation claire des responsabilités entre différents types de branches.

Workflow avec Feature Branch

Le workflow avec les branches feature consiste en une séquence d'étapes que le développeur effectue pour chaque nouvelle fonctionnalité. Ce processus minimise les conflits de fusion et assure le contrôle qualité du code.

1. Création de la branche à partir du dernier commit de develop. Le développeur bascule sur develop, le met à jour et crée une nouvelle branche feature.
2. Développement et commits dans la branche feature. Le développeur apporte des modifications, effectue des commits avec des descriptions claires et pousse périodiquement la branche vers le référentiel distant.
3. Synchronisation avec develop — pendant le développement, la branche principale peut avancer. Le développeur effectue un rebase ou un merge de develop dans sa branche feature.
4. Création d'une Pull Request — lorsque la fonctionnalité est prête, le développeur ouvre une PR pour la revue de code. L'équipe examine le code et laisse des commentaires.
5. Fusion et suppression — après l'approbation de la PR, la branche est fusionnée dans develop et supprimée à la fois localement et à distance.

La synchronisation périodique avec develop est d'une importance cruciale. Plus une branche feature vit longtemps sans fusionner les modifications de develop, plus la probabilité de conflits lors de la fusion finale est élevée.

Fréquence de synchronisation de la branche feature

Règles de nommage des branches feature

Le nommage des branches est une partie importante de la discipline d'équipe. Un standard de nommage uniforme permet d'identifier rapidement sur quelle tâche on travaille et qui l'exécute.

• feature/nom — le préfixe feature/ est utilisé dans Git Flow classique. Exemple : feature/added-auth-module.
• feature/JIRA-123-description — lien vers le numéro de tâche dans le système de suivi. Exemple : feature/PROJ-42-add-login.
• feature/type/nom — format étendu avec indication du type de tâche. Exemple : feature/feat/analytics-dashboard.

L'utilisation de l'ID de tâche de JIRA, Trello ou d'un autre système est une meilleure pratique. Elle lie automatiquement le code à la tâche et simplifie la recherche de branches via git log.

Processus de Pull Request

Pull Request (ou Merge Request dans GitLab) est une demande de fusion de la branche feature dans develop. Une PR n'est pas seulement une opération technique, mais un processus de revue de code en équipe qui améliore la qualité du code et diffuse les connaissances au sein de l'équipe.

Une bonne PR contient un titre avec une brève description de la tâche, un lien vers le ticket et une description des modifications. Le développeur doit indiquer ce qui a été fait exactement, quels fichiers ont été modifiés et s'il existe des risques potentiels pour d'autres parties du projet.

L'équipe examine le code dans la PR, laisse des commentaires, demande des modifications (change requests) et approuve la fusion (approve). Après approbation, un merge ou squash merge est effectué.

Le temps moyen de revue d'une PR dans le développement mobile est de 4 à 24 heures. La bibliothèque Danger automatise une partie des vérifications en exécutant des linters et des tests directement dans la PR.

Recommandations pour créer une bonne PR

• Taille — pas plus de 300-400 lignes de modifications. Les grosses PR sont difficiles à revoir et la qualité de la revue diminue.
• Une PR — une tâche — évitez de mélanger des modifications non liées dans une même demande.
• Captures d'écran — pour les modifications d'interface, joignez des captures d'écran avant et après.
• Tests — pour les nouvelles fonctionnalités, écrivez des tests unitaires et incluez-les dans la PR.

Stratégies de fusion des branches feature

Après l'approbation de la PR, la branche feature peut être fusionnée dans develop de différentes manières. Le choix de la stratégie de fusion affecte l'historique des commits et la possibilité d'annuler les modifications.

• Merge commit — crée un commit de fusion, préservant tout l'historique des commits de la branche feature. L'historique reste complet, mais le graphe de branchement devient plus complexe.
• Squash merge — combine tous les commits de la branche feature en un seul et l'ajoute sur develop. L'historique devient plus propre, mais les informations sur les commits intermédiaires sont perdues.
• Rebase and merge — réécrit les commits de la branche feature sur le dernier commit de develop et fusionne sans commit supplémentaire. L'historique reste linéaire.

Pour les projets mobiles avec des versions fréquentes, le squash merge est le plus utilisé : il fournit un historique propre dans develop, tandis que les détails du développement restent dans la description de la PR et dans la tâche du tracker.

Erreurs typiques lors du travail avec Feature Branch

Même les développeurs expérimentés commettent des erreurs en travaillant avec des branches feature. Connaître les problèmes typiques permet d'éviter la perte de temps et de données.

• Vie trop longue de la branche — une branche feature vit plus de 2-3 semaines sans synchronisation avec develop, entraînant des conflits de fusion massifs.
• Commits avec des descriptions peu claires — des messages comme « fix » ou « update » ne permettent pas de comprendre ce qui a été modifié et pourquoi.
• Mélange de tâches — dans une même branche feature, deux fonctionnalités non liées sont développées, rendant impossible l'annulation sélective.
• Absence de synchronisation — le développeur n'effectue pas de git fetch et ne met pas à jour develop, ce qui entraîne des conflits lors de la fusion finale.

La meilleure façon d'éviter ces problèmes est de convenir des règles de travail au début du projet et d'utiliser des vérifications automatisées dans le pipeline CI/CD.

Exemples de commandes pour travailler avec Feature Branch

Considérons un scénario pratique : un développeur commence une nouvelle fonctionnalité d'authentification dans une application mobile. Il crée une branche feature, travaille sur le code et termine la tâche par une Pull Request.

# Mettre à jour develop et créer la branche feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Travail sur la fonctionnalité : commits
git add src/ui/login/
git commit -m "Add login screen layout"

# Pousser la branche feature vers le serveur distant
git push origin feature/add-login-screen

# Synchronisation avec develop (rebase)
git fetch origin develop
git rebase origin/develop

# Après approbation de la PR : mettre à jour develop local et supprimer la branche
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

La commande git branch -d supprime la branche uniquement après que ses modifications ont été entièrement fusionnées. Si la branche n'est pas fusionnée, Git suggérera d'utiliser git branch -D pour une suppression forcée — utilisez ce drapeau avec prudence.

Automatisation des vérifications dans la branche feature

Le pipeline CI/CD doit s'exécuter pour chaque branche feature avant de créer une PR. Cela permet de détecter les problèmes à un stade précoce, avant que le code n'arrive en revue par d'autres développeurs.

# GitHub Actions pour vérifier la branche feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Le pipeline vérifie que le code compile, que les tests passent et que le style de code est conforme aux normes de l'équipe. Ce n'est qu'après avoir passé toutes les vérifications qu'une Pull Request peut être créée.