🧭 Introduction

Git est un système de contrôle de version distribué.

Git facilite la collaboration, le suivi des modifications et la traçabilité complète de toutes les versions du projet.
Enfin, il permet de gérer les livraisons logicielles de manière rigoureuse grâce aux mécanismes de tags et de releases.

C’est un outil puissant qui permet de capitaliser et de partager du code de manière efficace.
Grâce à sa gestion fine de l’historique (notamment via le rebase interactif), il contribue à produire un code plus propre et plus qualitatif.

Un historique propre et cohérent inspire confiance, il témoigne d’un code maîtrisé et de livrables de qualité.

🧠Rappels

⚙️ Rappel des commandes de base

git init             # Initialise un dépôt Git
git clone URL        # Clone un dépôt distant
git status           # Vérifie l'état des fichiers
git add fichier      # Ajoute un fichier à l'index (staging area)
git commit -m "msg"  # Crée un commit
git log              # Affiche l'historique des commits

Les plus pratiques :

git commit --amend --no-edit          # fix last commit
git checkout -b release/x             # new branch and chechout in
git log --graph --decorate --oneline  # history graph
git diff <SHA-1>^ <SHA-1>                 # vu du commit en version patch
git cherry-pick <SHA-1>               # copy commit

Il est possible de créer des alias dans le fichier ~/.gitconfig, par exemple :

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

🔄 Rappel sur le cycle de vie d’un fichier

From	To	Commande
Working Directory	Staging Area	git add . ou git add fichier
Staging Area	Local Repository	git commit
Local Repository	Remote Repository	git push

État	Description
Untracked	Fichier non suivi par Git
Staged	Fichier prêt à être commit
Committed	Fichier sauvegardé dans l’historique

🗂️Rappel sur les repository

🔍 Vérifier les remotes existants

git remote -v

→ Affiche la liste des dépôts distants (nom + URL) avec en général un dépot origin fetch et push

➕ Ajouter un remote

git remote add nom url

Exemple :

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

Les commits dans Git

✅ Définition

Un commit = une modification logique unique.

Chaque commit possède un SHA-1 unique permettant de l’identifier dans l’historique.

💡 Pour partager un commit avec un collaborateur, on lui communique le SHA-1 et la branche. git checkout <SHA-1> est une commande correct

⚡ Lisibilité de l’historique

Si chaque commit a un but clair et compréhensible, la lisibilité de l’historique est facilitée.

⚠️ Principe d’atomicité

Le principe d’atomicité repose sur l’idée qu’une action ou un commit doit être indivisible et cohérente :

🔹 Un commit = une seule modification logique complète.

💡 En pratique

Chaque commit doit représenter une étape fonctionnelle autonome : il doit pouvoir être appliqué ou annulé sans casser le projet.

un terraform plan ne doit pas remonter pas d’erreur.

Si une modification touche plusieurs aspects indépendants (ex. corriger un bug + 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 à jour le README
* 43007ad refactor: simplifie la fonction d’authentification
* 971d4a7 chore: changement d'Url d'inscription

Afin d’Organisation des commits par branche :

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 à 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

⚙️ Importance de l’atomicité

Intégration continue plus fiable → un commit doit toujours laisser le projet dans un état stable, (tests qui passent, code compilable, etc.).
Le retravail de l’historique est facilité → permet de s’adapter plus facilement à la roadmap des releases en fonction des aléas du projet.
- Selon les besoins, on peut supprimer les commits non retenus pour la mise en production ou regrouper 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 du développeur.

⚠️ La rigueur ne doit absolument pas être compromise, sinon la gestion de l’historique sera sapé et les équipes vont perdre confiance dans la qualité du livrable.

Ce travail en amont vous fera gagner du temps sur le long terme.

🌿Les branches dans Git

📌 Types de branches

Branche	Rôle
main ou master	Branche stable (production)
develop	Branche principale de développement
feature/xxx	Nouvelle fonctionnalité
hotfix/xxx	Correction urgente
release/xxx	Prochaine livraison

💡 Création et navigation

git branch                     # Liste les branches
git checkout -b feature/ajout-login  # Crée et bascule sur une nouvelle branche
git checkout main               # Retourne sur la branche principale

🔀 Merge vs Rebase Prenons 2 branches X et Y.

🔹 Merge Fusionne deux branches sans réécrire l’historique.

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

Dans les faits les commits X et Y conservent leur SHA-1 original. Un commit de merge permet de marquer la fusion des 2 branches divergences.

🔹 Rebase Réécrit l’historique pour rejouer les commits sur une autre base.

Produit un historique linéaire et plus propre. X’ et Y’ équivaut à X et Y des commits originaux avec un SHA-1 différent de l’original. Cependant, le contenu est (normalement) le même.

git checkout feature/ajout-login
git rebase main

⚠️ Après tout rebase, on vérifie s’il y a des changements avant et après. En général, on rebase avant de git push --force. On évalue le changement afin de voir si dans la gestion des éventuels conflits, il n’y a pas quelque chose qui manque. Dans ce cas, on évalue ce qui manque git diff origin > ../unpatch.diff et ensuite on le rejoue patch -p1 < ../unpatch.diff. Enfin, on fixup dans le bon commit ce manquement.

🤝 Bonnes pratiques en équipe

💡Pour préparer la branche release, faire un rebase depuis la branche de production avant de faire une merge request.

✅ permet de traiter les éventuels conflits en amont. ✅ permet d’enlever les commits sans valeur comme les merges de feature dans la branche release

💡Pour chaque release qui partent en production, les tags précédant doivent apparaitre git rebase X.Y.Z-1.

💡Dans le cas d’une branche déjà partagée avec d’autres développeurs, un git pull --rebase permet de traiter toute divergence et donc les éventuelles conflits avec vos commits.

💡Si vous n’avez qu’un commit et un énorme retard, copier son SHA-1, git reset --hard origin/release/xy avec la branche à l’origin où vous souhaitez vous aligner et jouer le commit git cherry-pick SHA-1.

💡Afin de préparer une merge request dans une branche de release, un rebase interactif git rebase -i origin/release/xy permet de fixup ces commits et d’enlever les commits qui ne font pas partie de votre travail. Ceux n’ayant pas le même SHA-1 dû à une divergence remonte dans votre historique lors d’un rebase interactif et donc, vous aurez sûrement des git rebase --skip à faire.

💡Il est possible de faire git reset --soft <SHA-1> du commit qui contient le bon commentaire et de faire git commit --amend --no-edit afin de fixup les changements.

💡Chaque commit que vous effectuez est une capitalisation: git reflog permet de voir votre historique de navigation git.

❌Les mauvaises pratiques git

⚠️ Ne jamais merger la branche de production dans une branche. ⚠️ On merge uniquement la branche de release dans la branche stable de production. En ne respectant pas ce principe, si on remonte l’historique git log --graph --decorate --oneline de la branche de production, les fusions deviennent illisibles.

⚠️ Laisser des commits qui fixent le précédant alourdi l’historique et donc le travail des futurs rebases entre branche de release et de production.

🚀Guide Git – Bases & Bonnes Pratiques