Suivre l'historique d'un fichier et la paternité de la ligne

• Séparez l’historique des fichiers de l’attribution de la ligne actuelle.
• Lisez l'auteur et le contributeur indépendamment.
• Inspectez les blâmes antérieurs sans vérifier les commits.
• Gardez les preuves d’attribution séparées de la confiance de sécurité.

Commencez là où la leçon 15 s'est terminée : main avec ignore commit, clean ; README.md est toujours le README original et index.html contient le pied de page de Leo de la leçon 11. La fonctionnalité publiée et la balise v0.1.0 sont inchangées.

La vidéo a été enregistrée avec Git 2.52.0 et GitTree 2.0 sur Ubuntu 24.04 : README.md a été enregistré dans l'application, le commit de Maya a été effectué de manière native en tant que préparation des coéquipiers, et les vues de l'historique et des reproches ont été ouvertes dans l'application ; les relectures de l'état avant et du blâme ont été exécutées dans le terminal. Rien n'a été exécuté sur macOS ou Windows, et Ubuntu est le seul système Linux enregistré. Le niveau Git source de GitTree est 2.39.0.

GitTree vous demande de vous connecter ; le plan gratuit couvre ensuite chaque étape ici. Aucun compte fournisseur, Pro/essai, identifiant API ou service Internet n'est nécessaire. Une origine locale nue n'est pas GitLab ou CI. Toutes les identités utilisent example.com ; n'exécutez jamais cette leçon dans une extraction de source.

Effectuez des mutations via GitTree ou le chemin natif à des entrées identiques, pas les deux consécutivement. Une vérification en lecture seule peut suivre l'une ou l'autre. Toute préparation décrite comme un travail de terminal est étiquetée préparation native, jamais une fonctionnalité d'application inventée.

L'historique des fichiers répertorie les validations sélectionnées par des règles de chemin/historique ; blâme attribue les lignes actuelles aux commits qui les ont introduites en dernier sous les options sélectionnées. Il n’existe pas non plus d’explication sociale complète sur qui a conçu une fonctionnalité.

L’auteur et le contributeur peuvent différer. Ce luminaire utilise délibérément la même identité fictive Maya pour les deux dans son engagement et pour Leo dans le sien. Les noms/e-mails sont des métadonnées, et non une preuve de propriété ou un code de confiance.

Ignorer les espaces et suivre les lignes déplacées peut modifier les réponses d'attribution sans modifier les octets ou l'historique du fichier. Prenez du recul par rapport à un commit blâmé sélectionné pour inspecter son prédécesseur ; la sélection n’est pas la caisse.

Le commit explicite README avance uniquement sur le principal. Les sélections et bascules ultérieures d'historique/de blâme modifient l'état d'affichage de l'application ; aucune mutation d'index, de travail, de branche locale ou de serveur ne se produit.

Sur la sauvegarde principale d'origine, complétez README_MAYA ci-dessous. La préparation native utilise git -c user.name/user.email uniquement pour cette validation, pas une configuration globale ou un remplacement trompeur réservé à l'auteur uniquement. Capturez les métadonnées réelles résultantes.

Enregistrez uniquement à la phase nommée ci-dessous. Ce sont des corps UTF-8/LF complets avec une nouvelle ligne finale ; ne collez jamais les clôtures Markdown. Les fichiers exécutables inchangés héritent de l'entrée nommée. Les versions dans des variantes distinctes ne doivent pas écraser l'original.

README.md — README_MAYA

# GitTree Features

A fictional landing page used to learn Git and GitTree.

All people and addresses in this repository are fictional.
No form submits information to a server.

Review changes deliberately and preserve useful work.

Palette : Commande+Maj+P (Ctrl+Maj+P sur Ubuntu) ; tapez la commande exactement nommée et sélectionnez-la. Les actions de référence nommée utilisent le menu contextuel de cette ligne, et non un raccourci de palette sans argument.

1. Afficher les fichiers ; ouvrez README.md et enregistrez le README_MAYA complet. Vérifiez la ligne de révision ajoutée.
2. Validez l'ajout de manière native avec l'identité fictive explicite ci-dessous ; étiquetez cette préparation de coéquipier. Ne prétendez pas que l'application a réécrit les auteurs existants.
3. Avec README.md ouvert via Show Files puis README.md, la vue du fichier comporte quatre onglets : File, Changes, Blame et History. Choisissez History : il répertorie uniquement les commits de ce fichier, Maya en haut. Sélectionnez le commit de Maya.
4. Inspectez la différence de chemin et les métadonnées ; utilisez la liste d'historique ArrowUp/ArrowDown pour inspecter une autre révision sans extraction.
5. Choisissez Blame sur README.md. L'en-tête indique « Blame @ », un court identifiant de validation, et les lignes sont regroupées par validation ; cliquez sur la ligne ajoutée. Attendez-vous au sujet et à l'identité réels de Maya, et non à un SHA fixe inventé.
6. Ouvrez index.html et choisissez Blame ; inspectez l'attribution Lion de la ligne de pied de page de manière indépendante.
7. Ignore whitespace changes et Follow moved lines sont des options d'affichage de la vue des reproches. Cliquez sur le groupe d'un commit, choisissez Blame before this commit pour voir le blâme tel qu'il était, puis Back to the later blame.
8. Back to Graph ; Jump to HEAD (Ctrl+Maj+H sur Ubuntu). Vérifiez que la pointe principale d'origine est propre et que la pointe réelle n'a pas changé après inspection.

