Guide complet de Git pour les développeurs freelance

En résumé : Au 5 septembre 2026, adoptez un GitHub Flow simplifié pour la plupart des missions freelance : main reste exploitable, chaque tâche vit sur une branche courte et chaque fusion passe par une pull request. Ajoutez Conventional Commits pour clarifier l’historique. Réservez GitFlow aux projets qui publient des versions planifiées ou maintiennent plusieurs versions en parallèle.

Git devient surtout exigeant lorsque vous alternez entre plusieurs projets, clients et équipes. Une stratégie de branches cohérente, des commits explicites et quelques contrôles avant chaque push évitent les erreurs coûteuses.

Quelle stratégie de branches choisir ?

Le choix de votre stratégie de branches dépend de la taille du projet, de la fréquence de déploiement et du nombre de contributeurs.

GitFlow : la méthode classique

Le modèle GitFlow, présenté par Vincent Driessen en 2010, utilise des branches longues et une hiérarchie stricte. Son auteur recommande désormais un workflow plus simple pour la livraison continue, tout en conservant GitFlow pour les logiciels explicitement versionnés ou dont plusieurs versions restent maintenues.

main ─────────────────────────────────────► (production)
  │                                          ▲
  ├── develop ───────────────────────────────┤ (intégration)
  │     │          │          │              │
  │     ├── feature/login ──►┘              │
  │     ├── feature/api ────►┘              │
  │                                          │
  │     └── release/1.0 ────────────────────►┘
  │
  └── hotfix/fix-bug ──────────────────────►┘

Les branches :

