Choisir un modèle simple de branches Git

Pour un premier projet d’équipe, adoptez un modèle de branches simple : la branche main reste déployable, et chaque tâche dispose de sa propre branche de fonctionnalité à courte durée de vie. Si l’équipe développe une landing page en React et une API de paiement, les tâches peuvent être réalisées dans feature/pricing-page et feature/create-checkout-session plutôt que dans une branche de développement partagée. Cette séparation permet à deux développeurs de travailler en parallèle sans mélanger du code inachevé. Évitez d’ajouter des branches develop, release ou hotfix tant que le projet ne nécessite pas un véritable processus de mise en production.

Mettez-vous d’accord sur le workflow avant de commencer le premier ticket. Indiquez que les modifications de main passent par une pull request, que les branches de fonctionnalité sont créées à partir de main et que les branches fusionnées sont supprimées. Par exemple, une tâche de réinitialisation du mot de passe doit suivre le parcours ticket, branche de fonctionnalité, revue, puis main, sans push direct vers la branche partagée. Ces règles font du contrôle de version une habitude d’équipe prévisible plutôt qu’un ensemble de préférences individuelles.

Configurer main et les règles de nommage des branches

Protégez main dans les paramètres du dépôt avant que quiconque n’ouvre une pull request. Exigez la réussite des vérifications automatisées et au moins une approbation, et interdisez les push forcés afin qu’une erreur locale ne puisse pas réécrire l’historique partagé de l’équipe. Pour une équipe de quatre personnes, demander une seule approbation est souvent une règle de départ pratique ; renforcez cette exigence pour le code sensible lié aux paiements ou à l’authentification. Consignez la règle dans CONTRIBUTING.md afin qu’un nouveau membre de l’équipe puisse la suivre sans avoir à demander une explication en privé.

Choisissez des noms de branches qui indiquent leur objectif et, si possible, l’identifiant de la tâche. Exemples : feature/42-reset-password, fix/57-cart-total, docs/api-setup et chore/update-node. Les noms en minuscules avec des traits d’union sont plus faciles à parcourir dans la sortie du terminal et les listes de pull requests que des noms comme John'sNewBranch ou work. Supprimez les branches après leur fusion afin que la liste distante reflète les travaux en cours, au lieu de s’encombrer d’expériences abandonnées depuis des mois.

Démarrer les fonctionnalités à partir d’une branche main à jour

Avant de coder, synchronisez-vous avec le dépôt distant et créez la branche de fonctionnalité à partir de la branche main actuelle. Exécutez git switch main, puis git pull --ff-only origin main, et créez la branche avec git switch -c feature/42-reset-password. L’option --ff-only empêche Git de créer silencieusement un commit de fusion inattendu pendant cette mise à jour. Partir d’une base à jour réduit le risque qu’une tâche de trois jours entre immédiatement en conflit avec une modification fusionnée la veille.

Vérifiez le nom de la branche et son point de départ avec git status et git log --oneline --decorate -5 avant de modifier les fichiers. Si la tâche dispose déjà d’une branche existante, commencez par exécuter git fetch origin et comparez-la avec origin/main au lieu de créer une seconde branche portant un nom similaire. Pour une branche en retard d’un commit, vous pouvez la mettre à jour avec git rebase origin/main après avoir vérifié que votre travail local est bien enregistré dans un commit. Ne faites pas de rebase sur une branche utilisée activement par plusieurs coéquipiers, sauf si l’équipe a accepté la réécriture de l’historique qui en résultera.

Créez des commits Git de petite taille et faciles à examiner

Créez des commits suffisamment petits pour qu’un autre développeur puisse comprendre chaque modification en une ou deux minutes. Une fonctionnalité de paiement peut utiliser un commit pour la migration de base de données, un autre pour l’endpoint et un troisième pour le formulaire, tandis qu’une correction de faute de frappe de trois lignes devrait généralement rester dans un seul commit. Exécutez les tests pertinents avant chaque push, car un commit facile à examiner mais qui échoue dans la suite de tests existante ralentit malgré tout l’équipe. N’incluez pas dans la branche les fichiers générés, les secrets de l’environnement local ni les modifications de formatage sans rapport.

