Réécrire l'historique de Git en toute confiance : un guide

En tant que développeur, vous travaillez tout le temps avec Git. Êtes-vous déjà arrivé à un point où vous avez dit: "Uh-oh, qu'est-ce que je viens de faire?" Cet article vous donnera les outils pour réécrire l'histoire en toute confiance. Remarques avant de commencer J'ai également donné une conférence en direct couvrant le contenu de ce post. Si vous préférez une vidéo (ou souhaitez la regarder en même temps que la lecture) — vous pouvez la trouver . ici Je travaille sur un livre sur Git ! Êtes-vous intéressé à lire les versions initiales et à fournir des commentaires ? Envoyez-moi un email: gitting.things@gmail.com Enregistrer les modifications dans Git Avant de comprendre comment des choses dans Git, vous devez d'abord comprendre comment nous les modifications dans Git. Si vous connaissez déjà tous les termes, n'hésitez pas à sauter cette partie. annuler enregistrons Il est très utile de considérer Git comme un système permettant d'enregistrer des instantanés d'un système de fichiers dans le temps. Considérant un référentiel Git, il a trois « états » ou « arborescences » : Habituellement, lorsque nous travaillons sur notre code source, nous travaillons à partir d'un . Un (ou ) est n'importe quel répertoire de notre système de fichiers auquel est associé un . répertoire de travail répertoire de travail (ectrory) arbre de travail référentiel Il contient les dossiers et fichiers de notre projet ainsi qu'un répertoire appelé . J'ai décrit le contenu du dossier plus en détail dans . .git .git un message précédent Après avoir apporté certaines modifications, vous souhaiterez peut-être les enregistrer dans votre . Un (en bref : ) est une collection de , dont chacun est une archive de ce à quoi ressemblait du projet à une date passée, que ce soit sur votre machine ou sur celle de quelqu'un d'autre. référentiel dépôt repo commits l'arborescence de travail Un comprend également des éléments autres que nos fichiers de code, tels que , des branches, etc. référentiel HEAD Entre les deux, nous avons l' ou la ; ces deux termes sont interchangeables. Lorsque nous une branche, Git remplit l' avec tout le contenu du fichier qui a été extrait pour la dernière fois dans notre et à quoi il ressemblait lors de son extraction initiale. index staging area checkout index répertoire de travail Lorsque nous utilisons , le est créé en fonction de l'état de l' . git commit commit index Ainsi, l' ou la est votre terrain de jeu pour le prochain commit. Vous pouvez travailler et faire ce que vous voulez avec l' , y ajouter des fichiers, en supprimer des éléments, puis seulement lorsque vous êtes prêt, vous allez de l'avant et vous engagez dans le référentiel. index, zone de staging, index Il est temps de mettre la main à la pâte 🙌🏻 Utilisez pour initialiser un nouveau référentiel. Écrivez du texte dans un fichier appelé : git init 1.txt Parmi les trois états d'arborescence décrits ci-dessus, où se trouve maintenant ? 1.txt Dans l'arbre de travail, car il n'a pas encore été introduit dans l'index. Pour le , pour l'ajouter à l'index, utilisez . mettre en scène git add 1.txt Maintenant, nous pouvons utiliser pour valider nos modifications dans le référentiel. git commit Vous avez créé un nouvel objet de validation, qui inclut un pointeur vers un arbre décrivant l'intégralité de l'arbre de travail. Dans ce cas, ce ne sera que dans le dossier racine. En plus d'un pointeur vers l'arborescence, l'objet de validation inclut des métadonnées, telles que des horodatages et des informations sur l'auteur. 1.txt Pour plus d'informations sur les objets dans Git (tels que les commits et les arbres), . regarde mon post précédent (Oui, "check out", jeu de mots voulu 😇) Git nous indique également la valeur SHA-1 de cet objet commit. Dans mon cas, c'était (qui ne sont que les 7 premiers caractères de la valeur SHA-1, pour économiser de l'espace). c49f4ba Si vous exécutez cette commande sur votre ordinateur, vous obtiendrez une valeur SHA-1 différente, car vous êtes un auteur différent ; également, vous créeriez le commit sur un horodatage différent. Lorsque nous initialisons le référentiel, Git crée une nouvelle branche (nommée par défaut). Et . Donc, par défaut, vous n'avez que la branche . Que se passe-t-il si vous avez plusieurs succursales ? Comment Git sait-il quelle branche est la branche active ? main une branche dans Git est juste une référence nommée à un commit main Git a un autre pointeur appelé , qui pointe (généralement) vers une branche, qui pointe ensuite vers un commit. D'ailleurs, Il comprend le nom de la branche avec quelques préfixes. HEAD sous la capuche, HEAD n'est qu'un fichier. Il est temps d'introduire plus de changements dans le référentiel ! Maintenant, je veux en créer un autre. Créons donc un nouveau fichier et ajoutons-le à l'index, comme précédemment : Maintenant, il est temps d'utiliser . Il est important de noter que fait choses : git commit git commit deux Tout d'abord, il crée un objet de validation, il existe donc un objet dans la base de données d'objets interne de Git avec une valeur SHA-1 correspondante. Ce nouvel objet commit pointe également vers le commit parent. C'est le commit vers lequel pointait lorsque vous avez écrit la commande . HEAD git commit Deuxièmement, déplace le pointeur de la branche active — dans notre cas, ce serait , pour pointer vers l'objet commit nouvellement créé. git commit main Annulation des modifications Pour réécrire l'historique, commençons par annuler le processus d'introduction d'un commit. Pour cela, nous allons faire connaissance avec la commande , un outil super puissant. git reset git reset --soft Donc, la toute dernière étape que vous avez faite auparavant était de , ce qui signifie en fait deux choses : Git a créé un objet commit et a déplacé , la branche active. Pour annuler cette étape, utilisez la commande . git commit main git reset --soft HEAD~1 La syntaxe fait référence au premier parent de . Si j'avais plus d'un commit dans le commit-graph, dites "Commit 3" pointant vers "Commit 2", qui à son tour pointe vers "Commit 1". HEAD~1 HEAD Et disons que pointait vers "Commit 3". Vous pouvez utiliser pour faire référence à "Commit 2", et ferait référence à "Commit 1". HEAD HEAD~1 HEAD~2 Donc, revenons à la commande : git reset --soft HEAD~1 Cette commande demande à Git de modifier tout ce vers quoi pointe. (Remarque : dans les diagrammes ci-dessous, j'utilise pour « tout ce vers quoi pointe »). Dans notre exemple, pointe vers . Ainsi, Git ne changera que le pointeur de pour pointer vers . C'est-à-dire que pointera vers "Commit 1". HEAD *HEAD HEAD HEAD main main HEAD~1 main Cependant, cette commande n'affectait l'état de l'index ou de l'arbre de travail. Donc, si vous utilisez , vous verrez que est mis en scène, comme avant d'exécuter . pas git status 2.txt git commit Qu'en est-il de Il commencera par , ira à , puis à "Commit 1". Notez que cela signifie que "Commit 2" n'est plus accessible depuis notre historique. git log? HEAD main Cela signifie-t-il que l'objet commit de "Commit 2" est supprimé ? 🤔 Non, il n'est pas supprimé. Il réside toujours dans la base de données d'objets interne de Git. Si vous poussez l'historique actuel maintenant, en utilisant , Git ne poussera pas "Commit 2" sur le serveur distant, mais l'objet commit existe toujours sur votre copie locale du référentiel. git push Maintenant, validez à nouveau - et utilisez le message de validation de "Commit 2.1" pour différencier ce nouvel objet du "Commit 2" d'origine : Pourquoi "Commit 2" et "Commit 2.1" sont-ils différents ? Même si nous avons utilisé le même message de validation, et même s'ils pointent vers (du dossier racine composé de et ), ils ont toujours des horodatages différents, car ils ont été créés à des moments différents. le même objet arbre 1.txt 2.txt Dans le dessin ci-dessus, j'ai conservé "Commit 2" pour vous rappeler qu'il existe toujours dans la base de données d'objets interne de Git. "Commit 2" et "Commit 2.1" pointent maintenant vers "Commit 1", mais seul "Commit 2.1" est accessible depuis . HEAD Git Reset --Mixte Il est temps de revenir en arrière et de défaire plus loin. Cette fois, utilisez (remarque : est le commutateur par défaut pour ). git reset --mixed HEAD~1 --mixed git reset Cette commande démarre de la même manière que . Cela signifie qu'il prend le pointeur de tout ce que pointe maintenant, qui est la branche , et le définit sur , dans notre exemple - "Commit 1". git reset --soft HEAD~1 HEAD main HEAD~1 Ensuite, Git va plus loin, annulant efficacement les modifications que nous avons apportées à l'index. C'est-à-dire, changer l'index pour qu'il corresponde au actuel, le nouveau après l'avoir défini à la première étape. HEAD HEAD Si nous lancions , cela signifie que serait défini sur ("Commit 1"), puis Git ferait correspondre l'index à l'état de "Commit 1" - dans ce cas, il signifie que ne fera plus partie de l'index. git reset --mixed HEAD~1 HEAD HEAD~1 2.txt Il est temps de créer un nouveau commit avec l'état du "Commit 2" d'origine. Cette fois, nous devons à nouveau mettre en scène avant de le créer : 2.txt Réinitialisation de Git --Hard Allez-y, annulez encore plus ! Allez-y et lancez git reset --hard HEAD~1 Encore une fois, Git commence par l'étape , en définissant tout ce que pointe vers ( ), sur ("Commit 1"). --soft HEAD main HEAD~1 Jusqu'ici, tout va bien. Ensuite, passez à l'étape , en faisant correspondre l'index avec . Autrement dit, Git annule la mise en scène de . --mixed HEAD 2.txt Il est temps pour l'étape où Git va encore plus loin et fait correspondre le répertoire de travail avec l'étape de l'index. Dans ce cas, cela signifie supprimer également du répertoire de travail. --hard 2.txt (**Remarque : dans ce cas précis, le fichier il ne sera donc pas supprimé du système de fichiers ; ce n'est cependant pas vraiment important pour comprendre ). n'est pas suivi, git reset Donc, pour introduire un changement dans Git, vous avez trois étapes. Vous modifiez le répertoire de travail, l'index ou la zone de staging, puis vous validez un nouvel instantané avec ces modifications. Pour ces modifications : annuler Si nous utilisons , nous annulons l'étape de validation. git reset --soft Si nous utilisons , nous annulons également l'étape de mise en scène. git reset --mixed Si nous utilisons , nous annulons les modifications apportées au répertoire de travail. git reset --hard Scénarios réels ! Scénario 1 Donc, dans un scénario réel, écrivez "J'aime Git" dans un fichier ( ), car nous aimons tous Git 😍. Allez-y, mettez en scène et validez ceci également : love.txt Oh, oups ! En fait, je ne voulais pas que tu le commettes. Ce que je voulais vraiment que vous fassiez, c'est d'écrire quelques mots d'amour supplémentaires dans ce fichier avant de le valider. Que pouvez-vous faire? Eh bien, une façon de surmonter cela serait d'utiliser , en annulant efficacement les actions de validation et de mise en scène que vous avez prises : git reset --mixed HEAD~1 Donc, les points sont à nouveau "Commit 1", et ne fait plus partie de l'index. Cependant, le fichier reste dans le répertoire de travail. Vous pouvez maintenant continuer et ajouter plus de contenu : main love.txt Allez-y, mettez en scène et commitez votre fichier : Bravo 👏🏻 Vous avez cet historique clair et agréable de "Commit 2.4" pointant vers "Commit 1". Nous avons maintenant un nouvel outil dans notre boîte à outils, 💪🏻 git reset Cet outil est super, super utile, et vous pouvez accomplir presque n'importe quoi avec lui. Ce n'est pas toujours l'outil le plus pratique à utiliser, mais il est capable de résoudre presque tous les scénarios d'historique de réécriture si vous l'utilisez avec précaution. Pour les débutants, je recommande d'utiliser uniquement presque chaque fois que vous souhaitez annuler dans Git. Une fois que vous vous sentez à l'aise avec, il est temps de passer à d'autres outils. git reset Scénario #2 Considérons un autre cas. Créez un nouveau fichier nommé ; mettre en scène et valider : new.txt Oops. En fait, c'est une erreur. Vous étiez sur , et je voulais que vous créiez ce commit sur une branche de fonctionnalité. Mon mauvais 😇 main Il y a deux outils les plus importants que je veux que vous retiriez de cet article. Le est . La première et de loin la plus importante consiste de l'état actuel par rapport à l'état dans lequel vous voulez être. second git reset à dresser un tableau blanc Pour ce scénario, l'état actuel et l'état souhaité ressemblent à ceci : Vous remarquerez trois changements : points à "Commit 3" (le bleu) dans l'état actuel, mais à "Commit 2.4" dans l'état souhaité. main La branche n'existe pas dans l'état actuel, mais elle existe et pointe vers "Commit 3" dans l'état souhaité. feature pointe sur dans l'état actuel et sur dans l'état souhaité. HEAD main feature Si vous pouvez dessiner ceci et que vous savez comment utiliser , vous pouvez certainement vous sortir de cette situation. git reset Encore une fois, est de respirer et de tirer cela. la chose la plus importante En observant le dessin ci-dessus, comment passe-t-on de l'état actuel à celui souhaité ? Il existe bien sûr plusieurs façons, mais je ne présenterai qu'une seule option pour chaque scénario. N'hésitez pas à jouer avec d'autres options également. Vous pouvez commencer par utiliser . Cela définirait pour pointer vers le commit précédent, "Commit 2.4": git reset --soft HEAD~1 main En jetant un coup d'œil au diagramme actuel vs souhaité, vous pouvez voir que vous avez besoin d'une nouvelle branche, n'est-ce pas ? Vous pouvez utiliser pour cela ou (qui fait la même chose): git switch -c feature git checkout -b feature Cette commande met également à jour pour pointer vers la nouvelle branche. HEAD Depuis que vous avez utilisé , vous n'avez pas modifié l'index, il a donc exactement l'état que vous souhaitez valider - comme c'est pratique ! Vous pouvez simplement vous engager sur la branche : git reset --soft feature Et vous êtes arrivé à l'état souhaité 🎉 Scénario #3 Prêt à appliquer vos connaissances à d'autres cas ? Ajoutez quelques modifications à et créez également un nouveau fichier appelé . Mettez-les en scène et engagez : love.txt cool.txt Oh, oups, en fait je voulais que vous créiez deux commits séparés, un avec chaque changement 🤦🏻 Vous voulez essayer celui-ci vous-même ? Vous pouvez annuler les étapes de validation et de préproduction : Suite à cette commande, l'index n'inclut plus ces deux modifications, mais elles sont toujours dans votre système de fichiers. Alors maintenant, si vous ne faites que mettre en scène , vous pouvez le valider séparément, puis faire de même pour : love.txt cool.txt sympa 😎 Scénario #4 Créez un nouveau fichier ( ) avec du texte et ajoutez du texte à . Mettez en scène les deux modifications et validez-les : new_file.txt love.txt Oups 🙈🙈 Donc cette fois, je voulais que ce soit sur une autre branche, mais pas une branche, plutôt une branche déjà existante. nouvelle Alors que peux-tu faire? Je vais vous donner un indice. La réponse est vraiment courte et vraiment facile. Que fait-on en premier ? Non, pas . Nous dessinons. C'est la première chose à faire, car cela rendrait tout le reste beaucoup plus facile. Voici donc l'état actuel : reset Et l'état souhaité ? Comment passer de l'état actuel à l'état souhaité, qu'est-ce qui serait le plus simple ? Donc, une façon serait d'utiliser comme vous l'avez fait auparavant, mais il y a une autre façon que j'aimerais que vous essayiez. git reset Tout d'abord, déplacez pour pointer vers la branche : HEAD existing Intuitivement, ce que vous voulez faire est de prendre les modifications introduites dans le commit bleu et d'appliquer ces modifications ("copier-coller") au-dessus de la branche . Et Git a un outil juste pour ça. existing Pour demander à Git de prendre les changements introduits entre ce commit et son commit parent et d'appliquer simplement ces changements sur la branche active, vous pouvez utiliser . Cette commande prend les changements introduits dans la révision spécifiée et les applique au commit actif. git cherry-pick Il crée également un nouvel objet commit et met à jour la branche active pour pointer vers ce nouvel objet. Dans l'exemple ci-dessus, j'ai spécifié l'identifiant SHA-1 du commit créé, mais vous pouvez également utiliser , car le commit dont nous appliquons les modifications est celui vers lequel pointe . git cherry-pick main main Mais nous ne voulons pas que ces changements existent sur la branche . n'a appliqué les modifications qu'à la branche . Comment pouvez-vous les supprimer de ? main git cherry-pick existing main Une façon serait de à , puis d'utiliser : switch main git reset --hard HEAD~1 Tu l'as fait! 💪🏻 Notez que calcule en fait la différence entre le commit spécifié et son parent, puis les applique au commit actif. Cela signifie que parfois, Git ne pourra pas appliquer ces modifications car vous pourriez avoir un conflit, mais c'est un sujet pour un autre article. git cherry-pick Notez également que vous pouvez demander à Git de les modifications introduites dans n'importe quel commit, pas seulement les commits référencés par une branche. cherry-pick Nous avons acquis un nouvel outil, nous avons donc ainsi que à notre actif. git reset git cherry-pick Scénario #5 Bon, alors un autre jour, un autre repo, un autre problème. Créez un commit : Et -le sur le serveur distant : push Euh, oups 😓… Je viens de remarquer quelque chose. Il y a une faute de frappe. J'ai écrit au lieu de . Oups. Alors quel est le gros problème maintenant ? J'ai ed, ce qui signifie que quelqu'un d'autre a peut-être déjà ces modifications. This is more tezt This is more text push pull Si je remplace ces modifications en utilisant , comme nous l'avons fait jusqu'à présent, nous aurons des historiques différents, et l'enfer pourrait se déchaîner. Vous pouvez réécrire votre propre copie du référentiel autant que vous le souhaitez jusqu'à ce que vous le . git reset push Une fois que vous le changement, vous devez être certain que personne d'autre n'a récupéré ces changements si vous allez réécrire l'histoire. push très Alternativement, vous pouvez utiliser un autre outil appelé . Cette commande prend le commit que vous lui fournissez et calcule le Diff à partir de son commit parent, tout comme , mais cette fois, il calcule les changements inverses. git revert git cherry-pick Donc, si dans le commit spécifié vous avez ajouté une ligne, l'inverse supprimerait la ligne, et vice versa. a créé un nouvel objet commit, ce qui signifie qu'il s'agit d'un ajout à l'historique. En utilisant , vous n'avez pas réécrit l'historique. Vous avez admis votre erreur passée, et ce commit est une reconnaissance que vous avez fait une erreur et maintenant vous l'avez corrigée. git revert git revert Certains diraient que c'est la voie la plus mature. Certains diront que ce n'est pas un historique aussi propre que si vous utilisiez pour réécrire le commit précédent. Mais c'est une façon d'éviter de réécrire l'histoire. git reset Vous pouvez maintenant corriger la faute de frappe et valider à nouveau : Votre boîte à outils est maintenant chargée avec un nouvel outil brillant, : revert Scénario #6 Travaillez, écrivez du code et ajoutez-le à . Mettez en scène ce changement et validez-le : love.txt J'ai fait la même chose sur ma machine et j'ai utilisé la touche fléchée vers le de mon clavier pour revenir aux commandes précédentes, puis j'ai appuyé sur et… Wow. Up Enter Oups. Ai-je simplement utilisé ? 😨 git reset --hard Que s'est-il passé ? Git a déplacé le pointeur vers , donc le dernier commit, avec tout mon travail, n'est pas accessible depuis l'historique actuel. Git a également désorganisé toutes les modifications de la zone de staging, puis a fait correspondre le répertoire de travail à l'état de la zone de staging. réellement HEAD~1 précieux C'est-à-dire que tout correspond à cet état où mon travail est… parti. Temps de panique. Paniquer. Mais, vraiment, y a-t-il une raison de paniquer ? Pas vraiment… Nous sommes des gens détendus. Qu'est-ce qu'on fait? Eh bien, intuitivement, le commit a-t-il vraiment, disparu ? Non pourquoi pas? Il existe toujours dans la base de données interne de Git. vraiment Si je savais seulement où c'est, je connaîtrais la valeur SHA-1 qui identifie ce commit, nous pourrions le restaurer. Je pourrais même annuler l'annulation et à ce commit. reset Donc, la seule chose dont j'ai vraiment besoin ici est le SHA-1 du commit "supprimé". Donc la question est, comment puis-je le trouver? serait-il utile ? git log Eh bien pas vraiment. irait à , qui pointe vers , qui pointe vers le commit parent du commit que nous recherchons. Ensuite, remonterait à travers la chaîne parente, qui n'inclut pas le commit avec mon précieux travail. git log HEAD main git log Heureusement, les personnes très intelligentes qui ont créé Git ont également créé un plan de sauvegarde pour nous, et cela s'appelle le . reflog Pendant que vous travaillez avec Git, chaque fois que vous modifiez , ce que vous pouvez faire en utilisant , mais aussi d'autres commandes comme ou , Git ajoute une entrée au . HEAD git reset git switch git checkout reflog Nous avons trouvé notre engagement ! C'est celui qui commence par . 0fb929e Nous pouvons également l'identifier par son "surnom" - . Ainsi, comme Git utilise pour accéder au premier parent de , et pour faire référence au deuxième parent de et ainsi de suite, Git utilise pour faire référence au premier parent reflog de , où pointait à l'étape précédente. HEAD@{1} HEAD~1 HEAD HEAD~2 HEAD HEAD@{1} HEAD HEAD On peut aussi demander à de nous montrer sa valeur : git rev-parse Une autre façon de voir le est d'utiliser , qui demande à de considérer réellement le : reflog git log -g git log reflog Nous voyons ci-dessus que le , tout comme , pointe vers , qui pointe vers « Commit 2 ». Mais le parent de cette entrée dans le pointe vers "Commit 3". reflog HEAD main reflog Donc, pour revenir à "Commit 3", vous pouvez simplement utiliser (ou la valeur SHA-1 de "Commit 3") : git reset --hard HEAD@{1} Et maintenant, si nous : git log Nous avons sauvé la journée ! 🎉👏🏻 Que se passerait-il si j'utilisais à nouveau cette commande ? Et exécuté ? Git définirait sur l'endroit où pointait avant la dernière , c'est-à-dire sur "Commit 2". On peut continuer toute la journée : git commit --reset HEAD@{1} HEAD HEAD reset En regardant maintenant notre boîte à outils, elle est remplie d'outils qui peuvent vous aider à résoudre de nombreux cas où les choses tournent mal dans Git : Avec ces outils, vous comprenez mieux maintenant le fonctionnement de Git. Il existe d'autres outils qui vous permettraient de réécrire spécifiquement l'historique, ), mais vous avez déjà beaucoup appris dans cet article. Dans les prochains articles, je plongerai également dans . git rebase git rebase L'outil le plus important, encore plus important que les cinq outils répertoriés dans cette boîte à outils, est de dresser un tableau blanc de la situation actuelle par rapport à celle souhaitée. Faites-moi confiance, cela rendra chaque situation moins intimidante et la solution plus claire. En savoir plus sur Git J'ai également donné une conférence en direct couvrant le contenu de ce message. Si vous préférez une vidéo (ou souhaitez la regarder en même temps que la lecture) — vous pouvez la trouver . ici En général, couvre de nombreux aspects de Git et de ses composants internes ; vous êtes les bienvenus (jeu de mots 😇) ma chaîne YouTube Vérifiez-le A propos de l'auteur est le CTO et co-fondateur de , un outil de développement qui aide les développeurs et leurs équipes à gérer les connaissances sur leur base de code avec une documentation interne à jour. Omer est le fondateur de Check Point Security Academy et était le responsable de la cybersécurité à l'ITC, une organisation éducative qui forme des professionnels talentueux pour développer des carrières dans la technologie. Omer Rosenbaum nager Omer est titulaire d'une maîtrise en linguistique de l'Université de Tel-Aviv et est le créateur du . Brève chaîne YouTube Publié pour la première fois ici