Git workflow pour freelances : organiser son code proprement

Pourquoi un Git workflow solide est indispensable au freelance

Quand on débute en freelance, Git ressemble souvent à un outil "bonus" — utile, mais pas vital. On commit tout sur main, on push quand on y pense, et on se débrouille. Jusqu'au jour où un client demande à revenir trois semaines en arrière, ou où une mise en production casse tout le site.

C'est là qu'on réalise que Git n'est pas un luxe, c'est une infrastructure de survie. Un bon workflow, même simple, vous évite des sueurs froides, protège votre réputation et vous permet de livrer avec confiance.

Dans ce guide, je vous partage ma méthode après 5 ans de projets clients en solo et en petite équipe.

Les bases : branches, commits et nomenclature

Une branche par fonctionnalité ou correctif

La règle d'or : ne jamais travailler directement sur main. Tout nouveau développement doit partir d'une branche dédiée.

# Créer et basculer sur une nouvelle branche
git checkout -b feature/refonte-header

# Ou avec la syntaxe moderne
git switch -c fix/bug-formulaire-contact

Voici la nomenclature que j'utilise sur tous mes projets :

Les commits conventionnels : votre journal de bord

Les Conventional Commits sont une spécification simple qui rend vos logs lisibles par un humain ET par des outils automatisés.

type(scope): description courte

Corps optionnel avec plus de détails.

