Cours Git & GitHub Complet 🔀

Les 12 chapitres essentiels — commits, branches, merge, pull requests et workflows

12
Chapitres
100+
Commandes
Git 2.x
Version
A1→C2
Niveaux

CHAPITRE 01

Introduction et installation

🔀 Configurer Git
# Installer Git
# macOS : brew install git
# Ubuntu : sudo apt install git
# Windows : https://git-scm.com/download/win

# Configuration initiale (une seule fois)
git config –global user.name « Votre Nom »
git config –global user.email « votre@email.com »
git config –global init.defaultBranch main
git config –global core.editor « code –wait » # VS Code comme éditeur

# Vérifier
git config –list
git –version

Git est un système de contrôle de version distribué créé par Linus Torvalds en 2005 (créateur de Linux). Il permet de suivre chaque modification de votre code, collaborer en équipe, et revenir en arrière. GitHub est la plateforme web qui héberge vos dépôts Git. Alternatives : GitLab, Bitbucket.

📂 Les 3 zones de Git
ZoneDescriptionCommande
Working DirectoryVos fichiers locaux (modifications en cours)Vous éditez vos fichiers
Staging Area (index)Fichiers prêts à être commitésgit add
Repository (.git)Historique complet des commitsgit commit

CHAPITRE 02

Premiers commits

📝 Le workflow de base
# Initialiser un dépôt
git init

# Voir l'état des fichiers
git status

# Ajouter au staging
git add fichier.txt # Un fichier
git add src/ # Un dossier
git add . # Tout
git add -p # Interactif (choisir hunk par hunk)

# Commiter
git commit -m « feat: ajouter la page d'accueil »

# Raccourci : add + commit en une commande
git commit -am « fix: corriger le bug de connexion »
# ⚠️ -a n'ajoute que les fichiers DÉJÀ suivis (pas les nouveaux)

# .gitignore — fichiers à ne jamais versionner
# Créez un fichier .gitignore à la racine :
node_modules/
.env
*.log
dist/
__pycache__/
.DS_Store

Un commit = une photo instantanée de votre projet. Chaque commit a un identifiant unique (hash SHA), un message, un auteur et un timestamp. Commitez souvent, avec des messages clairs. Un bon commit représente un changement logique et autonome.

CHAPITRE 03

Historique et navigation

📜 Explorer l'historique
# Log
git log # Historique complet
git log –oneline # Compact (1 ligne par commit)
git log –oneline –graph # Avec graphe des branches
git log –oneline -10 # 10 derniers commits
git log –author=« Alice » # Par auteur
git log — src/app.js # Historique d'un fichier

# Différences
git diff # Working vs staging
git diff –staged # Staging vs dernier commit
git diff HEAD~2 # Vs 2 commits en arrière
git diff main..feature # Entre 2 branches

# Inspecter un commit
git show abc1234 # Détails d'un commit

# Qui a écrit chaque ligne ?
git blame fichier.txt # Auteur par ligne

# Chercher dans l'historique
git log –grep=« fix bug » # Par message
git log -S « function_name » # Par contenu modifié

CHAPITRE 04

Branches

🌿 Travailler avec les branches
# Créer et naviguer
git branch feature/login # Créer une branche
git checkout feature/login # Basculer dessus
git checkout -b feature/login # Créer + basculer (raccourci)
git switch feature/login # Basculer (syntaxe moderne)
git switch -c feature/login # Créer + basculer (moderne)

# Lister
git branch # Branches locales
git branch -a # + branches distantes
git branch -v # Avec dernier commit

# Supprimer
git branch -d feature/login # Supprimer (si mergée)
git branch -D feature/login # Forcer la suppression

# Renommer
git branch -m ancien-nom nouveau-nom

Une branche = un pointeur léger vers un commit. Créer une branche ne copie pas le code — c'est instantané. La branche main est la branche principale. Travaillez toujours sur une branche dédiée, jamais directement sur main.

CHAPITRE 05

Merge et rebase

🔀 Fusionner des branches
# MERGE — fusionne en créant un commit de merge
git checkout main
git merge feature/login
# → Crée un « merge commit » qui combine les deux branches
# → Historique : préserve l'historique complet

# Fast-forward — si main n'a pas bougé
# → Pas de merge commit, le pointeur avance simplement
git merge –no-ff feature/login # Forcer un merge commit

# REBASE — rejouer les commits sur une autre base
git checkout feature/login
git rebase main
# → « Déplace » les commits de feature sur la pointe de main
# → Historique : linéaire et propre (pas de merge commit)

