Git avancé : collaboration d'équipe et gestion des branches

Introduction

Un collègue m’a tagué dans le groupe : « Ton merge vient d’écraser ma fonction de connexion, les utilisateurs ne peuvent plus se connecter en prod… »

J’ouvre le code : des marqueurs de conflit partout, impossible de distinguer mon code du sien. Cette nuit-là, j’ai compris : savoir les commandes Git de base ne suffit pas pour travailler en équipe.

Branches introuvables, peur de merger, historique illisible — si ça vous parle, cet article est pour vous. Retour d’expérience sur le choix du workflow, la résolution des conflits, le rebase et la revue de code. À la fin : stratégie de branches adaptée à l’équipe, conflits gérés proprement, historique rangé, processus de revue efficace.

Chapitre 1 : Choisir le workflow Git adapté à votre équipe

Au début, en tant que lead, je ne savais pas quel workflow adopter. On m’avait dit que Git Flow était « pro », on l’a copié — une équipe de 5 personnes y passait une demi-heure par jour à gérer les branches. Tout le monde en avait marre.

Il n’y a pas de workflow parfait, seulement celui qui convient.

Git Flow vs GitHub Flow vs Trunk Based Development

En résumé :

Git Flow — usine avec chaîne stricte : develop, feature, release, hotfix. Microsoft, IBM, grosses structures avec cycles de release mensuels.

Pour une petite équipe, c’est lourd. Chaque release : branche release depuis develop, tests, merge dans master, retour vers develop — épuisant.

GitHub Flow — une branche principale (main/master), features en branches, PR pour merger. Idéal pour 3-10 personnes, itérations rapides et livraison continue.

Mon équipe actuelle utilise GitHub Flow + CI/CD : plusieurs déploiements par jour, règles simples à retenir.

Trunk Based Development — tout le monde sur la branche principale, branches de moins d’un jour. Google, Facebook, avec tests automatisés massifs.

Pour une équipe « classique », le TBD est agressif sans ~90 % de couverture de tests.

Tendance 2025

Le modèle hybride domine : petites équipes (1-10) sur GitHub Flow + Actions ou GitLab CI ; équipes moyennes combinent Git Flow et GitHub Flow.

Exemple : 20 personnes, « GitHub Flow + branche release » — quotidien en GitHub Flow, branche release avant chaque version stable.

Recommandations :

• 1-5 personnes : GitHub Flow, point final
• 5-15 : GitHub Flow + release simplifiée
• 15+ : Git Flow ou hybride, avec CI/CD solide

Ne sur-concevez pas. Trop de règles au départ → personne ne les suit → retour au chaos individuel.

Chapitre 2 : Règles d’or de la gestion des branches

Le pire cauchemar : 70 branches distantes, la moitié mortes depuis deux ans. Trouver la sienne prenait des plombes.

Voici les règles qui ont nettoyé le dépôt.

Convention de nommage

Préfixes obligatoires :

• feature/ — nouvelle fonctionnalité
• bugfix/ — correction de bug
• hotfix/ — correctif urgent
• release/ — publication

Plus le numéro de tâche : feature/JIRA-1234-user-login

On voit tout de suite le but et le responsable. Une branche test oubliée trois mois — personne ne sait plus à quoi elle sert.

À éviter :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• Noms en chinois (affichage parfois cassé)
• Espaces, @, caractères spéciaux
• Tirets - entre les mots, pas _

Cycle de vie des branches

Le pire cas vu : une feature ouverte trois mois, conflits ingérables, réécriture complète.

Règle actuelle : durée de vie feature ≤ 3 jours. Gros chantier → plusieurs petites features mergées en série.

Supprimer la branche juste après le merge — l’historique Git conserve tout.

# Supprimer la branche locale
git branch -d feature/xxx
# Supprimer la branche distante
git push origin --delete feature/xxx

Nettoyage des branches déjà mergées :

# Voir les branches mergées dans main
git branch --merged main
# Suppression en masse (à utiliser avec prudence)
git branch --merged main | grep -v "main" | xargs git branch -d

Protection de la branche principale

Au début, push direct sur main autorisé — un stagiaire a poussé du code incomplet, environnement de test down.

Règles GitHub/GitLab :

• Pas de push direct sur main, PR/MR obligatoire
• Au moins 1 approbation
• CI verte (tests, lint)

Settings → Branches → Branch protection rules.

Ça paraît lourd, mais ça évite des erreurs bêtes — et la revue fait monter le niveau de l’équipe.