Footer optionnel (ex: BREAKING CHANGE, closes #123)

Exemples concrets :

feat(blog): ajouter la pagination des articles
fix(contact): corriger l'envoi du formulaire sur iOS Safari
style(header): aligner le logo verticalement
docs: mettre à jour le README avec les variables d'env
chore(deps): mettre à jour Twig vers 3.8.0
refactor(auth): simplifier la gestion des sessions

Pourquoi c'est important ? Quand un client lit vos commits, il comprend ce qui a été fait. Quand vous revenez sur un projet 6 mois plus tard, vous aussi.

Le workflow complet d'un projet client

Phase 1 : initialisation du dépôt

# Initialiser et configurer
git init
git config user.name "Benjamin Schweitzer"
git config user.email "contact@benjamin-schweitzer.fr"

# Ajouter un .gitignore dès le départ
curl -s https://www.toptal.com/developers/gitignore/api/php,composer,node,macos > .gitignore

# Premier commit propre
git add .
git commit -m "chore: initialisation du projet"

# Connecter au remote
git remote add origin git@github.com:votre-compte/projet-client.git
git push -u origin main

Phase 2 : développement au quotidien

# Toujours partir d'un main à jour
git switch main
git pull origin main

# Créer sa branche de travail
git switch -c feature/espace-client

# ... développement ...

# Commits réguliers (pas de gros commits fourre-tout !)
git add src/Controller/ClientController.php
git commit -m "feat(client): créer le controller d'espace client"

git add templates/client/
git commit -m "feat(client): ajouter les templates de l'espace client"

Phase 3 : revue et fusion

# Mettre à jour sa branche avec les derniers changements de main
git switch feature/espace-client
git rebase main

# Résoudre les conflits si nécessaire
# git add fichier-conflictueux.php
# git rebase --continue

# Push et Pull Request
git push origin feature/espace-client

Sur GitHub, ouvrez une Pull Request même si vous travaillez seul. C'est une bonne habitude et ça permet de faire une relecture avant de fusionner.

Stratégie de déploiement : les trois environnements

Tout projet professionnel devrait avoir trois environnements distincts :

1. Local (votre machine)

2. Staging (pré-production)

3. Production (le vrai site)

Ma configuration de branches pour ça

main        → production (déploiement automatique via webhook)
develop     → staging (déploiement sur push)
feature/*   → local uniquement

Voici mon deploy.sh simplifié :

#!/bin/bash
set -e

echo "🚀 Déploiement en cours..."

# Pull des dernières modifications
git pull origin main

# Installation des dépendances
composer install --no-dev --optimize-autoloader
npm ci --production

# Build des assets
npm run build

# Migrations éventuelles
php artisan migrate --force 2>/dev/null || true

# Cache
php artisan config:cache 2>/dev/null || true

echo "✅ Déploiement terminé !"

Les alias Git qui font gagner du temps

Ajoutez ces alias dans votre ~/.gitconfig :

[alias]
    st   = status -sb
    co   = checkout
    sw   = switch
    br   = branch --sort=-committerdate
    lg   = log --oneline --graph --decorate --all
    undo = reset --soft HEAD~1
    oops = commit --amend --no-edit
    sync = !git fetch origin && git rebase origin/main
    wip  = !git add -A && git commit -m "wip: sauvegarde temporaire"
    unwip = reset HEAD~1

git lg est particulièrement précieux — il vous donne une vue graphique de toutes les branches :

* 3f2a1b0 (HEAD -> feature/blog) feat(blog): ajouter la recherche
* 2e1d0c9 fix(blog): corriger l'encodage des titres
| * 4a3b2c1 (main) chore: mise à jour des dépendances
|/
* 1b0a9f8 feat: page À propos

Gérer les secrets et variables d'environnement

Règle absolue : ne jamais committer de secrets dans Git.

# .gitignore — à adapter selon votre stack
.env
.env.local
.env.production
config/secrets.php
storage/
*.log

Utilisez toujours un fichier .env.example documenté :

# Base de données
DB_HOST=localhost
DB_NAME=your_db
DB_USER=your_user
DB_PASS=your_password

# SMTP
SMTP_HOST=ssl://smtp.example.com
SMTP_PORT=465
SMTP_USER=contact@example.com
SMTP_PASS=your_smtp_password

# Clés API
OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...

Stratégie de tags et versioning

Pour les projets avec livraison formelle, utilisez le versioning sémantique (MAJOR.MINOR.PATCH) :

# Créer un tag annoté pour une livraison
git tag -a v1.2.0 -m "Version 1.2.0 — Espace client complet"
git push origin v1.2.0

# Voir tous les tags
git tag --sort=-version:refname | head -10

# Checkout sur une version précise
git checkout v1.1.0

Règle de versioning :

• MAJOR : changement incompatible (refonte totale, migration de base)
• MINOR : nouvelle fonctionnalité rétrocompatible
• PATCH : correction de bug

Git hooks : automatiser les contrôles qualité

Les hooks Git s'exécutent automatiquement à certains moments du workflow. Voici mon pre-commit :

#!/bin/bash
# .git/hooks/pre-commit (chmod +x)

echo "🔍 Vérifications pré-commit..."

# Vérifier la syntaxe PHP
for file in $(git diff --cached --name-only --diff-filter=ACM | grep '.php$'); do
    php -l "$file" > /dev/null 2>&1
    if [ $? -ne 0 ]; then
        echo "❌ Erreur de syntaxe PHP dans $file"
        exit 1
    fi
done

# Vérifier qu'on ne commite pas de var_dump ou dd()
if git diff --cached | grep -E '^\+.*(var_dump|dd\(|die\()' > /dev/null 2>&1; then
    echo "⚠️  Attention : var_dump() ou dd() détecté dans le diff"
    echo "   Utilisez --no-verify pour forcer le commit"
    exit 1
fi

echo "✅ Tout est bon !"

Récupérer des situations difficiles

J'ai commité sur main par erreur

# Déplacer le dernier commit vers une nouvelle branche
git switch -c feature/mon-travail
git switch main
git reset --hard HEAD~1  # Annule le commit sur main

Je veux annuler un commit déjà pushé

# Créer un commit d'annulation (safe, garde l'historique)
git revert abc1234
git push origin main

Je veux récupérer un fichier supprimé

# Trouver dans quel commit il a été supprimé
git log --diff-filter=D --summary -- chemin/du/fichier.php

# Le restaurer depuis ce commit
git checkout abc1234^ -- chemin/du/fichier.php

Checklist de déploiement

Avant chaque mise en production, je passe mentalement cette liste :

• [ ] Tous les tests passent
• [ ] Le changelog est à jour
• [ ] Un tag de version est créé
• [ ] Les migrations sont vérifiées
• [ ] Le .env de production est configuré
• [ ] Un backup de la base est fait
• [ ] Le déploiement est fait en heure creuse
• [ ] Je peux rollback en moins de 5 minutes