• main : code production, toujours stable
• develop : intégration des fonctionnalités
• feature/* : développement de nouvelles fonctionnalités
• release/* : préparation d’une version
• hotfix/* : corrections urgentes en production

Quand l’utiliser : projets avec des cycles de publication planifiés, applications mobiles avec versioning App Store/Play Store, environnements réglementés nécessitant un contrôle strict des déploiements.

GitHub Flow : la simplicité

La documentation officielle de GitHub Flow, consultée le 5 septembre 2026 décrit un workflow léger : une branche par changement, des commits explicites, une pull request, puis une fusion dans la branche par défaut.

main ─────●─────●─────●─────●──────► (toujours déployable)
            ▲         ▲
            │         │
       feature/A  feature/B
       (PR + review) (PR + review)

Le principe est simple :

1. Créer une branche depuis main.
2. Travailler sur la fonctionnalité.
3. Ouvrir une pull request pour obtenir un retour ou vérifier le changement.
4. Fusionner dans main lorsque le changement est prêt.
5. Supprimer la branche devenue inutile.

Trunk-based development : le mode expert

Le trunk-based development pousse la logique plus loin : le travail rejoint fréquemment la branche principale, directement ou depuis des branches courtes.

# Branche éphémère
git checkout -b quick-fix
# Modifications...
git commit -am "fix: correctif rapide"
git push origin quick-fix
# PR, revue et fusion rapide

# Ou directement sur main (pour les petits changements)
git checkout main
# Modifications...
git commit -am "docs: mise à jour README"
git push origin main

Dans cet exemple, les fonctionnalités incomplètes sont masquées derrière des feature flags :

if (featureFlag.isEnabled('new-payment-flow')) {
  // Nouvelle logique de paiement
} else {
  // Ancienne logique
}

Mon choix en tant que freelance

Pour la plupart des missions freelance, ma recommandation est un GitHub Flow adapté :

• Projet solo : gardez main exploitable et créez une branche courte par tâche significative.
• Projet en équipe : ajoutez une pull request, les contrôles automatisés et l’environnement de validation demandés par le client.
• Publications planifiées ou versions maintenues en parallèle : envisagez GitFlow, sans ajouter de branche que le processus de publication ne justifie pas.

Pourquoi adopter Conventional Commits ?

La spécification Conventional Commits 1.0.0, consultée le 5 septembre 2026 définit une convention légère qui ajoute une signification lisible par les humains et les outils aux messages de commit :

<type>[scope optional]: <description>

[body optionnel]

[footer optionnel]

Types courants :

• feat: nouvelle fonctionnalité définie par la spécification
• fix: correction de bug définie par la spécification
• docs: documentation, type complémentaire autorisé
• style: formatage sans impact fonctionnel
• refactor: refactorisation
• test: ajout ou modification de tests
• chore: tâche de maintenance
• perf: optimisation de performance

Exemples :

git commit -m "feat(auth): add OAuth2 login with Google"
git commit -m "fix(cart): prevent duplicate items on rapid clicks"
git commit -m "docs: update API documentation for v2 endpoints"
git commit -m "perf(images): implement WebP conversion pipeline"

Cette convention facilite la lecture de l’historique et permet aux outils de générer des journaux de modifications ou de déterminer une évolution de version sémantique. Les types autres que feat et fix restent des conventions d’équipe : documentez-les.

Quelles pratiques Git appliquer au quotidien ?

Le .gitignore dès le départ

Chaque projet devrait commencer par un .gitignore adapté :

# Dépendances
node_modules/
vendor/

# Environnement
.env
.env.local
.env.*.local

# Build
dist/
build/

# IDE
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

# Logs
*.log
npm-debug.log*

Gérer les conflits de merge

Les conflits sont inévitables. Voici une méthode systématique :

# Mettre à jour main
git checkout main && git pull

# Rebaser votre branche feature sur main
git checkout feature/mon-feature
git rebase main

# En cas de conflit, résoudre puis continuer
git add <fichiers>
git rebase --continue

# Ou abandonner le rebase si nécessaire
git rebase --abort

Le rebase réapplique vos commits sur une nouvelle base et peut garder un historique linéaire. Utilisez-le sur votre branche de travail, mais évitez de réécrire une branche déjà partagée sans accord avec l’équipe :

# Historique avec merge (moins lisible)
*   Merge branch 'feature/login' into main
|\
| * feat: add login form
|/
* feat: add auth module

# Historique avec rebase (plus propre)
* feat: add login form
* feat: add auth module

Les aliases Git pour gagner du temps

# ~/.gitconfig
[alias]
  st = status -sb
  co = checkout
  br = branch
  cm = commit -m
  lg = log --oneline --graph --all --decorate
  unstage = reset HEAD --
  last = log -1 HEAD --stat
  undo = reset --soft HEAD~1

Comment collaborer avec plusieurs clients ?

Cas 1 : vous rejoignez un projet existant

# Cloner le repo
git clone <url>
cd <project>

# Comprendre la structure de branches
git branch -a

# Créer votre branche de travail
git checkout -b freelance/marc-feature main

# Suivre les conventions existantes
git log --oneline -20

Cas 2 : vous gérez un projet pour un client

# Structure recommandée
git init
git checkout -b main

# Protéger main (sur GitHub/GitLab)
# - Require pull request reviews
# - Require status checks
# - No force push

# Branche par tâche
git checkout -b feature/redesign-homepage

Cas 3 : vous collaborez avec des développeurs internes

# Synchroniser régulièrement
git fetch origin
git rebase origin/main

# PR claire avec description
gh pr create --title "feat: redesign homepage" \
  --body "## Changes
- New hero section
- Updated navigation
- Mobile responsive layout

## Testing
- [x] Desktop Chrome/FF/Safari
- [x] Mobile iOS/Android"

Quels outils Git complètent ce workflow ?

Git hooks avec Husky

La documentation de démarrage de Husky, consultée le 5 septembre 2026 indique que husky init crée un hook pre-commit dans .husky/ et met à jour le script prepare. Vous pouvez ensuite y lancer les contrôles adaptés au projet :

# Installation
npm install -D husky
npx husky init

# .husky/pre-commit
npx lint-staged

// package.json
{
  "lint-staged": {
    "*.{js,ts}": ["eslint --fix", "prettier --write"],
    "*.{css,scss}": ["stylelint --fix", "prettier --write"],
    "*.md": ["prettier --write"]
  }
}

Git Bisect pour trouver le commit fautif

# Git bisect trouve le commit qui a introduit un bug
git bisect start
git bisect bad           # Le commit actuel est bugué
git bisect good v1.0     # Cette version fonctionnait

# Git checkout automatiquement des commits intermédiaires
# Testez et indiquez good/bad
git bisect good          # ou git bisect bad

# Répétez jusqu'à trouver le commit fautif
git bisect reset         # Revenir au HEAD

Conclusion

Commencez simple : un GitHub Flow adapté, des Conventional Commits cohérents et une branche par tâche. Ajoutez des règles seulement lorsqu’un client, une équipe ou un cycle de publication les justifie.

Pour plusieurs clients, séparez strictement les dépôts et vérifiez avant chaque push le remote, la branche et l’identité Git active. Documentez les choix propres à chaque équipe dans son CONTRIBUTING.md.

Sources

• A successful Git branching model — Vincent Driessen
• GitHub Flow — documentation GitHub
• Conventional Commits 1.0.0
• git rebase — documentation Git
• git bisect — documentation Git
• Get started — documentation Husky