Bonnes pratiques Git

Ce qui fait la différence

Savoir utiliser les commandes Git, c'est bien. Savoir bien utiliser Git, c'est autre chose. Ces bonnes pratiques viennent de milliers de projets et d'équipes. Autant les adopter dès le début.

.gitignore — ce que Git ne doit pas suivre

Certains fichiers ne doivent jamais aller dans ton dépôt : mots de passe, clés API, fichiers générés automatiquement, logs, dossiers node_modules.

Le fichier .gitignore liste les fichiers et dossiers à ignorer. Git ne les verra même pas.

.gitignore

# Variables d'environnement (JAMAIS dans Git !)
.env
.env.local

# Dépendances Node.js (lourd, se régénère avec npm install)
node_modules/

# Fichiers générés / build
dist/
build/
.cache/

# Fichiers système
.DS_Store
Thumbs.db

# Logs
*.log

⚠️

Ne commite jamais un fichier .env contenant des mots de passe ou clés API. Une fois dans l'historique Git, c'est difficile à effacer — et si le dépôt est public, c'est trop tard. Ajoute .env dans .gitignore avant le premier commit.

✅

Le site gitignore.io génère automatiquement un .gitignore adapté à ton projet (Node, Python, Java, etc.).

Messages de commit : l'art de bien expliquer

Un bon message de commit explique pourquoi tu as fait ce changement. Pas juste "ce que tu as fait". Le code montre déjà le "quoi".

Mauvais messages

# Mauvais — trop vague
git commit -m "fix"
git commit -m "modif"
git commit -m "wip"
git commit -m "aaaaa"

Bons messages

# Bons — précis, compréhensibles dans 6 mois
git commit -m "Correction : formulaire ne se soumet plus sur mobile"
git commit -m "Ajout de la page de contact avec validation"
git commit -m "Refactor : extraction du composant Header"
git commit -m "Fix #42 : bouton invisible en mode sombre"

Convention populaire : commence par un préfixe. feat: pour une fonctionnalité, fix: pour un bug, docs: pour la documentation, refactor: pour une restructuration. C'est le standard Conventional Commits.

Git Flow simplifié — comment organiser ses branches

Pas besoin de Git Flow complet pour bien travailler. Voici une stratégie simple qui convient à 90% des projets :

Stratégie de branches

# main — code stable, en production
# Ne jamais commiter directement sur main

# Pour chaque nouvelle fonctionnalité :
git checkout -b feat/menu-mobile
# ... travail, commits ...
git checkout main
git merge feat/menu-mobile

# Pour un bug urgent :
git checkout -b fix/crash-ios

💡

Nomme tes branches avec des préfixes clairs : feat/ pour les fonctionnalités, fix/ pour les corrections, docs/ pour la doc. Ça aide toute l'équipe à comprendre l'intention de chaque branche d'un coup d'oeil.

Récapitulatif : les règles d'or

Commite souvent, en petites unités. Un commit = un changement logique.
Jamais de .env dans Git. Jamais. Sans exception.
Messages de commit clairs. Futur toi te remerciera.
Une branche par fonctionnalité. Ne pas tout mélanger sur main.
git pull avant de commencer pour ne pas travailler sur du vieux code.

// À retenir

.gitignore liste les fichiers que Git doit ignorer. À créer au début du projet.
Ne jamais commiter .env ou des secrets. Une fois dans l'historique, c'est dangereux.
Un bon message de commit explique le pourquoi, pas juste le quoi.
Convention utile : feat:, fix:, docs:, refactor: en préfixe.
Une branche par fonctionnalité. main = code stable uniquement.