Git et GitHub : le guide complet pour débutants

Avant Git, je nommais mes fichiers projet-final.js, projet-final-v2.js, projet-final-VRAIMENT-FINAL.js. C'est une blague qui revient souvent dans le monde du dev. Ce n'est pas une blague — c'est ce que tout le monde fait avant de découvrir Git.

Git est un système de versioning : il enregistre chaque modification de votre code avec un message, une date, et la possibilité de revenir en arrière à n'importe quel point. GitHub est la plateforme qui héberge votre code Git en ligne et y ajoute les outils de collaboration.

Si vous débutez en développement, Git est l'un des premiers outils à maîtriser. Pas parce que c'est obligatoire pour coder, mais parce que sans lui, vous travaillez sans filet.

Git vs GitHub : la distinction essentielle

Beaucoup confondent les deux. Ce n'est pas la même chose.

Git est un outil qui tourne localement sur votre machine. Il n'a pas besoin d'internet. Il gère l'historique de votre code dans un dossier .git caché à la racine de votre projet.

GitHub est un service en ligne (comme GitLab ou Bitbucket) qui héberge vos repositories Git. Il permet de sauvegarder votre code en dehors de votre machine, de le partager, et de collaborer.

Git peut exister sans GitHub. GitHub ne peut pas exister sans Git.

Installation et configuration

# macOS
brew install git
 
# Linux (Debian/Ubuntu)
sudo apt install git
 
# Windows — télécharger depuis git-scm.com

git config --global user.name "Votre Nom"
git config --global user.email "vous@example.com"
git config --global init.defaultBranch main

Ces informations apparaissent dans chaque commit que vous créez. Utilisez la même adresse email que votre compte GitHub.

Votre premier repository

Un repository (repo) est simplement un dossier que Git surveille.

# Initialiser Git dans un dossier existant
mkdir mon-projet && cd mon-projet
git init
 
# Créer un fichier
echo "# Mon projet" > README.md
 
# Vérifier l'état du repo
git status

git status est la commande que vous taperez le plus souvent. Elle montre quels fichiers ont changé et ce qui est prêt à être enregistré.

Commits : enregistrer l'historique

Un commit est un instantané de votre code à un moment donné. Il a un message, un auteur, une date, et un identifiant unique (un hash comme a3f8b2c).

L'enregistrement se fait en deux étapes.

Étape 1 — Staging : vous choisissez quels fichiers inclure dans le prochain commit.

git add README.md          # Ajouter un fichier spécifique
git add .                  # Ajouter tous les fichiers modifiés
git add src/               # Ajouter un dossier entier

Étape 2 — Commit : vous enregistrez le snapshot avec un message.

git commit -m "feat: ajouter la page d'accueil"

Vérifier l'historique :

git log                    # Historique complet
git log --oneline          # Version condensée, une ligne par commit

Écrire de bons messages de commit

Un bon message explique le pourquoi, pas le quoi. Le diff montre déjà ce qui a changé.

# Mauvais
git commit -m "fix"
git commit -m "modif"
git commit -m "ça marche maintenant"
 
# Bons
git commit -m "fix: corriger le calcul de TVA sur les produits réduits"
git commit -m "feat: ajouter l'authentification par email"
git commit -m "refactor: simplifier la logique de pagination"

La convention type: description (feat, fix, refactor, docs, chore) est adoptée par la majorité des projets open source. Elle rend l'historique lisible d'un coup d'œil.

Branches : travailler en parallèle

Une branche est une ligne de développement indépendante. La branche principale s'appelle main (ou master sur les anciens projets).

Imaginez que main est votre code en production. Vous ne voulez pas y toucher directement quand vous développez une nouvelle fonctionnalité — une erreur rendrait le code principal cassé. Vous créez une branche, vous travaillez dessus, et quand c'est prêt vous fusionnez.

# Créer une branche et basculer dessus
git checkout -b feature/login
 
# Voir toutes les branches (* = branche active)
git branch
 
# Basculer sur une branche existante
git checkout main
 
# Supprimer une branche (après merge)
git branch -d feature/login

Sur la branche feature/login, vous pouvez casser tout ce que vous voulez. main reste intact.

# Workflow typique
git checkout -b feature/mon-api    # Nouvelle branche
# ... travail, modifications ...
git add .
git commit -m "feat: ajouter endpoint /users"
git checkout main                  # Retour sur main

Merge : fusionner les branches

Quand votre fonctionnalité est prête, vous fusionnez la branche dans main.

git checkout main
git merge feature/login

Git combine automatiquement les changements. Si deux branches ont modifié la même ligne du même fichier, il ne peut pas décider seul — c'est un conflit.

# Git marque le fichier conflictuel
<<<<<<< HEAD
const PORT = 3000
=======
const PORT = 8080
>>>>>>> feature/login

Vous éditez manuellement le fichier pour garder la bonne version, puis :

