Chapitre 11 - Bonnes pratiques | Cours GitHub pour débutants

🎯 Objectifs de ce chapitre

À la fin de ce chapitre, tu seras capable de :

Rédiger des messages de commit clairs et utiles
Adopter un workflow Git efficace et sécurisé
Organiser ton dépôt GitHub de manière professionnelle
Éviter les erreurs courantes des débutants
Travailler en équipe de manière fluide
Sauvegarder ton travail régulièrement et sûrement

Pourquoi les bonnes pratiques ?

Les bonnes pratiques ne sont pas des règles arbitraires. Elles t'évitent des heures de frustration, des pertes de code, et des conflits avec tes collaborateurs !

📝 Messages de commit efficaces

Un bon commit raconte une histoire

Dans 6 mois, toi ou tes collègues devriez pouvoir comprendre l'historique du projet juste en lisant les messages de commit.

✅ Format conventionnel

<type>: <description courte>

[description détaillée optionnelle]

Exemples :

feat: ajoute la connexion utilisateur
fix: corrige le bug de calcul du prix
docs: met à jour le README

❌ À éviter absolument

update (trop vague)
fix bug (quel bug ?)
wip (work in progress)
commit du vendredi soir (humour qui ne vieillit pas bien)

Types de commit standards

feat

Nouvelle fonctionnalité

feat: ajoute le panier d'achat

fix

Correction de bug

fix: répare la validation email

docs

Documentation

docs: ajoute les instructions d'installation

style

Formatage, point-virgules manquants

style: formate le code avec Prettier

refactor

Refactorisation du code

refactor: simplifie la fonction de calcul

test

Ajout ou correction de tests

test: ajoute les tests pour l'API utilisateur

Règles d'or pour les messages de commit

🎯 Commence par un verbe à l'impératif : "ajoute", "corrige", "améliore"
📏 50 caractères maximum pour la première ligne
🔍 Sois spécifique : Explique QUOI et POURQUOI
🌍 Écris en français (ou anglais si projet international)
🚫 Ne mentionne pas comment - c'est visible dans le code

🔄 Workflow efficace au quotidien

Commence par un pull

git pull origin main

Toujours partir de la dernière version

↓

Crée une branche descriptive

git checkout -b feat/ajout-panier-achat

Une branche = une fonctionnalité

↓

Travaille et commit régulièrement

git add .
git commit -m "feat: ajoute le composant panier"

Petits commits fréquents

↓

Pousse ta branche

git push origin feat/ajout-panier-achat

Sauvegarde ton travail

↓

Crée une Pull Request

Sur GitHub, avec une description claire

Fréquence des commits

✅ Commits atomiques

Un commit = une idée logique

🚀 Facile à comprendre
🔧 Simple à annuler si problème
🔍 Facile à déboguer
📚 Historique clair

❌ Mega-commits

Un commit = une journée de travail

🤯 Difficile à comprendre
💥 Risque de tout casser
🔎 Impossible à déboguer
📖 Historique inutile

Quand faire un commit ?

💡 Quand tu as fini une petite tâche logique
🧪 Quand tes tests passent
☕ Avant une pause
🏠 Avant de quitter le travail
🔄 Avant de changer de contexte

📁 Organisation du dépôt

Une bonne organisation rend ton projet plus professionnel et facile à maintenir.

✅ Structure claire

mon-projet/
├── src/           # Code source
├── docs/          # Documentation
├── tests/         # Tests
├── public/        # Fichiers statiques
├── .github/       # Configuration GitHub
├── README.md
└── package.json

❌ Chaos organisé

mon-projet/
├── code.js
├── code2.js
├── test.js
├── doc.txt
├── image1.png
├── image2.jpg
└── README.md

Fichiers de configuration essentiels

.gitignore

Liste des fichiers à ignorer

node_modules/
.env
*.log
.DS_Store

README.md

Documentation principale

Doit expliquer le projet rapidement

LICENSE

Licence d'utilisation

Essentiel pour l'open source

.github/

Configurations GitHub

