Soignez l’historique de votre projet
Avez-vous déjà eu un trou de mémoire ? Certainement ! Parfois cela ne porte pas à conséquence, mais la plupart du temps, on se passerait bien de ce problème (par exemple lors d’un examen 
) !
Un repository Git possède une mémoire mais contrairement à nous, il n’a jamais de trou de mémoire ! Ce qui est une bonne nouvelle pour nous. 
Pourquoi, me direz-vous ?
Tout simplement car la mémoire du repository nous permet d’être plus performants dans la gestion de nos projets. C’est ce que nous allons découvrir dans ce chapitre. 
La mémoire du repository Git est nommée historique. Ce dernier contient la liste des commits réalisés.
Vous pouvez visualiser l’historique avec la commande git log. Voici un exemple de résultat pour cette commande :
$ git log commit c3ca7e9f03c832b1a101a9d15196df9e86152f58 (HEAD -> main, origin/main) Author: Romain Sessa <19792764+romainsessa@users.noreply.github.com> Date: Wed Mar 16 13:54:06 2022 +0100 Update CONTRIBUTING.md commit cba9b3cdf34e868bd7a938629cac11659f41f33f Author: Romain Sessa <19792764+romainsessa@users.noreply.github.com> Date: Wed Mar 16 13:52:58 2022 +0100 Update CONTRIBUTING.md commit 81e203e7acb086b2b3a1ce0f01afe73894f9a170 Author: romainsessa <romainsessa@gmail.com> Date: Wed Mar 16 11:53:31 2022 +0100 Fichiers de documentation : README, CONTRIBUTING, CODE OF CONDUCT, LICENCE
Très bien, mais pourquoi vouloir corriger l’historique du projet, en fait ??
Pour différentes raisons : corriger une erreur ou avoir un historique de commits le plus compréhensible possible, par exemple. Car oui, l’historique peut être pollué !
Découvrons cela plus précisément ensemble !
Faites une correction simple sur l’historique du projet
Commençons avec un cas simple : alors que vous venez de résoudre une issue et que vous avez fièrement commité le résultat de votre travail, vous vous rendez compte que vous avez oublié un fichier. 
Comment feriez-vous pour corriger cela ?
Facile, git add du fichier manquant puis git commit !
Certes, votre solution vous permettra d’obtenir le résultat souhaité, mais elle aura une conséquence fâcheuse : votre historique contiendra 1 commit supplémentaire qui, fondamentalement, n’apporte rien. En d’autres termes : cette solution va polluer votre historique.
Et alors, quel est le problème ?
Imaginez cette situation à l’échelle de grands projets avec de nombreux collaborateurs : l’historique deviendrait de plus en plus illisible, et nous perdrions l’avantage d’une traçabilité claire des opérations sur le projet.
Git nous offre une solution simple avec l’option --amend de la commande git commit pour éviter cette situation. Voilà comment vous en servir :
modification de 2 fichiers : README.md et CONTRIBUTING.md ;
git add README.md ;
git commit -m “Mise à jour de README.md et CONTRIBUTING.md”.
Oups ! On réalise notre erreur, nous avons oublié le fichier CONTRIBUTING.md :
git add CONTRIBUTING.md ;
git commit --amend.
Simple mais efficace ! 
Modifiez précisément l’historique du projet
Attaquons-nous à un autre scénario ! En bon contributeur, vous ne travaillez pas sur la branche main, vous avez créé une branche nommée feature (ou fonctionnalité, en français) pour modifier les fichiers. Vous avez prévu de merger feature sur main une fois votre contribution réalisée.
Mais voilà, un problème majeur a été détecté par votre équipe sur la branche main, et il est résolu dans la foulée par un collaborateur. Vous pensiez que votre branche avait comme point de départ le dernier commit de la branche main mais ce n’est plus le cas ! Qui plus est, il vous faut intégrer le correctif appliqué à la branche main à votre branche.
Comment feriez-vous ?
Hum… je me place sur ma branche, puis je fais un git merge main.
Intéressant, vous allez en effet intégrer le correctif à votre branche à travers un commit de merge. C’est pas mal, mais ça a l’inconvénient, encore une fois, de polluer la lisibilité de l’historique.
Tu vas encore nous sortir une nouvelle commande, c’est ça ?
On ne peut rien vous cacher 
! L’heureuse élue est : git rebase. Cette commande permet de réécrire l’historique de la branche que l’on rebase. Cela signifie que cette branche est déplacée à la pointe de la branche main, comme le montre l’image ci-dessous :
Ainsi l’historique du projet est linéaire et propre. Je pense qu’une démonstration peut vous aider à bien comprendre cette manipulation :
Retenons qu’une fois positionné sur la branche feature, il ne vous reste plus qu’à exécuter git rebase main.
Localisez et corrigez un bug sans impacter la tâche courante
Le dernier scénario que nous traiterons dans ce chapitre est assez fréquent pour les développeurs. Vous êtes en plein développement d’une nouvelle fonctionnalité quand tout à coup, on vous informe d’un bug à résoudre en haute priorité. Ce bug doit être résolu sur la branche que vous utilisez.
Laissez-moi vous apprendre une façon propre de traiter cette situation.
Voici la méthode :
Mettre de côté le développement en cours.
Identifier le commit qui est à l’origine du bug.
Annuler ce commit.
Reprendre le développement qui a été mis de côté.
Retrouvez-moi dans la démonstration suivante pour mettre en œuvre cette méthode :
Récapitulons les commandes utilisées :
git stash permet de mettre de côté le développement en cours ;
git stash pop permet de récupérer ce qui a été stashé ;
git bisect (et ses options start, good, bad, reset) sert à identifier un commit problématique en parcourant l’historique ;
git revert permet de créer un nouveau commit qui contient l’inverse du commit concerné, ce qui revient à annuler l’effet de ce dernier.
Nous arrivons au bout de ce chapitre, et j’espère que vous avez pu apprécier la puissance des différentes commandes que nous avons pu explorer. À n’en pas douter, maîtriser ces commandes c’est devenir un expert. 
À vous de jouer !
Rassurez-vous, je ne vais pas vous demander de pratiquer de nouveau chacun des cas vus dans le chapitre. 
Concentrons-nous sur ce que vous risquez de rencontrer le plus : localiser et corriger un bug.
Placez-vous dans la branche p1c4.
Cette branche contient différents commits sur le fichier README.md, dont un est erroné : la section Prérequis a été supprimée au lieu d’être mise à jour.
Appliquez la procédure pour corriger un bug sans impacter la tâche “courante”.
Pour la correction, je vous propose de regarder la vidéo suivante :
En résumé
git commit --amend permet de modifier le dernier commit.
git rebase permet de réécrire l’historique d’une branche.
git stash permet de mettre de côté le développement en cours.
git stash pop permet de récupérer le développement mis de côté.
git bisect permet d’identifier un commit problématique en parcourant l’historique.
git revert permet d’annuler un commit.
Félicitations, vous êtes arrivé au bout de la première partie du cours ! 
Allez, continuons avec la deuxième partie, où notre maîtrise de Git et GitHub ne cessera de croître. 
Mais avant, je vous propose de tester vos connaissances grâce au quiz !
