Guide des workflows Git : branches, fusions et collaboration en équipe

Git est le socle du workflow de toute équipe logicielle moderne. Pourtant, beaucoup de développeurs n'utilisent que commit, push et pull — passant à côté des fonctionnalités qui rendent le développement collaboratif fluide et sans conflits. Ce guide couvre les stratégies de branches, les bonnes pratiques de commits et les commandes du quotidien utilisées par les équipes professionnelles.

Le modèle mental de base

Git est un graphe acyclique dirigé d'instantanés (commits). Chaque commit pointe vers son ou ses parents. Les branches ne sont que des pointeurs nommés vers des commits — légères et rapides à créer.

main:    A → B → C → D
feature:         C → E → F

Créer une branche ne copie pas les fichiers — cela crée simplement un nouveau pointeur. C'est pourquoi la création d'une branche prend quelques millisecondes, quelle que soit la taille du dépôt.

Stratégies de branches

GitHub Flow (simple, livraison continue)

Idéal pour les équipes qui déploient fréquemment :

1. main est toujours déployable
2. Créer une branche de fonctionnalité pour chaque modification
3. Ouvrir une pull request lorsqu'elle est prête pour la revue
4. Fusionner dans main après approbation
5. Déployer immédiatement

git checkout -b feature/add-user-auth
# ... effectuer les modifications ...
git push origin feature/add-user-auth
# Ouvrir la PR → revue → fusion → déploiement

Git Flow (releases structurées)

Idéal pour les produits avec des releases versionnées (applications, bibliothèques) :

• main — code de production uniquement
• develop — branche d'intégration
• feature/* — nouvelles fonctionnalités (branchées depuis develop)
• release/* — préparation des releases (branchées depuis develop)
• hotfix/* — correctifs urgents en production (branchés depuis main)

Plus structuré, mais implique une charge supplémentaire. Préférez GitHub Flow sauf si vous avez un réel besoin de gestion parallèle des releases.

Trunk-Based Development

Les développeurs commitent directement dans main (ou des branches éphémères de moins d'un jour). Les feature flags contrôlent ce que voient les utilisateurs. Nécessite un CI/CD robuste et une bonne couverture de tests. Utilisé par Google, Facebook et les équipes à haute vélocité.

Écrire de bons messages de commit

Le message de commit est une lettre à votre futur vous-même (et à vos coéquipiers). Suivez le format Conventional Commits :

<type>(<scope>): <résumé court>

<corps optionnel — quoi et pourquoi, pas comment>

<pied de page optionnel — changements cassants, références aux issues>

Types :

• feat — nouvelle fonctionnalité
• fix — correction de bug
• docs — documentation uniquement
• refactor — modification du code qui ne corrige pas un bug ni n'ajoute de fonctionnalité
• test — ajout ou correction de tests
• chore — processus de build, dépendances, outillage

Exemples :

feat(auth): add JWT refresh token rotation

Implements sliding session windows using refresh token rotation.
Previous tokens are invalidated on use to detect theft.

Closes #142

fix(api): return 404 instead of 500 for missing user

The /users/:id endpoint was throwing an unhandled exception when
the user didn't exist. Now returns a proper 404 with error message.

Règle d'or : Si votre message de commit est fix stuff ou WIP, votre équipe vous en veut. Soyez descriptif.

Merge vs. Rebase

Merge

git checkout main
git merge feature/my-feature

Crée un commit de fusion qui réunit deux branches. Préserve l'historique complet — vous pouvez voir exactement quand les branches ont divergé et fusionné.

A → B → C → M (commit de fusion)
         ↑   ↑
         E → F (feature)

Utilisez merge pour : intégrer des branches à longue durée de vie, préserver le contexte dans l'historique.

Rebase

git checkout feature/my-feature
git rebase main

Rejoue vos commits au-dessus de la branche cible. Crée un historique linéaire — comme si la fonctionnalité avait été développée à partir du dernier état de main.

Avant : A → B → C (main)
                 ↑
            D → E (feature, basée sur B)

Après : A → B → C → D' → E' (feature rebasée sur C)

Utilisez rebase pour : nettoyer les commits locaux avant une PR, maintenir les branches de fonctionnalités à jour.

Règle absolue : Ne rebasez jamais des commits qui ont été poussés sur une branche partagée. Le rebase réécrit l'historique — cela casse les branches locales des autres membres de l'équipe.

Rebase interactif : nettoyer l'historique

Avant d'ouvrir une PR, écrasez et fusionnez les commits de travail en cours désordonnés :

git rebase -i HEAD~4   # éditer interactivement les 4 derniers commits

Options dans l'éditeur interactif :

• pick — conserver le commit
• squash — fusionner avec le commit précédent, combiner les messages
• fixup — fusionner avec le commit précédent, ignorer le message
• reword — conserver les modifications, éditer le message
• drop — supprimer le commit entièrement

Gérer les conflits

Les conflits surviennent quand deux branches modifient les mêmes lignes. Git les marque ainsi :

<<<<<<< HEAD (votre branche)
const timeout = 5000;
=======
const timeout = 3000;
>>>>>>> feature/update-timeouts

Résolvez en éditant le fichier dans l'état correct (en supprimant les marqueurs), puis :

git add src/config.ts
git merge --continue   # ou git rebase --continue

Mieux vaut prévenir que guérir :

• Tirez régulièrement depuis main pour garder les branches de courte durée
• Communiquez avec vos coéquipiers lorsque vous travaillez sur les mêmes fichiers
• Gardez les PRs petites — les grandes PRs génèrent plus de conflits et des revues plus difficiles

Commandes essentielles du quotidien

# Démarrer une nouvelle fonctionnalité
git checkout -b feature/my-feature

# Indexer des modifications spécifiques (pas tout le fichier)
git add -p

# Voir les modifications non indexées
git diff

# Voir les modifications indexées
git diff --staged

# Modifier le dernier commit (avant de pousser)
git commit --amend --no-edit

# Sauvegarder temporairement le travail non commité
git stash
git stash pop

# Trouver quel commit a introduit un bug (recherche binaire)
git bisect start
git bisect bad              # le commit actuel est mauvais
git bisect good v1.2.0      # dernier commit connu comme bon

# Récupérer une branche supprimée ou un commit perdu
git reflog

# Afficher un graphe visuel des branches
git log --oneline --graph --all

Bonnes pratiques pour les pull requests

Une bonne PR :

• Fait une seule chose — les relecteurs peuvent comprendre l'ensemble de la modification
• A une description claire — ce qui a changé, pourquoi, et comment le tester
• Est petite — moins de 400 lignes de diff comme règle approximative
• Passe le CI — ne demandez jamais une revue sur un build cassé
• Référence l'issue — Closes #42 ferme automatiquement l'issue lors de la fusion

Utilisez notre README Generator pour générer la documentation en parallèle de vos modifications de code.

Les essentiels du .gitignore

Ajoutez toujours ces éléments à .gitignore :

# Variables d'environnement
.env
.env.local
.env.*.local

# Dépendances
node_modules/
vendor/

# Sortie de build
dist/
build/
.next/

# Fichiers système
.DS_Store
Thumbs.db

# Fichiers d'éditeur
.vscode/settings.json
.idea/
*.swp

Générez un .gitignore spécifique à votre projet sur gitignore.io — il prend en charge des centaines de langages et d'outils.

La maîtrise de Git se construit avec le temps. Assimilez le modèle mental, adoptez de bonnes habitudes de commit, et la collaboration au sein de votre équipe deviendra nettement plus fluide.