Chapitre 3 : Git Rebase vs Merge — quand utiliser quoi ?

Premier git rebase : tous les IDs de commit ont changé, j’ai cru avoir perdu le code.

Merge et rebase fusionnent le code, mais la logique diffère.

Différence fondamentale

Merge — deux rivières qui se rejoignent, confluence visible, rivière plus large. Un merge commit, bifurcations dans l’historique.

Rebase — l’affluent versé dans le principal : une rivière linéaire. Historique réécrit, commits « déplacés », IDs nouveaux.

Techniquement :

• Merge : historique complet, création et fusion des branches conservées
• Rebase : historique linéaire, contexte de branche perdu

Cas d’usage et règle d’or

Merge :

• Fusion finale feature → main
• Branches partagées d’équipe
• Conserver l’historique de fusion

Rebase :

• Feature en retard sur main
• Ranger sa branche perso (avant push)
• Historique linéaire souhaité

Règle d’or :

Ne jamais rebaser des commits déjà poussés sur une branche partagée !

Les IDs changent ; si un collègue a basé son travail sur vos anciens commits, tout se casse. Un collègue l’a fait — une semaine de grogne, branches à refaire.

Principe : rebase librement en local, réfléchir avant de pousser.

Rebase interactif en pratique

git rebase -i est très puissant.

Dix commits du type « fix », « modif », « encore » — avant merge sur main, regroupés en 3 commits propres avec git rebase -i.

# Ranger les 10 derniers commits
git rebase -i HEAD~10

Dans l’éditeur :

pick a1b2c3d Ajout connexion utilisateur
pick e4f5g6h Correction bug connexion
pick i7j8k9l Encore
pick m0n1o2p Optimisation connexion
...

Actions possibles :

• pick — garder le commit
• squash ou s — fusionner avec le précédent
• reword ou r — modifier le message
• edit ou e — pause pour modifier le contenu
• drop ou d — supprimer le commit

Exemple :

pick a1b2c3d Ajout connexion utilisateur
squash e4f5g6h Correction bug connexion
squash i7j8k9l Encore
reword m0n1o2p Optimisation connexion

Les trois premiers fusionnent ; le quatrième demande un nouveau message.

Au début c’est déroutant ; après quelques essais, fini les « modif », « re-modif », « encore modif ».

Pratique 2025 : rebase en local, merge sur main — historique principal lisible, merges importants tracés.

Chapitre 4 : Les conflits sans panique

Premier conflit : <<<<<<< et >>>>>>> partout — j’ai tout supprimé et tout réécrit. Mauvaise idée.

Les conflits sont gérables si on comprend les marqueurs et qu’on prévient.

Prévenir les conflits

1. Synchroniser main chaque jour

git checkout main
git pull origin main
git checkout feature/xxx
git merge main  # ou git rebase main

La feature ne dérive pas trop de main.

2. Petits commits, merge rapide

Feature ≤ 3 jours — plus elle vit, plus le delta et le risque de conflit.

3. Communiquer

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Même fichier modifié par deux personnes → se parler. Tableau Notion « en cours » : qui touche quoi.

Marqueurs et résolution manuelle

Exemple de marqueurs :

<<<<<<< HEAD
function login(username, password) {
  // votre code
  return api.post('/login', { username, password });
}
=======
function login(email, password) {
  // code du collègue
  return api.post('/auth/login', { email, password });
}
>>>>>>> feature/new-login

• Entre <<<<<<< HEAD et ======= : votre branche
• Entre ======= et >>>>>>> feature/new-login : branche entrante

Décider quoi garder ou fusionner — username ou email ? quel chemin d’API ? — puis :

git add .
git commit -m "Résolution conflit fusion connexion"

Outils visuels

VS Code surligne les conflits : Accept Current Change, Accept Incoming Change, Accept Both Changes, Compare Changes.

Conflits lourds : git mergetool + p4merge (base / votre version / version distante).

Vérification après résolution

Une fois, conflit « résolu », push — logique critique du collègue supprimée, incident prod.

Routine :

1. Tests locaux
2. git diff pour vérifier les suppressions
3. Relecture par le collègue si possible

Quelques minutes qui évitent des nuits blanches.

Chapitre 5 : Revue de code efficace

Au début, je détestais la revue : « mon code est bon », allers-retours interminables.

En devenant relecteur, j’ai vu que la valeur dépasse le « trouver des bugs ».

Vraie valeur de la revue