# Rebase interactif — réécrire l'historique
git rebase -i HEAD~3
# → Choisir : pick, squash (fusionner), reword, drop

AspectMergeRebase
HistoriquePréservé (merge commits)Linéaire (pas de merge commits)
SécuritéNe réécrit pas l'historiqueRéécrit l'historique ⚠️
Quand l'utiliserBranches partagées, PRBranches locales, avant PR
Règle d'orToujours safeJamais sur une branche partagée

CHAPITRE 06

Conflits

⚡ Résoudre les conflits
# Un conflit ressemble à ça dans le fichier :
<<<<<<< HEAD
console.log('Version de main');
=======
console.log('Version de feature');
>>>>>>> feature/login

# Étapes pour résoudre :
# 1. Ouvrir le fichier et choisir la bonne version
# 2. Supprimer les marqueurs <<<<<<<, =======, >>>>>>>
# 3. Ajouter le fichier résolu
git add fichier.js
# 4. Continuer
git merge –continue # ou git rebase –continue

# Annuler un merge en cours
git merge –abort
git rebase –abort

VS Code résout les conflits visuellement avec des boutons « Accept Current », « Accept Incoming », « Accept Both ». Outils dédiés : git mergetool, GitKraken, ou la vue merge de VS Code. Les conflits sont normaux — ils arrivent quand deux personnes modifient les mêmes lignes.

CHAPITRE 07

Stash et tags

📦 Stash — mettre de côté
# Sauvegarder les modifications en cours (sans commiter)
git stash # Mettre de côté
git stash -m « WIP: formulaire » # Avec un message

# Récupérer
git stash pop # Appliquer et supprimer du stash
git stash apply # Appliquer sans supprimer

# Lister et gérer
git stash list # Tous les stash
git stash drop stash@ # Supprimer un stash
git stash clear # Tout supprimer

🏷️ Tags — marquer une version
# Tag léger
git tag v1.0.0

# Tag annoté (recommandé — avec message et auteur)
git tag -a v1.0.0 -m « Version 1.0 — lancement »

# Lister
git tag # Tous les tags
git tag -l « v1.* » # Filtrer

# Pousser les tags
git push origin v1.0.0 # Un tag
git push origin –tags # Tous les tags

# Supprimer
git tag -d v1.0.0 # Localement
git push origin –delete v1.0.0 # Sur le remote

CHAPITRE 08

GitHub : remote

☁️ Travailler avec GitHub
# Cloner un dépôt existant
git clone https://github.com/user/repo.git
git clone git@github.com:user/repo.git # Via SSH (recommandé)

# Lier un dépôt local à GitHub
git remote add origin https://github.com/user/repo.git
git remote -v # Vérifier

# Pousser
git push origin main # Pousser main
git push -u origin main # -u = set upstream (1ère fois)
git push # Après -u, raccourci
git push origin feature/login # Pousser une branche

# Récupérer
git fetch origin # Télécharger sans fusionner
git pull origin main # fetch + merge
git pull –rebase origin main # fetch + rebase (plus propre)

# Supprimer une branche distante
git push origin –delete feature/login

🔑 SSH (recommandé)
# Générer une clé SSH
ssh-keygen -t ed25519 -C « votre@email.com »

# Copier la clé publique
cat ~/.ssh/id_ed25519.pub

# Ajouter sur GitHub → Settings → SSH Keys → New SSH Key

# Tester
ssh -T git@github.com
# → « Hi username! You've successfully authenticated »

SSH évite de taper votre mot de passe à chaque push/pull. Configurez-le une fois, c'est terminé. GitHub n'accepte plus les mots de passe HTTPS depuis 2021 — utilisez SSH ou un Personal Access Token (PAT).

CHAPITRE 09

Pull requests

🔃 Workflow Pull Request
# 1. Créer une branche
git switch -c feature/login

# 2. Travailler et commiter
git add .
git commit -m « feat: ajouter formulaire de connexion »
git commit -m « feat: ajouter validation email »

# 3. Pousser la branche
git push -u origin feature/login

# 4. Créer la Pull Request sur GitHub
# → Aller sur github.com/user/repo
# → « Compare & pull request »
# → Écrire une description claire
# → Demander une review

# 5. Après l'approbation → Merge sur GitHub
# → « Squash and merge » (recommandé : 1 commit propre)

# 6. Mettre à jour main localement
git switch main
git pull origin main
git branch -d feature/login # Supprimer la branche locale

3 stratégies de merge sur GitHub : Merge commit = garde tous les commits + un merge commit. Squash and merge = combine tous les commits en 1 seul (historique propre, recommandé). Rebase and merge = rejoue les commits linéairement (pas de merge commit).