Rédigez les messages de commit à l’impératif, par exemple Add password reset validation ou Fix cart total rounding. Chaque message doit expliquer l’intention, tandis que le diff présente les détails de l’implémentation. Après avoir vérifié le résultat localement, publiez une nouvelle branche avec git push -u origin feature/42-reset-password. Si vous découvrez une erreur avant la revue, corrigez-la avec amend ou squash localement ; une fois que les réviseurs ont commencé à commenter, préférez un nouveau commit correctif afin que la discussion reste traçable.

Ouvrez une Pull Request et exécutez la CI

Ouvrez la pull request dès que la branche est prête à être examinée, même si la modification ne concerne que six fichiers. Définissez main comme branche cible, associez la tâche, décrivez les changements et indiquez la commande exacte de validation, par exemple npm test et npm run lint. Pour une modification du formulaire de connexion, incluez la route concernée, le comportement au clavier, une capture d’écran de l’état d’erreur et toute étape de migration qu’un réviseur doit exécuter. Ne marquez la demande comme brouillon que si vous souhaitez recueillir des retours préliminaires avant de demander une approbation.

Utilisez l’intégration continue pour exécuter sur la pull request les mêmes contrôles qualité que ceux attendus par l’équipe sur le poste d’un développeur. Un premier pipeline utile peut installer les dépendances, exécuter les tests unitaires, lancer le linting et compiler l’application en quatre étapes distinctes et visibles. Si la compilation échoue parce qu’un fichier package-lock a été omis, corrigez la branche et poussez à nouveau vos modifications au lieu de demander au réviseur d’ignorer le contrôle en échec. La CI est un indicateur, pas un substitut à la revue : un test peut réussir alors qu’un bouton reste inaccessible ou qu’une réponse d’API expose des données privées.

Examinez, fusionnez et préservez la stabilité de main

Considérez les commentaires de revue comme des modifications apportées à la conception partagée, et non comme un vote sur l’auteur. Si un réviseur demande une validation côté serveur pour un champ de prix, modifiez le code, ajoutez un test ciblé pour une valeur négative telle que -1 et répondez en indiquant le commit ou l’emplacement du fichier. Résolvez les questions dans la pull request afin que l’historique final explique pourquoi l’implémentation a changé. Demandez un second réviseur lorsque le premier commentaire révèle une préoccupation plus large concernant la sécurité, la perte de données ou le comportement de l’API publique.

Choisissez une stratégie de fusion et appliquez-la de manière cohérente. Pour un premier projet, fusionner une fonctionnalité composée de cinq commits en un seul commit descriptif par squash permet de garder main lisible, tandis que les équipes qui ont besoin d’un historique détaillé des versions peuvent conserver les commits individuels. Ne fusionnez qu’une fois les vérifications requises réussies, les approbations à jour et la branche à jour par rapport à main, conformément aux règles du dépôt. Après la fusion, signalez toute étape manuelle de déploiement ou de migration avant de commencer la tâche suivante.

Résoudre les conflits et nettoyer les branches

Lorsque main évolue pendant votre travail, mettez votre branche à jour avant de demander l’approbation finale. Récupérez les références du dépôt distant, exécutez git rebase origin/main et résolvez les conflits un fichier à la fois ; par exemple, conservez la dernière version du composant de bouton partagé tout en préservant le nouveau comportement de votre parcours de paiement. Après avoir modifié un fichier en conflit, exécutez git add sur ce fichier, puis git rebase --continue et relancez les tests. Si le conflit devient difficile à gérer, git rebase --abort rétablit la branche dans son état antérieur au rebase, ce qui vous permet de demander de l’aide sans perdre le travail déjà commité.

Une fois la pull request fusionnée, supprimez la branche distante avec git push origin --delete feature/42-reset-password et la copie locale avec git branch -d feature/42-reset-password. Exécutez ensuite git switch main, puis git pull --ff-only origin main avant de choisir le prochain ticket. S’il reste du travail inachevé, créez une nouvelle branche à partir de main mis à jour au lieu de poursuivre sur une branche déjà fusionnée. Au bout d’une semaine, le dépôt devrait présenter une branche main stable, un petit nombre de tâches en cours et un historique qui explique chaque changement visible par les utilisateurs.

Articles associés

Pour aller plus loin

Git

gestion de versions

intégration continue