Guide Git : Bases et Bonnes Pratiques

Git est un système de contrôle de version distribué. Il facilite la collaboration, le suivi des modifications et la traçabilité complète de toutes les versions d'un projet, et permet de gérer les livraisons de façon rigoureuse grâce aux tags et aux releases.

Sa gestion fine de l'historique — notamment le rebase interactif — contribue à produire un code plus propre. Un historique cohérent inspire confiance : il témoigne d'un code maîtrisé et de livrables de qualité.

Les commandes de base

git init             # Initialise un depot
git clone URL        # Clone un depot distant
git status           # Verifie l etat des fichiers
git add fichier      # Ajoute un fichier a l index
git commit -m "msg"  # Cree un commit
git log              # Affiche l historique

Les plus utiles au quotidien :

git commit --amend --no-edit          # corriger le dernier commit
git checkout -b release/x             # creer une branche et s y placer
git log --graph --decorate --oneline  # historique en graphe
git diff SHA^ SHA                     # voir un commit sous forme de patch
git cherry-pick SHA                   # rejouer un commit ailleurs

Ces commandes gagnent à être raccourcies par des alias dans la configuration Git :

co=checkout
can=commit --amend --no-edit
lk=log --graph --decorate --oneline
diffp=!f() { git diff "$1^" "$1"; }; f
cp=cherry-pick

Le cycle de vie d'un fichier

Depuis	Vers	Commande
répertoire de travail	index	`git add`
index	dépôt local	`git commit`
dépôt local	dépôt distant	`git push`

État	Description
untracked	fichier non suivi
staged	fichier prêt à être commité
committed	fichier enregistré dans l'historique

Les dépôts distants

git remote -v affiche la liste des dépôts distants, nom et URL — en général un seul, origin, en lecture et en écriture. On en ajoute un avec :

git remote add superuser https://github.com/user/repo.git

Un commit est une modification logique unique

Chaque commit possède un SHA-1 unique qui l'identifie dans l'historique. Pour partager un commit avec quelqu'un, on lui communique ce SHA et la branche — git checkout SHA est une commande valide.

Le principe d'atomicité

Un commit doit être indivisible et cohérent : une seule modification logique complète. Concrètement, il doit représenter une étape fonctionnelle autonome, qui peut être appliquée ou annulée sans casser le projet — les tests passent, le code compile, un plan d'infrastructure ne remonte pas d'erreur.

Si une modification touche plusieurs aspects indépendants — corriger un bug et reformater du code — il vaut mieux faire plusieurs commits séparés :

* 7f44b46 feat: ajout du formulaire de contact
* 5be4bae fix: corrige le bug d affichage sur mobile
* ad56a90 doc: met a jour le README
* 43007ad refactor: simplifie la fonction d authentification
* 971d4a7 chore: changement d URL d inscription

Organisés par branche, ces mêmes commits se lisent ainsi :

git lk release/20251110
* b6e8041 (HEAD -> release/20251110, origin/release/20251110) feat: ajout du formulaire de contact
* e3a437c refactor: simplifie la fonction d authentification
* d81b76f doc: met a jour le README
* 81ddefd (origin/feature/20251110) chore: changement d URL d inscription
* 1243ddd (origin/hotfix/20251110, origin/master) fix: corrige le bug d affichage sur mobile

Pourquoi l'atomicité compte

L'intégration continue devient fiable : un commit laisse toujours le projet dans un état stable.

L'historique se retravaille : on s'adapte à la feuille de route des livraisons en fonction des aléas du projet. Selon les besoins, on supprime les commits non retenus pour la mise en production, ou on regroupe les fonctionnalités livrées dans une même release. C'est sur ce point que Git apporte une réelle valeur ajoutée au travail quotidien.

La rigueur ne doit pas être compromise : sans elle, la gestion de l'historique est sapée et les équipes perdent confiance dans la qualité du livrable. Ce travail en amont fait gagner du temps sur le long terme.

Les branches

Branche	Rôle
`main`	branche stable, la production
`develop`	branche principale de développement
`feature/xxx`	nouvelle fonctionnalité
`hotfix/xxx`	correction urgente
`release/xxx`	prochaine livraison

git branch                           # Liste les branches
git checkout -b feature/ajout-login  # Cree une branche et s y place
git checkout main                    # Retourne sur la principale

Fusion ou rebase : deux façons de rapprocher deux branches

Prenons deux branches divergentes, X et Y.

La fusion conserve l'historique

git checkout release/next
git merge feature/xy --no-ff

Les commits X et Y conservent leur SHA d'origine, et un commit de fusion vient marquer la rencontre des deux branches.

Le rebase réécrit l'historique

git checkout feature/ajout-login
git rebase main

Les commits sont rejoués sur une autre base, ce qui produit un historique linéaire. X' et Y' correspondent à X et Y, avec un SHA différent — le contenu, lui, est normalement identique.

C'est ce « normalement » qui demande de la vigilance. Après tout rebase, il faut comparer l'avant et l'après, en général avant un git push --force. La résolution des conflits peut avoir laissé tomber quelque chose : on évalue alors l'écart avec git diff origin > ../unpatch.diff, on le rejoue avec patch -p1 < ../unpatch.diff, puis on l'intègre au bon commit.

Bonnes pratiques en équipe

Préparer la branche de livraison par un rebase depuis la production, avant d'ouvrir une demande de fusion.

Cela permet de traiter les conflits en amont, et d'enlever les commits sans valeur — typiquement les fusions de branches de fonctionnalité dans la branche de livraison.

Faire apparaître les tags précédents pour chaque livraison qui part en production, avec git rebase X.Y.Z-1.

Sur une branche déjà partagée, git pull --rebase traite les divergences et les conflits éventuels avec vos propres commits.

Avec un seul commit et un gros retard, copiez son SHA, alignez-vous sur la branche distante avec git reset --hard origin/release/xy, puis rejouez le commit avec git cherry-pick SHA.

Pour préparer une demande de fusion, un rebase interactif git rebase -i origin/release/xy permet de regrouper vos commits et d'écarter ceux qui ne font pas partie de votre travail. Les commits dont le SHA a changé à cause d'une divergence remontent dans votre historique pendant l'opération : vous aurez donc probablement des git rebase --skip à passer.

Pour corriger un commit sans en créer un nouveau, git reset --soft SHA sur le commit qui porte le bon message, puis git commit --amend --no-edit.

Rien n'est jamais vraiment perdu : git reflog retrace votre navigation dans le dépôt.

Les mauvaises pratiques

Ne jamais fusionner la branche de production dans une autre branche. La fusion va dans l'autre sens : c'est la branche de livraison qui entre dans la branche stable. En ne respectant pas ce principe, l'historique de la production devient illisible dès qu'on le remonte en graphe.

Ne pas laisser traîner les commits qui corrigent le précédent. Ils alourdissent l'historique, et donc le travail de tous les rebases suivants entre la branche de livraison et celle de production.