git add fichier-en-conflit.js
git commit -m "merge: résoudre conflit sur PORT"

Les conflits font peur au début. Après dix fois, c'est mécanique.

GitHub : mettre son code en ligne

Créez un compte sur github.com, puis un nouveau repository via l'interface.

Connexion SSH (recommandé)

GitHub accepte HTTPS et SSH. SSH est plus confortable : pas besoin de taper son mot de passe à chaque push.

# Générer une clé SSH
ssh-keygen -t ed25519 -C "vous@example.com"
 
# Afficher la clé publique
cat ~/.ssh/id_ed25519.pub

Copiez la clé publique et collez-la dans GitHub → Settings → SSH and GPG keys → New SSH key. Le concept de clé SSH est le même que pour accéder à un serveur distant.

Push : envoyer le code sur GitHub

# Lier le repo local au repo GitHub (une seule fois)
git remote add origin git@github.com:votre-user/mon-projet.git
 
# Envoyer la branche main
git push -u origin main
 
# Ensuite, push simplifié
git push

Pull : récupérer les changements

# Récupérer et fusionner les changements distants
git pull
 
# Récupérer sans fusionner (inspecter d'abord)
git fetch
git diff main origin/main

Pull Request : la collaboration sur GitHub

Une Pull Request (PR) est une demande de fusion de branche. Sur un projet en équipe, vous ne mergez pas directement dans main — vous ouvrez une PR pour que quelqu'un relise votre code avant.

Le flux complet :

git checkout -b feature/ma-fonctionnalite
# ... développement ...
git add .
git commit -m "feat: implémenter la recherche"
git push origin feature/ma-fonctionnalite

Puis sur GitHub, un bouton "Compare & pull request" apparaît. Vous rédigez une description, désignez des reviewers. Ils commentent, vous corrigez, vous pushez de nouveaux commits. Quand tout le monde est d'accord, la PR est mergée.

Sur vos projets solo, les PRs servent de journal de bord : vous documentez ce que vous avez fait et pourquoi avant de merger. Utile dans six mois quand vous vous demandez pourquoi vous avez pris telle décision.

.gitignore : ce que Git ne doit pas voir

Certains fichiers n'ont rien à faire dans votre repository : les secrets, les dépendances, les fichiers générés.

# Dépendances
node_modules/
vendor/
 
# Variables d'environnement (NE JAMAIS commiter)
.env
.env.local
.env.production
 
# Fichiers générés
dist/
.next/
build/
 
# IDE
.vscode/
.idea/
*.DS_Store

Créez ce fichier à la racine du projet avant le premier commit. Une fois qu'un fichier est dans l'historique Git, le retirer est possible mais pénible.

Tips et astuces

Annuler le dernier commit (sans perdre le travail)

git reset --soft HEAD~1

Annule le commit mais garde les fichiers modifiés en staging. Utile quand vous avez commité trop tôt.

Modifier le message du dernier commit

git commit --amend -m "feat: nouveau message"

À utiliser uniquement si le commit n'a pas encore été pushé.

Mettre de côté du travail en cours

git stash          # Sauvegarder les modifications sans commiter
git stash pop      # Les restaurer
git stash list     # Voir tous les stash

Utile quand vous devez switcher de branche en urgence sans avoir fini votre travail.

Voir ce qui a changé

git diff                   # Changements non stagés
git diff --staged          # Changements stagés (prêts à commiter)
git diff main feature/x    # Différence entre deux branches

Retrouver qui a écrit une ligne

git blame fichier.js

Affiche chaque ligne avec l'auteur et le commit qui l'a introduite. Indispensable quand vous essayez de comprendre une décision de code.

Chercher dans l'historique

# Trouver quel commit a introduit un texte
git log --all -S "texte recherché"
 
# Historique d'un fichier spécifique
git log --follow src/auth.js

Revenir à un commit précédent (mode lecture)

git checkout a3f8b2c    # Hash du commit
git checkout main       # Retour au présent

Alias pour les commandes fréquentes

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.lg "log --oneline --graph --all"

git lg affiche un graphe visuel des branches dans le terminal. Indispensable sur les projets multi-branches.

Une fois les bases maîtrisées, l'étape suivante naturelle est d'automatiser : chaque push sur main peut déclencher des tests et un déploiement automatique. C'est ce que fait GitHub Actions — et la configuration se fait directement dans votre repository.

Git est un outil qu'on apprend en l'utilisant, pas en lisant de la documentation. Créez un repo aujourd'hui, committez, cassez quelque chose, apprenez à récupérer. L'historique est là — vous ne pouvez pas vraiment tout perdre.

Si vous cherchez où Git s'inscrit dans un parcours d'apprentissage plus large, la roadmap développeur web 2026 positionne chaque compétence — Git, frontend, backend, DevOps, IA — dans un ordre logique.