Aucun fichier indexé. Utilisez git add pour indexer vos changements.
📊 Graphe de commitsbranche actuellemain
💀 Le piège du resetIntermediate0/5
📖 Concepts
git reset --hardDéplace le pointeur de branche ET réinitialise la staging area ET le working directory. Les changements non committés sont perdus pour toujours. Les commits peuvent être récupérés via le reflog, mais le travail non indexé et non suivi ne peut pas l'être.
Reflog ≠ bouton undoLe reflog ne suit que les commits et les mouvements de HEAD. Si vous aviez des modifications non indexées, des fichiers non suivis, ou des changements indexés mais non committés, ils NE sont PAS dans le reflog. Ce que vous n'avez pas committé, vous pouvez le perdre.
📖 Histoire
Vous construisez une nouvelle feature. Vous faites quelques éditions, vous les indexez, vous êtes content. Puis vous décidez de tout jeter et de repartir.
Un reset propre semble être le bon choix. Et ça l'est — jusqu'à ce que ça ne le soit plus.
C'est l'histoire de la différence entre « je peux annuler ça » et « j'aurais dû committer d'abord. »
Modifiez app.py — remplacez "v1" par "v2" dans l'éditeur, puis indexez-le.
Ouvrez app.py dans l'éditeur (cliquez dans l'arborescence), remplacez v1 par v2, puis lancez git add app.py pour indexer le changement.
● Modifiez app.py — remplacez "v1" par "v2" dans l'éditeur, puis indexez-le.
○ Créez notes.txt avec le contenu "my notes" et indexez-le aussi.
○ Vous décidez que l'approche est mauvaise. Jetez les changements indexés et repartez à zéro.
○ Regardez le reflog — voyez ce qui s'est passé.
○ Vérifiez git status pour voir l'ensemble.
Terminal
📘 Starting tutorial: The Reset Trap
Learn the hard way why --hard is dangerous and reflog is your safety net
Step 1: Modify app.py — change "v1" to "v2" in the editor, then stage it.