Git

Qu’est-ce que Git ?

Git est un système de contrôle de version distribué qui suit les modifications apportées aux fichiers au fil du temps. Il vous permet de sauvegarder des instantanés (snapshots) de votre projet à tout moment, de comparer des versions, de corriger des erreurs et de collaborer avec d’autres personnes sans écraser le travail des uns et des autres.

Créé par Linus Torvalds en 2005 pour gérer le noyau Linux, Git est devenu le système de contrôle de version le plus utilisé au monde. Que vous développiez un projet personnel en solo ou que vous contribuiez à une base de code impliquant des milliers de développeurs, Git est l’outil qui rend cela possible.

L’idée fondamentale est simple : au lieu de sauvegarder une copie unique de votre projet, Git enregistre une série de commits — des instantanés de chaque fichier suivi à un moment précis. Vous pouvez remonter dans le temps, comparer des versions, créer des branches pour tester de nouvelles idées et fusionner votre travail une fois qu’il est prêt. Ce modèle s’adapte aussi bien à une seule personne qu’à des milliers d’utilisateurs.

Pourquoi le versioning est essentiel

Sans contrôle de version, la collaboration devient chaotique. Si deux personnes modifient le même fichier, le travail de l’une sera forcément écrasé par celui de l’autre. Un bug introduit la semaine dernière oblige à annuler manuellement des heures de modifications. Une expérimentation de fonctionnalité qui échoue signifie devoir tout recommencer de zéro.

Git résout tous ces problèmes :

• Suivre chaque modification — qui a changé quoi, quand et pourquoi. L’historique complet est toujours disponible.
• Revenir en arrière en toute sécurité — retournez à n’importe quel état précédent sans perdre votre travail actuel.
• Travailler en parallèle — les branches permettent à plusieurs personnes de travailler simultanément sur différentes fonctionnalités.
• Collaborer sans crainte — Git fusionne les modifications intelligemment et signale les conflits pour que vous puissiez les résoudre.
• Travailler hors ligne — tout reste local jusqu’à ce que vous décidiez de pousser vos modifications vers un serveur distant.

Le contrôle de version n’est pas optionnel pour le développement professionnel. C’est une compétence fondamentale dont tout développeur a besoin, quel que soit le langage, le framework ou la plateforme utilisé.

Comment fonctionne Git

Git s’appuie sur trois zones principales : le working directory (répertoire de travail), la staging area (zone de transit) et le repository (dépôt).

Votre working directory est l’endroit où vous modifiez vos fichiers. Lorsque vous exécutez git add, les modifications sont déplacées vers la staging area — une zone de préparation pour le prochain commit. Lorsque vous exécutez git commit, les modifications indexées sont sauvegardées sous forme de nouveau snapshot dans le repository.

# Edit a file in your working directory
echo "Hello, Git!" > hello.txt

# Stage the change
git add hello.txt

# Commit the staged change
git commit -m "Add hello.txt"

Ce flux en trois étapes — modifier, indexer, commiter — vous offre un contrôle précis sur le contenu de chaque snapshot. Vous pouvez indexer des parties d’un fichier, indexer plusieurs fichiers ensemble et créer des commits représentant chacun un seul changement logique.

Sous le capot, Git stocke les données sous forme de graphe orienté acyclique (DAG) d’objets de commit. Chaque commit pointe vers son parent, formant ainsi une chaîne d’historique. Les branches ne sont que des pointeurs légers vers des commits spécifiques, et HEAD est un pointeur vers le commit sur lequel vous vous trouvez actuellement.

Installer Git

Git est disponible pour tous les principaux systèmes d’exploitation :

macOS :

# Using Homebrew
brew install git

# Or install Xcode Command Line Tools
xcode-select --install

Windows :

# Download from git-scm.com or use winget
winget install Git.Git

Linux :

# Debian/Ubuntu
sudo apt install git

# Fedora
sudo dnf install git

# Arch
sudo pacman -S git

Vérifiez l’installation :

git --version
# git version 2.45.0

Après l’installation, configurez votre identité — ces informations seront incluses dans chaque commit que vous effectuerez :

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Commandes Git essentielles

Créer un dépôt

# Start a new repository in the current directory
git init

# Clone an existing repository
git clone https://github.com/user/repo.git

git init crée un dossier caché .git/ qui contient toutes les données de suivi de Git. git clone copie un dépôt existant — incluant tout son historique — sur votre machine.

