Git workflow pour développeurs web : guide pratique 2026

Introduction : Git, outil incontournable du développement web moderne

Git est le système de contrôle de version utilisé par plus de 93 % des développeurs dans le monde (Stack Overflow Survey 2025). En 2026, maîtriser Git n’est plus optionnel : c’est une compétence fondamentale pour tout développeur web, qu’il travaille seul ou en équipe. Ce guide pratique couvre les workflows les plus utilisés, les commandes du quotidien et les bonnes pratiques pour des projets WordPress et web en général.

Git Flow vs Trunk Based Development

Deux grandes philosophies s’affrontent :

Git Flow est adapté aux applications avec des cycles de release structurés (plugins WordPress versionnés, applications avec releases majeures/mineures). Trunk Based Development est idéal pour les équipes pratiquant le déploiement continu (CD) et les applications SaaS.

Branches Git : main, develop, feature, hotfix

# Structure Git Flow classique :
# main      : code de production, toujours stable
# develop   : intégration des features, prêt pour release
# feature/* : développement d'une fonctionnalité
# release/* : préparation d'une version (derniers ajustements)
# hotfix/*  : correction urgente en production

# Créer une feature branch depuis develop
git checkout develop
git pull origin develop
git checkout -b feature/ajout-formulaire-contact

# Développer, commiter...
git add src/FormContact.php
git commit -m "feat: ajouter formulaire de contact avec validation"

# Merger la feature dans develop
git checkout develop
git merge --no-ff feature/ajout-formulaire-contact
git push origin develop

# Supprimer la branch locale et distante
git branch -d feature/ajout-formulaire-contact
git push origin --delete feature/ajout-formulaire-contact

# Créer un hotfix depuis main
git checkout main
git checkout -b hotfix/fix-xss-formulaire
# Corriger le bug...
git commit -m "fix: corriger faille XSS dans le formulaire de contact"
git checkout main
git merge --no-ff hotfix/fix-xss-formulaire
git tag -a v1.2.1 -m "Version 1.2.1 - Correction XSS"
git checkout develop
git merge --no-ff hotfix/fix-xss-formulaire

Commandes Git du quotidien

# Voir l'état du dépôt
git status
git log --oneline --graph --all  # arbre des commits

# Sauvegarder le travail en cours sans commiter
git stash
git stash pop          # réappliquer le dernier stash
git stash list         # voir tous les stashs
git stash apply stash@{2}  # appliquer un stash spécifique

# Commandes de base
git add fichier.php
git add -p             # ajouter interactivement (hunk par hunk)
git commit -m "type(scope): description"
git push origin feature/ma-feature

# Réécrire le dernier commit (pas encore pushé)
git commit --amend --no-edit  # ajouter des fichiers oubliés
git commit --amend -m "Nouveau message"

# Cherry-pick : appliquer un commit spécifique sur une autre branch
git cherry-pick abc123

# Rebase : rebaser une feature sur develop
git checkout feature/ma-feature
git rebase develop
# Résoudre les conflits...
git rebase --continue
# ou annuler :
git rebase --abort

Résoudre les conflits de merge

# Quand un merge provoque un conflit :
git merge develop
# Auto-merging src/Plugin.php
# CONFLICT (content): Merge conflict in src/Plugin.php

# Ouvrir le fichier conflictuel : vous verrez
<<<<<<< HEAD (votre version)
public function register() {
    add_action('init', [$this, 'init_plugin']);
}
=======
public function register() {
    add_action('init', [$this, 'init_plugin'], 10);
    add_action('wp_loaded', [$this, 'load_assets']);
}
>>>>>>> develop (leur version)

# Choisir la bonne version (ou combiner les deux),
# supprimer les marqueurs <<<<<< ======= >>>>>>>
# Puis :
git add src/Plugin.php
git commit -m "merge: résoudre conflit dans Plugin.php"

GitHub/GitLab : Pull Requests et code review

Les PR/MR sont au cœur du workflow collaboratif. Bonnes pratiques :