ISSUE_TEMPLATE/
PULL_REQUEST_TEMPLATE.md
workflows/

🚨 Erreurs fréquentes à éviter

Travailler directement sur main

Problème : Tu risques de casser la version stable et de créer des conflits avec les autres.

Solution : Toujours créer une branche pour chaque nouvelle fonctionnalité.

Commits trop gros

Problème : Impossible de comprendre les changements ou de revenir en arrière sur une partie spécifique.

Solution : Fais des commits petits et fréquents, chaque commit doit avoir un objectif clair.

Oublier de pull avant de travailler

Problème : Tu travailles sur une version obsolète, ce qui crée des conflits au moment du push.

Solution : Toujours faire git pull avant de commencer à travailler.

Messages de commit vagues

Problème : Dans 6 mois, personne (même pas toi) ne saura pourquoi ces changements ont été faits.

Solution : Utilise la convention de messages et sois spécifique.

Pousser des données sensibles

Problème : Mots de passe, clés API, fichiers de configuration avec des données privées.

Solution : Utilise .gitignore et des variables d'environnement.

Négliger les Pull Requests

Problème : Fusionner directement sans review, ce qui peut introduire des bugs.

Solution : Toujours créer une PR et demander une review, même pour de petits changements.

🛡️ Sécurité et sauvegarde

GitHub n'est pas un service de backup

Même si GitHub est fiable, tu dois avoir des bonnes habitudes de sauvegarde locales.

✅ Bonnes habitudes de sécurité

🔑 Tokens d'accès au lieu des mots de passe
🔄 Push fréquents pour sauvegarder
🌿 Branches feature pour isoler le travail
🚫 .gitignore pour les fichiers sensibles
🔍 git status avant chaque commit

❌ Pratiques risquées

💥 git push --force sur les branches partagées
🔓 Fichiers .env dans le dépôt
📦 Node_modules commités
🖥️ Travail non commité pendant des jours
🤞 "Ça marche sur ma machine" comme stratégie

Checklist de sécurité

J'utilise des tokens personnels au lieu de mots de passe

Mon .gitignore exclut les fichiers sensibles

Je fais des commits réguliers (au moins 2-3 par jour)

Je pousse mon travail en fin de journée

J'utilise des branches pour chaque fonctionnalité

Je vérifie git status avant chaque commit

🎯 Checklist des bonnes pratiques

Messages de commit clairs
Utilise la convention : type: description (feat:, fix:, docs:, etc.)

Commits atomiques
Un commit = une idée logique, pas une journée de travail

Toujours travailler sur des branches
Jamais directement sur main, une branche par fonctionnalité

Pull avant de travailler
Toujours partir de la dernière version de main

Push fréquent
Sauvegarde ton travail régulièrement sur GitHub

Utiliser les Pull Requests
Même en solo, c'est une bonne pratique pour revoir son code

.gitignore configuré
Exclut les fichiers sensibles et les dépendances

README à jour
Documente ton projet pour toi et les autres

Ces pratiques te sembleront naturelles rapidement

Au début, ça peut sembler contraignant, mais après quelques semaines, ces bonnes habitudes deviendront ta seconde nature et te feront gagner un temps précieux !

✅ Résumé du chapitre

Ce que tu as appris

✅ Messages de commit efficaces avec convention standard
✅ Workflow Git professionnel étape par étape
✅ Organisation du dépôt pour la maintenabilité
✅ Éviter les erreurs courantes des débutants
✅ Pratiques de sécurité essentielles
✅ Checklist complète pour vérifier tes bonnes pratiques

Félicitations ! Tu maîtrises maintenant les bonnes pratiques qui feront de toi un utilisateur Git/GitHub efficace et professionnel. Dans le prochain et dernier chapitre, nous allons mettre en pratique toutes ces connaissances dans un mini-projet guidé.

Pour t'entraîner

Prends un de tes projets existants et applique toutes ces bonnes pratiques : restructure les commits, organise les fichiers, améliore le README. C'est le meilleur moyen de les intégrer !