Lire l'historique sans bouger la TÊTE

• Distinguer HEAD, un commit, un auteur et un committer sélectionnés.
• Suivez les parents et les ancêtres premiers parents.
• Lisez les ensembles de journaux à deux/trois points sans les confondre avec les points de terminaison de différence.
• Comparez deux commits réels dans GitTree sans réécrire l'historique.

Vous commencez là où la leçon 7 s'est terminée : main a trois commits des leçons 5 à 7. Seul le rayon CSS reste modifié : HEAD et l'index contiennent CSS-02-INDEX, le fichier de travail CSS-02-WORKING. Pas de télécommande. La vidéo a été enregistrée avec Git 2.52.0 et GitTree 2.0 sur Ubuntu 24.04 : les deux validations, le document, l'inspection du graphique, la recherche, Jump to HEAD et Compare References ont été effectués dans l'application, et les vérifications du terminal ont été exécutées par rapport à ce que l'application a créé, de sorte que les identifiants de validation affichés sont ceux que l'application a comparés. Le cas des branches divergentes est un diagramme : aucune branche de fonctionnalité n’a été créée. Rien n'a été exécuté sur macOS ou Windows, et Ubuntu est le seul système Linux enregistré. La source minimale de GitTree est Git 2.39.0 ; une fois connecté, l'inspection locale et les engagements sont sur le plan gratuit.

Un commit enregistre une arborescence, des métadonnées et des identifiants parents. Une branche nomme un commit ; HEAD nomme généralement la branche actuelle. Cliquer sur une autre ligne du graphique modifie le selection de l'application, et non HEAD, les fichiers de branche ou de disque. L'auteur enregistre qui a écrit l'œuvre ; le committer enregistre qui a enregistré ce commit. Il se trouve qu’il s’agit ici de la même identité fictive.

Pour une chaîne linéaire, HEAD~1 suit une arête du premier parent ; HEAD~2 suit deux. HEAD^1 est le premier parent ; HEAD^2 signifie le second parent of one commit, et non « deux commits en retour ». Un commit sans fusion n’a pas de deuxième parent.

git log A..B signifie accessible depuis B à l'exclusion de accessible depuis A. git log A...B signifie différence symétrique d'accessibilité. git diff A B compare les arborescences de points de terminaison, tandis que git diff A...B compare la base de fusion (A, B) à B. Un journal à trois points et un différentiel à trois points ne posent pas la même question. Sur cette histoire linéaire, certains résultats concordent ; ne généralisons pas cette coïncidence à des branches divergentes. Notation de révision, sémantique des différences.

La lecture/sélection/recherche ne modifie aucun index, octets de travail ou références. Les deux commits explicites de cette leçon déplacent le principal local : le rayon en premier, la documentation en second. Aucun changement à distance.

Validez d’abord la modification du rayon existant comme indiqué ci-dessous. Créez ensuite docs/history.md avec ce corps UTF-8/LF complet ; son élément final décrit le commit qui contiendra le document, et non un SHA inventé.

# GitTree Features history

The first-parent chain on main, oldest first:

1. feat: add the GitTree Features hero
2. feat: add styling and local project checks
3. feat: refine the hero and card spacing
4. style: finish the card radius change
5. docs: record logs-and-revisions practice

After this document is committed, HEAD names item 5.
HEAD~1 names item 4; HEAD~2 names item 3.
Selecting a graph row does not move HEAD.
These labels are descriptions, not fabricated commit SHAs.

All identities in this project are fictional.

N’ajoutez pas le cahier d’exercices facultatif ni les validations de nettoyage supplémentaires à cette chaîne de cinq validations.

