Retour au blog

Guide complet de Git pour les développeurs freelance

1 octobre 2024 • Dedimarco
git développement freelance productivité
Guide complet de Git pour les développeurs freelance

Git est l’outil incontournable de tout développeur. Mais pour un freelance qui jongle entre plusieurs projets, clients et équipes, maîtriser Git va bien au-delà des simples git add et git commit. Une stratégie de branches cohérente, des conventions de commits claires et un workflow adapté à la collaboration freelance font la différence entre un projet qui tourne et un projet qui dérape. Voici un guide complet basé sur 16 ans d’expérience.

Les stratégies de branches

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

GitFlow, popularisé par Vincent Driessen en 2010, utilise des branches longues durée et une hiérarchie stricte :

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 release 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é

GitHub Flow simplifie le modèle avec une seule branche principale et des branches feature courtes :

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 revue
  4. Merger dans main après approbation
  5. Déployer immédiatement

Trunk-based development : le mode expert

Le trunk-based development pousse la logique encore plus loin : des branches ultra-courtes (quelques heures à un jour maximum) ou des commits directs sur la branche principale :

# Branche éphémère
git checkout -b quick-fix
# Modifications...
git commit -am "fix: correctif rapide"
git push origin quick-fix
# PR, review, merge dans l'heure

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

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

Après des années d’expérience, ma recommandation pour les freelances est un GitHub Flow adapté :

  • Projets solo : GitHub Flow pur. Une branche main toujours déployable, des branches feature courtes.
  • Équipe de 2-5 personnes : GitHub Flow avec environnements de staging.
  • Équipe > 5 personnes ou releases planifiées : GitFlow allégé (sans la branche develop si les déploiements sont fréquents).

Conventions de commits : Conventional Commits

Des commits bien structurés sont essentiels pour la maintenance et la collaboration :

<type>[scope optional]: <description>

[body optionnel]

[footer optionnel]

Les types :

  • feat: nouvelle fonctionnalité
  • fix: correction de bug
  • docs: documentation
  • style: formatage (pas d’impact fonctionnel)
  • refactor: refactorisation
  • test: ajout/modification de tests
  • chore: tâches 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"

Ces conventions permettent de générer automatiquement des changelogs et de comprendre l’historique du projet en un coup d’œil.

Bonnes pratiques 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 est préféré au merge pour garder un historique linéaire et lisible :

# 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

Workflows de collaboration freelance

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 : Collaboration 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"

Outils complémentaires

Git hooks avec Husky

Automatisez les vérifications avant chaque commit :

# 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 les bugs

# 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

En tant que freelance, votre maîtrise de Git reflète votre professionnalisme. Un historique propre, des conventions respectées et un workflow adapté au contexte projet font la différence dans la collaboration avec vos clients et leurs équipes. Commencez simple — GitHub Flow avec Conventional Commits — et complexifiez uniquement quand le contexte l’exige.

La meilleure stratégie est celle que vous appliquez de manière cohérente. Documentez vos choix dans un CONTRIBUTING.md partagé avec chaque équipe, et n’hésitez pas à ajuster au fil des projets.