Suivre les modifications

# See which files are modified, staged or untracked
git status

# Stage a specific file
git add filename.js

# Stage all changes
git add .

# Commit with a message
git commit -m "Add user authentication"

git status est la commande que vous utiliserez le plus souvent. Elle vous indique ce qui a changé, ce qui est indexé (staged) et ce que Git ne suit pas. Vérifiez toujours le statut avant de valider vos modifications.

Consulter l’historique

# Show commit history
git log

# Compact one-line format
git log --oneline

# Show changes in each commit
git log -p

# Show a visual branch graph
git log --oneline --graph --all

L’historique des commits est la chronologie de votre projet. Utilisez-le pour comprendre comment le code a évolué, qui a effectué les modifications et pourquoi certaines décisions ont été prises.

Comparer les modifications

# Diff between working directory and staging area
git diff

# Diff between staging area and last commit
git diff --staged

# Diff between two commits
git diff abc1234 def5678

git diff vous montre exactement ce qui a changé, ligne par ligne. C’est essentiel pour relire votre propre travail avant de committer et pour comprendre les modifications apportées par quelqu’un d’autre dans une pull request.

Annuler des modifications

# Discard changes in working directory
git checkout -- filename.js

# Unstage a file
git reset HEAD filename.js

# Amend the last commit
git commit --amend -m "Updated commit message"

# Revert a commit (creates a new commit that undoes it)
git revert abc1234

Git permet d’expérimenter en toute sécurité car vous pouvez toujours revenir en arrière. La clé est de comprendre la différence entre rejeter des modifications, les retirer de l’index (unstaging) et créer de nouveaux commits qui annulent les précédents.

Travailler avec des branches

# List branches
git branch

# Create a new branch
git branch feature-login

# Switch to a branch
git checkout feature-login

# Create and switch in one command
git checkout -b feature-signup

# Delete a branch
git branch -d feature-login

Les branches sont le super-pouvoir de Git. Elles vous permettent de travailler sur de nouvelles fonctionnalités, de corriger des bugs ou d’expérimenter sans affecter la base de code principale. Une fois votre travail terminé, vous fusionnez la branche.

Fusionner et rebaser

Lorsqu’une branche est prête, vous l’intégrez à la ligne principale. git merge crée un commit de fusion (merge commit) qui joint les deux historiques, tandis que git rebase rejoue vos commits au-dessus d’une autre branche pour obtenir un historique linéaire :

# Merge a feature branch into main
git checkout main
git merge feature-login

# Rebase a feature branch onto the latest main
git checkout feature-login
git rebase main

Si les mêmes lignes ont été modifiées dans les deux branches, Git s’arrête et marque les fichiers comme étant en conflit. Modifiez les fichiers pour conserver le contenu correct, supprimez les marqueurs de conflit (<<<<<<<, =======, >>>>>>>), puis indexez-les et continuez :

git add .
git merge --continue   # or: git rebase --continue

Pour garder un historique propre, un squash merge condense chaque commit d’une branche de fonctionnalité en un seul commit sur la branche cible :

git checkout main
git merge --squash feature-dark-mode
git commit -m "Add dark mode feature"

Utilisez le merge lorsque vous voulez préserver l’historique complet de la branche ; utilisez le rebase ou le squash lorsque vous voulez une branche principale propre et linéaire. Ne faites jamais de rebase ou de squash sur des commits qui ont déjà été poussés vers une branche partagée.

Synchroniser avec les dépôts distants

# Add a remote server
git remote add origin https://github.com/user/repo.git

# Push commits to remote
git push origin main

# Pull latest changes
git pull origin main

# Fetch without merging
git fetch origin

Les remotes sont des copies de votre dépôt hébergées sur des serveurs. Le remote par défaut est généralement appelé origin. Le push envoie vos commits vers le remote, et le pull télécharge et fusionne les modifications distantes dans votre branche.

Le fichier .gitignore

Tout ne doit pas être suivi par Git. Les dépendances, les fichiers de build, les fichiers d’environnement et les paramètres de l’IDE sont généralement ignorés :

# Dependencies
node_modules/
vendor/

# Build output
dist/
build/

# Environment variables
.env
.env.local

# IDE settings
.vscode/
.idea/

# OS files
.DS_Store
Thumbs.db

