Ce chapitre présente les notions dans un ordre progressif. Les commandes illustrent le fonctionnement ; les manipulations guidées sont regroupées dans les TP.
1.1 Git, dépôt et historique distribué
Git conserve des instantanés du projet et les relations entre eux. Chaque clone possède un historique local : consulter les commits, préparer une modification ou créer une branche ne nécessite pas GitHub. Le réseau intervient pour échanger avec un dépôt distant.
Le dossier .git contient les objets, références et métadonnées. Le répertoire de travail contient les fichiers que vous consultez et modifiez. Un commit identifie un état enregistré, son auteur, un message et ses parents.
1.2 Répertoire de travail, index et commit
| État / espace | Rôle | Commande repère |
|---|---|---|
| Non suivi | Fichier présent, absent du suivi Git. | git status |
| Répertoire de travail | Modifications en cours, pas nécessairement préparées. | git diff |
| Index (staging area) | Contenu exact prévu pour le prochain commit. | git add doc.txt |
| Historique | Instantané enregistré localement. | git commit -m "Clarifie la documentation" |
git add prépare le contenu actuel du fichier, pas toutes ses modifications futures. Si vous modifiez encore le fichier après l’ajout, une partie peut être indexée et une autre rester non indexée. Un commit n’envoie rien sur GitHub.
git status
git diff
git add doc.txt
git diff --cached
git commit -m "Clarifie la documentation"git add . peut convenir après cette vérification ; il peut aussi embarquer des fichiers sans rapport.1.3 Initialiser et configurer
| Commande | Sens |
|---|---|
git init | Crée un dépôt dans le répertoire courant. |
git config user.name "Votre nom" | Auteur des commits pour ce dépôt. |
git config user.email "vous@example.com" | Adresse enregistrée dans les commits. |
git config --global … | Valeur par défaut pour les dépôts de cet utilisateur. |
git config --list | Affiche les valeurs de configuration. |
git rm doc.txt | Supprime le fichier et prépare sa suppression ; un commit reste nécessaire. |
L’identité de commit n’est pas l’authentification auprès de GitHub. Le nom de la branche initiale dépend de la configuration : main et master sont des noms, pas des types de branches.
1.4 Lire et comparer l’historique
| Commande | À retenir |
|---|---|
git log --oneline --graph --all | Vue opérationnelle compacte de l’historique.
|
git log --name-status | Affiche les fichiers concernés par chaque commit.
|
git diff commitA commitB | Compare deux instantanés ; + et − montrent les lignes ajoutées et retirées. |
git blame doc.txt | Dernier commit ayant affecté chaque ligne, utile pour retrouver le contexte. |
HEAD désigne le commit courant, généralement via la branche active. Une branche est une référence qui avance avec les commits ; ce n’est pas une copie complète du projet dans un autre dossier.
1.5 Branches, fusion et conflits
| Commande | À retenir |
|---|---|
git branch feature/doc | Crée une branche sans y passer. |
git switch feature/doc | Change de branche. git switch est la commande moderne dédiée à cet usage ; elle remplace ici l’usage historique de git checkout feature/doc. |
git switch -c feature/doc | Crée la branche et y passe. C’est l’équivalent moderne de git checkout -b feature/doc. |
git merge feature/doc | Intègre la branche nommée dans la branche actuellement active. |
git branch -d feature/doc | Supprime une branche locale intégrée ; -D force cette suppression. |
Une fusion peut avancer simplement le pointeur (fast-forward) ou produire un commit de fusion. Un conflit apparaît quand Git ne peut pas réconcilier automatiquement les modifications. Les marqueurs <<<<<<<, ======= et >>>>>>> montrent les versions à décider.
Après résolution : retirer les marqueurs, vérifier le résultat, préparer les fichiers et terminer la fusion avec un commit. git merge --abort abandonne une fusion en cours. L’outil ne peut pas décider de l’intention fonctionnelle des auteurs.
git checkout. git switch rend explicite le changement de branche.1.6 Annuler sans confondre revert, reset et restore
| Commande | Historique | Index / fichiers |
|---|---|---|
git revert <commit> | Ajoute un commit inverse ; conserve la trace. | Applique l’inverse du changement. |
git reset --soft <commit> | Déplace la branche vers le commit cible. | Conserve index et fichiers. |
git reset --mixed <commit> | Déplace la branche ; mode par défaut. | Réinitialise l’index ; conserve les fichiers. |
git reset --hard <commit> | Déplace la branche. | Réinitialise index et fichiers suivis ; pertes possibles. |
git restore doc.txt | Ne crée ni ne retire un commit. | Restaure par défaut le fichier depuis l’index. |
Sur un historique partagé, revert permet une correction visible sans réécrire ce que les collègues ont récupéré. reset déplace une référence : les anciens objets ne sont pas nécessairement effacés immédiatement et peuvent encore être accessibles via le reflog, mais cela ne protège pas les modifications locales non enregistrées.
1.7 Tags et versions
git tag -a v1.0.0 -m "Version 1.0.0"
git tag
git show v1.0.0Un tag repère un commit de référence et ne suit pas les nouveaux commits comme une branche. Le tag annoté contient un message et des métadonnées. Une release GitHub peut associer ce repère à des notes et à des fichiers livrables.
1.8 Git au quotidien sous Linux et en équipe
Sur Linux, Git reste le même outil que sous Windows : ce sont surtout l'installation, les chemins, le shell et la gestion des clés SSH qui changent. Sur Debian/Ubuntu, le paquet standard suffit dans la majorité des postes DevOps.
sudo apt update
sudo apt install git
git --version
git config --global user.name "Votre nom"
git config --global user.email "vous@example.com"
git config --global init.defaultBranch main
git config --list --show-origingit, utilisé ci-dessus, suffit généralement pour un poste Linux courant. Le paquet git-all installe un ensemble plus large d'outils Git.| Besoin quotidien | Commande | Effet |
|---|---|---|
| Créer et basculer sur une branche | git switch -c feature/api | Crée la branche depuis le commit courant et s'y place. |
| Voir local + distant | git branch -a | Affiche les branches locales et les références distantes connues. |
| Rafraîchir les références distantes | git fetch --prune | Récupère l'état du remote et retire les références distantes devenues obsolètes. |
| Supprimer une branche locale livrée | git branch -d feature/api | Suppression sûre si Git considère la branche fusionnée. |
| Supprimer la branche sur le serveur | git push origin --delete feature/api | Supprime la branche du dépôt distant. |
| Mettre de côté un travail incomplet | git stash push -m "WIP" | Nettoie temporairement le working tree sans créer de commit. |
| Récupérer le stash | git stash pop | Réapplique le dernier stash puis le retire de la pile si possible. |
| Retrouver un état perdu | git reflog | Affiche les déplacements locaux de HEAD, utile après un reset/rebase malheureux. |
| Appliquer un commit ciblé | git cherry-pick <sha> | Rejoue un commit précis sur la branche courante. |
| Rejouer sa branche sur main | git rebase origin/main | Repositionne les commits locaux sur la référence choisie. |
rebase, reset et surtout un push forcé réécrivent potentiellement l'histoire. Sur une branche partagée ou protégée, privilégier la PR et git revert. Si un force push est réellement nécessaire sur sa propre branche, git push --force-with-lease est plus prudent que --force car il refuse d'écraser un remote qui a avancé à votre insu.Avant de supprimer une branche livrée, le réflexe Tech Lead est : vérifier la PR/merge, mettre à jour les références avec git fetch --prune, supprimer la branche distante si elle n'a plus d'utilité, puis nettoyer la branche locale.