Credit : Logo officiel
Introduction a Git pour les developpeurs web
Introduction a Git pour les developpeurs web
Un freelance me contacte un samedi soir : il a ecrase 3 jours de travail en copiant un mauvais dossier sur son site WordPress. Il avait une "sauvegarde" qui datait d'il y a une semaine, sous forme de dossier monsite_v2_FINAL_FINAL_OK. Trois jours de specifs, refonte de la home, integration de la nouvelle charte graphique : evapores. Avec Git correctement configure, on aurait fait un git reset --hard HEAD@{2.days.ago} et on serait rentre chez nous.
Git, c'est le systeme de controle de version standard utilise par 90% des developpeurs en 2026. Que tu bosses seul ou en equipe, c'est ton filet de securite, ton historique, ta machine a remonter le temps. Si tu ne l'utilises pas encore, c'est le moment.
Installation et configuration initiale
Sur Debian/Ubuntu :
apt install git -y
git --version
# git version 2.39.2
Sur macOS via Homebrew :
brew install git
Configuration initiale (a faire une seule fois) :
git config --global user.name "Dylan D"
git config --global user.email "dylan@exemple.fr"
git config --global init.defaultBranch main
git config --global core.editor nano
git config --global pull.rebase false
git config --global core.autocrlf input
# Couleurs et alias utiles
git config --global color.ui auto
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.lg "log --oneline --graph --all --decorate"
Verifie ta config :
git config --list --global
Creer un depot
Nouveau projet
mkdir mon-projet
cd mon-projet
git init
# Initialized empty Git repository in /home/dylan/mon-projet/.git/
Cloner un depot existant
git clone https://github.com/utilisateur/projet.git
cd projet
git clone git@github.com:utilisateur/projet.git # via SSH (recommande)
Le cycle de base : add, commit, push
Git a trois zones a comprendre :
- Working directory : tes fichiers actuels
- Staging area (index) : ce que tu prepares pour le prochain commit
- Repository : l'historique des commits
# Voir l'etat actuel
git status
# On branch main
# Changes not staged for commit:
# modified: index.html
# Untracked files:
# src/style.css
# Ajouter au staging
git add index.html
git add src/
git add . # Tout ajouter (attention !)
git add -p # Mode interactif, par hunks
# Creer un commit
git commit -m "Ajouter la page d'accueil"
# Combine add + commit pour les fichiers deja suivis
git commit -am "Corriger la navigation"
# Voir l'historique
git log --oneline
git log --oneline --graph --all
git log -p src/style.css # Avec les diffs
Bons messages de commit
Un bon message de commit suit le format Conventional Commits :
feat: ajouter la page contact avec formulaire
fix: corriger l'erreur 500 sur /api/users
refactor: extraire la logique de validation dans un service
docs: completer le README avec la procedure de deploiement
style: passer le projet a Prettier
chore: mettre a jour les dependances npm
Clair, court, en imperatif. Ton futur toi (et tes collegues) te diront merci.
Le .gitignore
Absolument indispensable. Cree-le a la racine AVANT le premier commit :
# Dependances
node_modules/
vendor/
.pnp/
# Secrets
.env
.env.local
.env.*.local
*.key
*.pem
secrets.json
# Builds
dist/
build/
.next/
.nuxt/
*.log
# OS
.DS_Store
Thumbs.db
*.swp
# IDE
.vscode/
.idea/
# Tests/coverage
coverage/
.nyc_output/
Si tu oublies .env au premier commit, c'est galere a retirer de l'historique. Utilise git-filter-repo :
pip install git-filter-repo
git filter-repo --path .env --invert-paths
Et change tous les secrets compromise immediatement.
Les branches : ton outil principal
Les branches permettent de bosser sur des fonctionnalites isolees sans casser le code principal.
# Creer et basculer (ancienne syntaxe)
git checkout -b feature/navbar
# Equivalent moderne (Git 2.23+, recommande)
git switch -c feature/navbar
# Lister les branches
git branch # Locales
git branch -a # Toutes (locales + distantes)
git branch --merged # Deja mergees dans la courante
# Changer de branche
git switch main
git switch - # Retour a la branche precedente
# Supprimer
git branch -d feature/navbar # Si deja mergee
git branch -D feature/navbar # Forcer la suppression
Fusionner : merge ou rebase ?
Une fois ta fonctionnalite terminee, tu integres dans main.
Merge classique
git switch main
git pull origin main # Recupere les modifs distantes
git merge feature/navbar
git push origin main
Merge avec --no-ff (commit de merge explicite)
git merge --no-ff feature/navbar -m "Merge feature/navbar dans main"
Utile pour garder l'historique des branches lisible.
Rebase (historique lineaire)
# Sur ta branche feature
git switch feature/navbar
git rebase main
# Resoudre les conflits si necessaire, puis :
git switch main
git merge feature/navbar # Fast-forward propre
Le rebase reecrit l'historique : tes commits sont rejoues par-dessus main. Resultat : un graphe lineaire, plus facile a lire. Mais ATTENTION : ne rebase JAMAIS une branche partagee avec d'autres developpeurs.
Gerer un conflit
Quand deux branches modifient le meme fichier sur les memes lignes :
# Auto-merging index.html
# CONFLICT (content): Merge conflict in index.html
# Automatic merge failed; fix conflicts and then commit the result.
Dans le fichier :
<<<<<<< HEAD
<nav class="navbar navbar-dark">
=======
<nav class="navbar navbar-light">
>>>>>>> feature/navbar
Edite pour garder ce que tu veux, puis :
git add index.html
git commit # Sans -m, Git ouvre l'editeur avec un message pre-rempli
C'est stressant la premiere fois mais on s'y fait vite. VS Code et JetBrains ont des outils de merge graphiques qui aident enormement.
Travailler avec GitHub
Connecter un depot local a GitHub
Cree d'abord le repo sur github.com (vide), puis :
git remote add origin git@github.com:utilisateur/mon-projet.git
git branch -M main
git push -u origin main
Le -u etablit le tracking : tu pourras faire git pull et git push sans arguments par la suite.
Workflow quotidien collaboratif
# Matin : recuperer les modifs de l'equipe
git switch main
git pull origin main
# Creer une branche pour ta tache
git switch -c feature/checkout-improvements
# Bosser, commiter regulierement
git add .
git commit -m "feat: ajouter validation Stripe au checkout"
# Pousser ta branche
git push -u origin feature/checkout-improvements
# Sur GitHub : creer une Pull Request
# Apres revue et merge, nettoyer
git switch main
git pull origin main
git branch -d feature/checkout-improvements
Authentification SSH avec GitHub
# Generer une cle si tu n'en as pas
ssh-keygen -t ed25519 -C "dylan@exemple.fr"
# Copier la cle publique
cat ~/.ssh/id_ed25519.pub
Colle-la dans GitHub > Settings > SSH and GPG keys > New SSH key. Test :
ssh -T git@github.com
# Hi dylan! You've successfully authenticated
Commandes du quotidien
# Voir les modifs
git diff # Working directory vs staging
git diff --staged # Staging vs dernier commit
git diff main..feature/x # Entre branches
# Annuler les modifs locales d'un fichier
git restore index.html
# Retirer du staging (sans perdre les modifs)
git restore --staged index.html
# Modifier le dernier commit (avant push uniquement)
git commit --amend -m "Nouveau message"
git commit --amend --no-edit # Garder le message, ajouter des fichiers
# Stash : mettre de cote temporairement
git stash
git stash list
git stash pop # Recuperer le dernier stash
git stash apply stash@{2} # Recuperer un stash specifique
git stash drop stash@{0}
# Qui a modifie cette ligne ?
git blame index.html
# Chercher dans l'historique
git log --grep="navbar"
git log -p -- src/style.css
git log --author="Dylan" --since="2 weeks ago"
# Annuler un commit deja pousse (cree un commit inverse)
git revert abc1234
# Tagger une release
git tag -a v1.0.0 -m "Release 1.0.0"
git push origin v1.0.0
Workflow recommande pour un projet web
Le modele que j'utilise sur la majorite des projets clients :
main= toujours fonctionnel et deployable. Protected branch sur GitHub.- Une branche par tache :
feature/...,fix/...,chore/... - Commits frequents sur la branche
- Pull Request sur GitHub avec description claire
- Code review par au moins une personne
- CI verte (tests, linting) avant merge
- Squash merge pour garder un historique propre dans main
- Deploy depuis main (idealement automatique via GitHub Actions)
Pour les projets plus gros, ajoute une branche develop et des branches release/x.y.z (modele Git Flow).
Deployer avec Git sur ton serveur IONOS
Methode simple sans CI/CD : un hook post-receive.
Sur le serveur
mkdir -p /var/www/monsite.fr
cd /var/www
git init --bare deploy.git
Cree /var/www/deploy.git/hooks/post-receive :
#!/bin/bash
set -e
GIT_WORK_TREE=/var/www/monsite.fr
export GIT_WORK_TREE
git checkout -f main
cd /var/www/monsite.fr
npm ci --production
npm run build
systemctl reload nginx
echo "Deploiement reussi : $(date)"
chmod +x /var/www/deploy.git/hooks/post-receive
chown -R www-data:www-data /var/www/monsite.fr /var/www/deploy.git
Depuis ta machine
git remote add production ssh://deploy@serveur.com/var/www/deploy.git
git push production main
A chaque git push production main, le hook se declenche et deploie le code.
Pour des cas plus complexes, prefere GitHub Actions qui te donne CI + CD avec des logs propres et de la rollback simple.
Erreurs courantes et leur fix
error: failed to push some refs
Cause : la branche distante a des commits que tu n'as pas localement (un collegue a pousse).
Fix :
git pull --rebase origin main
# Resous les conflits si necessaire
git push origin main
fatal: refusing to merge unrelated histories
Cause : tu essaies de merger deux historiques qui n'ont aucun ancetre commun (typiquement quand tu git init localement puis tu connectes a un repo deja existant avec README).
Fix :
git pull origin main --allow-unrelated-histories
.env committe par erreur
Cause : le .gitignore n'etait pas en place au moment du commit.
Fix :
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Retirer .env de l'historique"
# CHANGE TOUS LES SECRETS DU FICHIER, ils sont publics
git filter-repo --path .env --invert-paths # Pour purger l'historique
detached HEAD state
Cause : tu as fait git checkout abc1234 (un commit specifique) au lieu d'une branche.
Fix :
git switch -c nouvelle-branche # Sauvegarde tes modifs dans une nouvelle branche
# Ou
git switch main # Si tu n'avais rien fait
Auto-merging file.txt CONFLICT (content)
Cause : conflit lors du merge ou rebase.
Fix :
git status # Voit les fichiers en conflit
# Resous chaque fichier (manuel ou avec git mergetool)
git add file.txt
git commit # Si merge
git rebase --continue # Si rebase
# Ou
git merge --abort
git rebase --abort # Pour annuler
Pour aller plus loin
- Deployer une application avec GitHub Actions : aller plus loin qu'un simple push hook.
- Configurer SSH proprement : indispensable pour utiliser Git via SSH avec GitHub/GitLab.
- Simplifier ses connexions SSH avec ssh_config : alias et raccourcis pour tes serveurs.
- Migrer un site WordPress sans temps d'arret : Git fait partie de la chaine de migration.
- Automatiser les backups avec Bash et cron : un repo Git n'est pas une sauvegarde, garde des backups separes.
L'investissement qui se rentabilise immediatement
Git demande deux ou trois apres-midi pour vraiment etre a l'aise, mais c'est un investissement qui paie des le premier jour. Tu codes plus serenement parce que tu peux tout annuler. Tu collabores sans craindre d'ecraser le travail d'un collegue. Tu deploies de maniere reproductible. Et surtout, tu ne perds plus jamais 3 jours de travail a cause d'une mauvaise manip avec un dossier de "sauvegarde". Apprends le minimum cette semaine, et complete au fur et a mesure des besoins.