Placez un fichier .gitignore à la racine de votre dépôt. Git ignorera tout fichier ou répertoire correspondant à ces modèles. Si vous avez déjà commité des fichiers que vous souhaitez ignorer, retirez-les d’abord du suivi :

git rm -r --cached node_modules/
git commit -m "Remove node_modules from tracking"

Comprendre les commits

Un commit est l’unité fondamentale de Git. Chaque commit contient :

• Un hash unique — un identifiant SHA-1 de 40 caractères comme a1b2c3d4e5f6...
• Un message — une description de ce qui a changé et pourquoi
• Un auteur — la personne qui a effectué la modification
• Un horodatage — la date et l’heure auxquelles la modification a été faite
• Un parent — le commit sur lequel il s’appuie (sauf pour le premier commit)
• Un snapshot — l’état de tous les fichiers suivis à ce moment précis

Les bons messages de commit suivent une convention. La première ligne est un résumé court à l’impératif (moins de 72 caractères). Un corps optionnel permet d’expliquer le contexte :

git commit -m "Fix null pointer in user authentication

The login endpoint was throwing a 500 error when the email
field was missing from the request body. Added a null check
before accessing user properties."

Chaque commit doit représenter un seul changement logique. Cela permet de comprendre, de passer en revue et de revenir en arrière sur des modifications individuelles facilement, sans affecter le reste du travail.

Workflows Git courants

Workflow centralisé

Tout le monde travaille sur la branche main. C’est simple, mais risqué pour les équipes :

git pull origin main
# make changes
git add .
git commit -m "Update feature"
git push origin main

Workflow par branche de fonctionnalité (Feature branch)

Chaque fonctionnalité ou correction possède sa propre branche. Les fusions s’effectuent via des pull requests :

git checkout -b feature-user-profile
# make changes
git push origin feature-user-profile
# open a pull request on GitHub

Workflow Gitflow

Un modèle structuré avec des branches main, develop, feature, release et hotfix. Idéal pour les projets avec des cycles de publication planifiés :

git checkout -b develop
git checkout -b feature-new-login
# work on feature
git checkout develop
git merge feature-new-login
git checkout -b release-v1.0
# finalize release
git checkout main
git merge release-v1.0
git tag v1.0.0

Trunk-based development

Tout le monde commit fréquemment sur main (le trunk), en utilisant des feature flags à courte durée de vie. Très populaire dans des entreprises comme Google et Meta :

git checkout main
# make small, frequent changes
git add .
git commit -m "Add feature flag for new dashboard"
git push origin main

Bonnes pratiques

• Commitez tôt, commitez souvent — des commits restreints sont plus faciles à comprendre et à annuler.
• Rédigez des messages de commit clairs — utilisez le mode impératif et expliquez le pourquoi, pas seulement le quoi.
• Créez une branche pour chaque fonctionnalité — gardez la branche main propre et prête pour le déploiement.
• Pull avant le push — intégrez toujours les modifications distantes avant de partager votre travail.
• Révisez votre propre diff — lancez git diff --staged avant de commiter pour corriger les erreurs.
• Ne commitez jamais de secrets — utilisez des variables d’environnement et le fichier .gitignore.
• Taguez vos releases — utilisez des tags de version sémantique comme v1.0.0 pour faciliter les rollbacks.
• Gardez un historique propre — effectuez un rebase des branches de fonctionnalités avant la fusion pour éviter les commits de merge encombrants.

Erreurs courantes

• Committer trop de changements non liés dans un seul commit.
• Utiliser des messages vagues comme “fix” ou “update” qui n’expliquent rien.
• Faire des force-push sur des branches partagées et écraser le travail des autres.
• Ne pas configurer de .gitignore, ce qui entraîne le commit de node_modules ou de fichiers .env.
• Travailler sur main au lieu de créer une branche de fonctionnalité (feature branch).
• Oublier de pull avant de push, provoquant des conflits de fusion (merge conflicts).
• Ne pas sauvegarder les dépôts distants — le local ne suffit pas.

Quelle est la suite ?

Vous maîtrisez désormais les fondamentaux de Git : les repositories, les commits, les branches, le merging et les remotes. La suite logique est de découvrir GitHub pour la collaboration dans le cloud, la gestion des issues, les pull requests et les Actions. Choisissez un projet, construisez quelque chose de concret et laissez la pratique faire ses preuves.