• Une PR = une fonctionnalité ou correction (pas de PR géantes impossible à reviewer)
• Ajoutez toujours une description claire : contexte, solution choisie, comment tester
• Liez la PR à une issue (Fixes #123 dans le message de commit ou la description)
• Définissez des reviewers obligatoires avant le merge
• Utilisez les “Draft PR” pour les travaux en cours qui nécessitent des avis précoces

# Convention de messages de commit (Conventional Commits)
feat: nouvelle fonctionnalité
fix: correction de bug
docs: documentation uniquement
style: formatage (pas de changement de logique)
refactor: refactoring sans nouvelle fonctionnalité ni bug fix
test: ajout ou modification de tests
chore: maintenance (dépendances, config)

# Exemples
feat(formulaire): ajouter validation côté client
fix(panier): corriger le calcul de TVA pour les produits variables
docs: mettre à jour README avec instructions Docker

Git hooks : pre-commit et pre-push

# .git/hooks/pre-commit (le rendre exécutable avec chmod +x)
#!/bin/sh
# Vérifier le coding standard avant chaque commit
./vendor/bin/phpcs --standard=WordPress src/
if [ $? -ne 0 ]; then
    echo "ERREUR: violations du coding standard. Committez après correction."
    exit 1
fi

# .git/hooks/pre-push
#!/bin/sh
# Lancer les tests avant chaque push
./vendor/bin/phpunit
if [ $? -ne 0 ]; then
    echo "ERREUR: les tests échouent. Push annulé."
    exit 1
fi

# Avec Husky (Node.js) pour partager les hooks dans le dépôt :
# package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "pre-push": "npm test"
    }
  }
}

.gitignore pour projets WordPress

# .gitignore WordPress
# Core
/wp-admin/
/wp-includes/
/wp-*.php
/index.php
/xmlrpc.php
/wp-content/uploads/
/wp-content/upgrade/
/wp-content/backup-db/
/wp-content/cache/
/wp-content/advanced-cache.php
/wp-content/wp-cache-config.php

# Ne pas commiter les plugins et thèmes tiers (gérés par Composer)
/wp-content/plugins/
!/wp-content/plugins/mon-plugin-custom/  # exception pour plugins maison

# Config sensible
wp-config.php
.env
.env.*
!.env.example

# Dépendances
/vendor/
/node_modules/

# OS
.DS_Store
Thumbs.db
*.log

Pour un développement web full-stack organisé et collaboratif, consultez notre développeur full stack Paris.

Questions fréquentes sur Git et les workflows

Quelle est la différence entre git merge et git rebase ?

git merge crée un commit de fusion qui préserve l’historique exact des deux branches. git rebase rejoue les commits de votre branche sur la branche cible, créant un historique linéaire et plus lisible. Le rebase réécriture l’historique (ne jamais rebaser des branches publiques partagées !). Pour les features branches personnelles, le rebase donne un historique plus propre. Pour les branches partagées, préférez le merge avec –no-ff.

Comment annuler un commit déjà pushé ?

Utilisez git revert HEAD qui crée un nouveau commit annulant le précédent sans réécrire l’historique : c’est la méthode sûre pour les branches publiques. git reset --hard HEAD~1 suivi d’un force-push est une option mais dangereuse sur des branches partagées car elle réécrit l’historique distant et perturbe les autres développeurs.

Git Flow ou Trunk Based Development pour un projet WordPress en équipe ?

Pour une équipe de 2 à 5 développeurs sur un site WordPress avec des mises en production régulières (hebdomadaires/bimensuelles), Git Flow est souvent plus adapté car il formalise le processus de release. Pour une équipe pratiquant le déploiement continu avec CI/CD automatisé, Trunk Based Development réduit les conflits et accélère les livraisons. La clé est de choisir et documenter un workflow que toute l’équipe applique rigoureusement.

Comment gérer les credentials et secrets dans Git ?

Ne jamais commiter de secrets (clés API, mots de passe, tokens). Utilisez des fichiers .env (ajoutés au .gitignore) avec un .env.example documentant les variables nécessaires. Pour les équipes, utilisez un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, GitHub Secrets pour CI/CD). Si un secret est accidentellement commité, considérez-le compromis et révoquez-le immédiatement : les outils comme git-filter-repo peuvent le retirer de l’historique mais le secret doit quand même être révoqué.