1. Palette Show Working Changes (Commande/Ctrl+Maj+P pour ouvrir la palette). Cliquez sur styles.css sous Unstaged Files. Confirmez qu'il ne reste que le rayon 0,5rem → 0,75rem ; ne répétez pas le changement de largeur précédent.
2. Choisissez son action de ligne Stage File, entrez Résumé style: finish the card radius change, désactivez les options ordinaires, puis Commit Changes to 1 File (ou Commande/Ctrl+Entrée une fois). Vérifiez quatre commits et nettoyez le statut de suivi.
3. Palette New File… → Path from the project folder = docs/history.md → Create. Collez le document complet et Save. Back to Graph → Show Working Changes → Fichier de scène pour docs/history.md.
4. Résumé docs: record logs-and-revisions practice ; valider un fichier. La chaîne attendue compte désormais cinq commits.
5. Cliquez sur la ligne du héros racine. Inspectez son véritable SHA, son sujet, son auteur/commissaire et son statut parent root commit dans les détails de la validation. Cliquez sur la dernière ligne ; comparer sa relation parent. N'invoquez pas Check Out This Commit simplement pour le lire.
6. Dans les détails du commit, activez View all files pour distinguer l'ensemble de l'arborescence du commit des seuls chemins modifiés ; inspecter le document lors de sa révision enregistrée. Cela ne modifie pas le fichier de travail.
7. Renvoie Back to Graph ; utilisez la palette Search Loaded History ou Commande/Ctrl+F while the graph is active, tapez radius et inspectez l'historique chargé correspondant. Dans un éditeur, le même accord trouve le texte de l'éditeur. Effacez ensuite la recherche. Une recherche dans l'historique chargé n'est pas une requête dans l'historique à l'échelle du serveur.
8. La palette Jump to HEAD, Commande/Ctrl+Maj+H, localise l'astuce actuelle. La sélection/recherche peut se déplacer tandis que le git symbolic-ref --short HEAD natif rapporte toujours le principal.
9. Utilisez git rev-parse HEAD~2 natif pour obtenir son ID de validation real ; aucun cours fixe SHA n’est fourni. La palette Compare References… (repo.compareRefs) s'ouvre Compare References. Dans Old side, collez cet ID mesuré et sélectionnez son option de validation ; dans New side, choisissez HEAD. Le sélecteur accepte un ID de validation, et non une promesse que les expressions de révision arbitraires y seront analysées.
10. Sous What to compare, choisissez The two endpoints puis Compare. Attendez-vous à des différences docs/history.md et styles.css pour cette chaîne. Rouvrez/modifiez la comparaison et choisissez Changes since the merge base avec les mêmes côtés : l'ascendance linéaire fait coïncider le résultat du point final ici. Ne déduisez pas le comportement du journal symétrique à partir de cette vue. Cancel se ferme sans modifier l'historique.

Alternative de mutation native, uniquement avant le succès de l'application correspondante :

git add -- styles.css
git commit --quiet -m "style: finish the card radius change"

Tous deux réussirent en silence. Après avoir enregistré le document complet :

git add -- docs/history.md
git commit --quiet -m "docs: record logs-and-revisions practice"
git log --reverse --format=%s

Chaîne complète observée :

feat: add the GitTree Features hero
feat: add styling and local project checks
feat: refine the hero and card spacing
style: finish the card radius change
docs: record logs-and-revisions practice

Inspecter l'ensemble par rapport à l'arbre :

git log --format=%s HEAD~2..HEAD
git log --format=%s HEAD~2...HEAD

Chaque requête imprimée séparément :

docs: record logs-and-revisions practice
style: finish the card radius change

Ils coïncident uniquement parce que le point de terminaison le plus ancien est ici un ancêtre.

git diff --name-only HEAD~2 HEAD
git rev-list --count HEAD
git symbolic-ref --short HEAD

Sorties dans l'ordre :

docs/history.md
styles.css
5
main

Les deux fichiers nommés sont des différences d'arborescence, et non les identités des deux validations renvoyées par le journal.

git rev-parse --verify --quiet HEAD^2

Aucun stdout/stderr observé et sortie 1 : le dernier commit n'est pas une fusion. Utilisez plutôt HEAD~2 pour deux étapes du premier parent. Pour identifier un véritable identifiant de comparaison :

git rev-parse HEAD~2

Lisez sa sortie réelle pendant la répétition ; un SHA mesuré change avec les métadonnées de validation et ne doit pas être copié à partir d’une étiquette de modèle.

À la fin de cette leçon : cinq commits sur main dans l'ordre documenté ; travail suivi/index propre, pas de télécommande ou opération en cours. CSS a désormais un rayon de 0,75rem et docs/history.md est validé. La lecture d'une ligne de graphique précédente n'a pas détaché HEAD.