Pour chaque commit ordinaire : le résumé est le sujet indiqué ; Description vide ; Modifier la validation précédente, ignorer les crochets, ajouter une signature par un auteur différent, appuyer après la validation et autoriser la validation vide ; pas de co-auteurs. Mettez en scène uniquement les fichiers nommés, puis validez les modifications dans N fichiers une fois (fichier pour un) ou Commande+Entrée comme alternative. Attendez le vrai résultat. Une leçon qui modifie explicitement ne change que cette option indiquée.

Après avoir enregistré README_MAYA :

git add -- README.md
git -c user.name="Maya Chen" -c user.email=maya@example.com commit --quiet -m "docs: explain deliberate review"
git log -1 --format='%an <%ae>%n%cn <%ce>' -- README.md
git blame --line-porcelain -- README.md
git blame --line-porcelain -- index.html
git status --short

La validation réussit. La requête d'auteur réelle comprend :

Maya Chen <maya@example.com>
Maya Chen <maya@example.com>

La sortie complète du blâme inclut les SHA/temps variables réels et les enregistrements par ligne. Pour la nouvelle ligne README, les champs d'enregistrement vérifiés incluent l'auteur Maya Chen, l'adresse-mail de l'auteur <maya@example.com>, les documents de synthèse : expliquez la révision délibérée, puis un préfixe de tabulation "Review" modifie délibérément et préserve le travail utile. L'enregistrement de pied de page identifie Leo Okafor et son engagement de rappel ; cela doit être mesuré à partir de l'arbre réel, et non inventé comme un auteur uniforme pour chaque ligne HTML. Le statut final est vide.

Alternatives en lecture seule :

git log --follow --format='%s' -- README.md
git blame -w -- README.md
git blame -M -- README.md

Ces options répondent à différentes questions d'attribution ; la disposition de sortie est spécifique à la version Git et est capturée, et non remplacée par l'extrait du champ porcelaine.

Where you end: Le seul ajout au fichier README de Maya est validé en tant que documentation : expliquez la révision délibérée sur main. Blame attribue cette nouvelle ligne à Maya et ce pied de page à Leo ; l’inspection laisse la TÊTE/l’index/le travail propre et inchangé.

• Appeler le blâme un score de culpabilité.
• En supposant que l'auteur est toujours égal au contributeur.
• Extraire un commit simplement pour inspecter sa ligne.

Effacez les options d'affichage ou revenez au blâme ultérieur/Sauter à HEAD. La navigation n'a pas besoin d'être réinitialisée. Si l'attribution diffère, inspectez les paramètres réels de chemin, de révision et d'espace/déplacement avant de modifier l'historique.

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

   Le blâme répond à quoi ?

   Choisissez une réponse.

   Dernière introduction du commit pour une ligne sous options

   À qui appartient chaque idée

   Qui mérite la critique

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

   Question 2 de 6

   Quelles distinctions comptent ?

   Choisissez chaque réponse qui s'applique.

   Chemin et révision sélectionnée

   Le nom prouve la sécurité

   Auteur contre auteur

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

   Question 3 de 6Obligatoire

   Sélectionnez l'ancienne révision du fichier : HEAD ?

   Choisissez une réponse.

   Supprimé

   Se déplace automatiquement

   Inchangé

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

   Question 4 de 6Obligatoire

   Modifier la requête pour ignorer les espaces : octets ?

   Choisissez une réponse.

   Inchangé

   Reformaté

   L'histoire réécrite

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

   Question 5 de 6

   Résultat de blâme différent : premier contrôle ?

   Choisissez une réponse.

   Chemin, révision et options

   Forcer la poussée

   Réinitialiser le principal

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

   Question 6 de 6Obligatoire

   Qu'est-ce qui prouve le résultat ?

   Choisissez chaque réponse qui s'applique.

   Pointe propre inchangée après inspection

   Avatar d'un auteur

   Enregistrements réels des lignées Maya/Léo

   Vérifier la réponse

Prouvez que la ligne de révision README appartient à Maya et le pied de page à Leo en utilisant de véritables enregistrements en porcelaine. Activez -w dans une requête distincte en lecture seule et expliquez pourquoi l'attribution inchangée ici ne prouve pas que l'option n'a jamais d'importance.

• L’histoire et le blâme répondent à des questions différentes.
• Les métadonnées ne sont pas une question de confiance.
• L’inspection ne bouge pas la TÊTE.

• Ignorer les fichiers et nettoyer le travail non suivi en toute sécurité (leçon 15)
• Lire l'historique sans bouger la TÊTE (leçon 8)
• Télécharger GitTree

Blâme — نسب الأسطر; historique des fichiers — سجل الملف; auteur — المؤلف; committer — المُودِع.