1. Partage — savoir ce que font les autres, éviter les silos. Plusieurs astuces apprises en relisant des PR.

2. Qualité — un regard externe. Récursion sans cas limite repérée en revue, stack overflow évité.

3. Croissance — lire du bon code des seniors : meilleure école.

Bonnes pratiques PR

Taille

200-400 lignes idéal, max ~500. Au-delà, revue superficielle. Gros chantier → PR1 modèles, PR2 inscription, PR3 connexion, PR4 profil.

Description

Modèle d’équipe :

## Contexte
Pourquoi ce changement
## Changements
- Nouvelle fonctionnalité xxx
- Correction bug xxx
- Refactor module xxx
## Tests
- [ ] Tests unitaires OK
- [ ] Tests manuels OK
- [ ] Validé en environnement de test
## Points d'attention
Config, migration base, etc.

Messages de commit

Conventional Commits :

• feat: ajout connexion utilisateur
• fix: validation mot de passe
• refactor: couche service utilisateur
• docs: mise à jour doc API

Changelog auto, historique navigable.

Relecteur et auteur

Relecteur :

• Réponse sous 24 h
• Commentaires constructifs avec raison
• Logique, lisibilité, bugs — pas le style (lint)

Auteur :

• Répondre aux commentaires
• Expliquer la conception
• Écouter les suggestions

Avant : « c’est faux, changez ». Maintenant : « cette boucle peut coûter cher sur gros volume ; envisager X ou Y, qu’en pensez-vous ? » — bien mieux.

Tendance 2025 : revue assistée par IA

GitHub Code Quality (octobre 2025) : maintenabilité, sécurité.

Utile pour exceptions non gérées, fuites mémoire, complexité cyclomatique élevée.

L’IA ne remplace pas l’humain sur le design et le métier.

Workflow actuel : scan IA pour le technique, humain pour architecture et logique métier.

Chapitre 6 : Erreurs courantes et pièges

Danger du push forcé

Feature en retard, rebase, push refusé — j’ai trouvé git push -f et écrasé le travail d’un collègue. Heureusement, backup.

git push -f / --force écrase l’historique distant sans regarder les commits distants.

Autorisé : branche feature perso, seul utilisateur.

Interdit : main/master, toute branche partagée.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Si vraiment nécessaire : git push --force-with-lease (échoue si nouveaux commits à distance).

Autres erreurs fréquentes

1. Dev sur main

Même un caractère : branche + PR pour trace et rollback.

2. Commits bâclés

« fix », « modif », « 111 », « asdf » — inutiles six mois plus tard.

3. Branches non supprimées

Supprimer après merge ; option auto sur GitHub/GitLab à cocher.

4. git add . aveugle

Tout en staging, y compris .env avec mots de passe. Préférer git add -p.

Checklist Git d’équipe

Branches

• Préfixes feature/, bugfix/, etc.
• Numéro de tâche dans le nom
• Feature ≤ 3 jours
• Suppression après merge
• Protection de main

Commits

• Conventional Commits
• Un sujet par commit
• Lint et tests avant push
• Pas de secrets (.env, clés)

Revue

• PR 200-400 lignes
• Description (contexte, changements, tests)
• ≥ 1 approbation
• CI verte
• Réponse < 24 h

Conflits

• Sync main quotidienne
• Tests après résolution
• Discussion si doute

Interdit

• Pas de dev direct sur main
• Pas de git push -f sur branches partagées
• Pas de rebase de commits déjà poussés en partagé
• Pas de code non testé

Conclusion

Cette nuit à 2 h en prod, j’aurais voulu connaître tout ça. Les galères deviennent de l’expérience.

Git n’est pas difficile ; le dur, c’est l’accord d’équipe. Sans adhésion, le meilleur workflow ne sert à rien.

Commencez simple, optimisez progressivement. Pas de charte monstre d’un coup.

Exemple :

• Semaine 1 : nommage des branches
• Semaine 2 : protection main
• Semaine 3 : processus PR
• Semaine 4 : Conventional Commits

Laissez le temps d’adaptation.

Communiquez. Beaucoup de « conflits Git » sont des problèmes de communication.

Ressources :

• Atlassian Git Tutorial
• Pro Git — gratuit en ligne
• GitKraken ou SourceTree — clients visuels pour débuter

Prochain article possible : cherry-pick, stash, submodule — suivez-nous si ça vous intéresse.

Bonne collaboration Git — et plus de réveils à 2 h pour des merges mal réglés !