• Traiter la ligne sélectionnée comme une validation extraite : inspectez HEAD indépendamment.
• Lire ^2 comme ~2 : deuxième parent contre deux bords du premier parent.
• Application de la signification du journal symétrique au diff à trois points : le diff est directionnel de la base de fusion vers la droite.
• En supposant que la recherche graphique couvre l'historique déchargé/non récupéré.

Une révision manquante peut signifier une ascendance insuffisante, une faute de frappe ou une limite superficielle, et non une corruption. Vérifiez la chaîne et le référentiel sélectionné. Effacer les filtres d'application avant de conclure un commit a disparu. Ne récupérez pas auprès d'un fournisseur arbitraire, ne réinitialisez pas ou ne procédez pas à un paiement simplement pour réparer une sélection. Si un document existe déjà, inspectez son contenu avant d'appliquer cette étape de création d'un nouveau fichier.

Répondez à chaque question, puis lisez pourquoi. Les questions marquées « Obligatoire » comptent pour terminer la leçon.

1. Question 1 de 6

   Question 1 de 6

   Cliquer sur une ancienne ligne de graphique fait quoi ici ?

   Choisissez une réponse.

   Modifie la sélection de l'application

   Supprime les commits les plus récents

   Détache la TÊTE

   Vérifier la réponse
2. Question 2 de 6

   Question 2 de 6

   Quelles déclarations sont correctes sur cette chaîne linéaire à cinq validations ?

   Choisissez chaque réponse qui s'applique.

   HEAD^2 signifie le deuxième parent

   ^2 est toujours égal à ~2

   HEAD~2 suit deux arêtes premières parents

   Vérifier la réponse
3. Question 3 de 6

   Question 3 de 6Obligatoire

   Quels sujets se trouvent dans HEAD~2..HEAD après la validation de history.md ?

   Choisissez une réponse.

   Uniquement les fichiers nommés HEAD

   Les cinq engagements

   Document historique et rayon

   Vérifier la réponse
4. Question 4 de 6

   Question 4 de 6Obligatoire

   Le principal est H5 ; la caractéristique F descend de H3. Quelle est la fonctionnalité principale... dans git log ?

   Choisissez une réponse.

   H4, H5 et F

   Seulement F

   Seulement H3

   Vérifier la réponse
5. Question 5 de 6

   Question 5 de 6

   Est-ce que git diff A...B signifie l'ensemble de journaux symétriques ?

   Choisissez une réponse.

   Non, fusionner la base → arbre B

   Ça bouge toujours la TÊTE

   Oui, des opérateurs identiques partout

   Vérifier la réponse
6. Question 6 de 6

   Question 6 de 6Obligatoire

   Quelles observations prouvent le point de contrôle terminé ?

   Choisissez chaque réponse qui s'applique.

   HEAD toujours principal après sélection

   Rayon sale toujours en attente

   Cinq sujets précis dans l'ordre

   Vérifier la réponse

Sélectionnez une ligne plus ancienne et prouvez que HEAD reste principal. Expliquez pourquoi deux entrées de journal peuvent correspondre à des différences dans seulement deux chemins. Entrée modifiée : pour une branche distincte avec un commit de H3 alors que main est à H5, prédire main..feature contient uniquement cette validation de fonctionnalité, mais main...feature inclut également H4/H5. Ne créez pas cette branche dans le point de contrôle canonique ; utilisez une copie jetable.

• Selection et HEAD ont des propriétaires différents.
• La notation parent et les ensembles de révisions décrivent l'ascendance, pas les modifications de fichiers.
• Comparez les points finaux réellement résolus et étiquetez clairement la question.

• Commit le morceau sélectionné, pas le fichier entier (leçon 7)
• Mettez en scène l'instantané prévu et effectuez votre premier commit (leçon 5)
• Télécharger GitTree

S'engager — إيداع; parent — إيداع أب; réf — مرجع; révision — مراجعة; gamme — نطاق; fusionner la base — أساس الدمج; auteur — المؤلف; committer — المُودِع.