CHAPITRE 10

GitHub Actions (CI/CD)

⚙️ Automatiser avec les Actions
# .github/workflows/ci.yml
name: CI

on:
push:
branches: [main] pull_request:
branches: [main]

jobs:
test:
runs-on: ubuntu-latest

steps:
uses: actions/checkout@v4

name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'

name: Install dependencies
run: npm ci

name: Run tests
run: npm test

name: Build
run: npm run build

GitHub Actions = CI/CD gratuit (2000 minutes/mois sur les dépôts publics, illimité). Déclenchez des tests, du linting, des déploiements automatiques à chaque push ou PR. Placez vos fichiers YAML dans .github/workflows/.

CHAPITRE 11

Annuler et corriger

⏪ Revenir en arrière
# Annuler les modifications non commitées
git checkout — fichier.txt # Restaurer un fichier
git restore fichier.txt # Syntaxe moderne
git restore –staged fichier.txt # Retirer du staging

# Modifier le dernier commit
git commit –amend -m « Nouveau message »
git commit –amend –no-edit # Ajouter des fichiers sans changer le message

# Revert — annuler un commit (crée un nouveau commit inverse)
git revert abc1234 # Safe : ne réécrit pas l'historique

# Reset — remonter dans l'historique ⚠️
git reset –soft HEAD~1 # Annule le commit, garde staging
git reset –mixed HEAD~1 # Annule commit + staging, garde fichiers
git reset –hard HEAD~1 # Annule TOUT (⚠️ destructif)

# Retrouver un commit « perdu »
git reflog # Historique de toutes les actions
git checkout abc1234 # Revenir à ce commit

CommandeHistoriqueUsage
git revertPréservé (nouveau commit)Branche partagée (safe)
git reset –softRéécrit ⚠️Refaire le dernier commit
git reset –hardRéécrit ⚠️⚠️Abandonner des changements locaux
git commit –amendRéécrit ⚠️Corriger le dernier commit

CHAPITRE 12

Bonnes pratiques

💬 Conventional Commits
# Format : type(scope): description

feat: ajouter l'authentification Google
fix: corriger le crash au login sur iOS
docs: mettre à jour le README
style: formater le code avec Prettier
refactor: simplifier la logique de panier
test: ajouter tests unitaires pour UserService
chore: mettre à jour les dépendances
perf: optimiser la requête SQL des produits
ci: ajouter GitHub Actions pour les tests

🔀 Workflow Git Flow simplifié
# Branches principales
main # Production (toujours déployable)
develop # Développement (optionnel pour petites équipes)

# Branches de travail
feature/login # Nouvelle fonctionnalité
fix/crash-ios # Correction de bug
hotfix/security # Correction urgente en prod

# Workflow simple (petites équipes) :
# 1. Toujours créer une branche depuis main
# 2. Commiter dessus
# 3. Ouvrir une PR
# 4. Review + merge (squash) dans main
# 5. Supprimer la branche

✅ Bonnes pratiques

✅ À FAIRE
• Commits atomiques (1 changement = 1 commit)
• Conventional Commits (feat/fix/docs)
• Pull Requests pour tout merge dans main
.gitignore dès le début
• SSH au lieu de HTTPS
git pull –rebase (historique propre)
• Squash and merge sur les PR
• Tags pour les versions (v1.0.0)
• GitHub Actions pour les tests

❌ À ÉVITER
• Commiter directement sur main
• Messages vagues (« fix », « update », « wip »)
git push –force sur une branche partagée
• Commiter .env ou des secrets
• Rebase sur une branche partagée
git reset –hard sans réfléchir
• Ignorer les conflits (résolvez-les vite)
• Un seul gros commit (« tout le projet »)
• Commiter node_modules/ ou dist/

🧠 Quiz
Quelle est la différence entre git fetch et git pull ?
git fetch télécharge les changements du remote sans modifier vos fichiers locaux. Vous pouvez inspecter avant de fusionner. git pull = git fetch + git merge (ou rebase avec –rebase). Pull est pratique mais fetch est plus safe car il ne touche pas à votre working directory.
Quand utiliser revert vs reset ?
git revert = crée un nouveau commit qui annule un ancien. L'historique est préservé — safe pour les branches partagées. git reset = réécrit l'historique en déplaçant le pointeur de branche. Uniquement sur les branches locales non poussées. En cas de doute, utilisez revert.

Cours Git & GitHub Complet — Commits, branches, pull requests et CI/CD

Référence : git-scm.com | GitHub Docs | Conventional Commits