Cachez le travail et reprenez-le en toute sécurité

• Choisissez ce qui se trouve dans une réserve : modifications suivies, fichiers non suivis ou uniquement ce qui est mis en scène.
• Expliquez pourquoi Apply conserve la réserve et Pop ne la supprime qu'après une application propre.
• Vérifiez que la modification et la note sont revenues et que la branche n'a pas bougé.
• Récupérez d'un conflit Pop sans perdre la réserve.

Vous êtes sur private/stash-hint, une branche du résultat de la leçon 18, avec un commit qui ajoute docs/stash-conflict.md ("Utiliser une adresse fictive."). Dans votre arborescence de travail, vous avez une modification inachevée de ce fichier et un nouveau fichier, docs/signup-hint.md, que Git n'a jamais vu. Quelqu'un vous demande de passer à autre chose, vous souhaitez donc mettre les deux de côté, sans vous engager dans un travail à moitié fait.

Tout est local et sur le forfait gratuit (GitTree vous demande de vous connecter) : pas de compte d'hébergement, pas de fournisseur, pas d'Internet. Chaque identité est fictive (exemple.com). N'exécutez jamais cette leçon dans un projet réel.

Apportez les modifications dans GitTree ou avec les commandes Git natives, pas les deux dans la même copie. La lecture du résultat est toujours sûre. Les étiquettes de menu proviennent des propres chaînes de GitTree 2.0 et les commandes natives ont été exécutées avec Git 2.43 dans des copies jetables. Les étapes GitTree n'ont pas été exécutées le macOS, Windows ou Linux.

Stash stocke vos modifications locales en tant qu'objets Git, puis nettoie l'arborescence de travail jusqu'au dernier commit. Il s'agit d'un outil d'interruption de courte durée, pas d'une sauvegarde ni d'un remplacement pour une branche que vous souhaitez conserver.

Une réserve contient les modifications suivies par défaut. Les fichiers non suivis sont laissés sur place, sauf si vous les demandez, ce que Git fait avec --include-untracked. La boîte de dialogue Stash Changes… de GitTree est Include untracked files activée lorsqu'elle s'ouvre ; vérifie quand même. Les fichiers ignorés appartiennent à une catégorie différente et ne sont pas stockés ici. Only staged changes cache exactement ce qui se trouve dans l'index et Keep staged changes in place too laisse l'index tel qu'il était.

Apply Stash remet les modifications et conserve la réserve dans la liste. Pop Stash l'applique et supprime l'entrée uniquement si l'application était propre. En cas de conflit, la réserve reste et vous résolvez le conflit dans l'arborescence de travail. Les commandes Apply et Pop de GitTree ne restaurent pas l'état intermédiaire ; git stash apply --index fait cela, mais l'application ne l'utilise pas, donc les modifications préparées reviennent sans préparation.

Le stockage et l'application ne déplacent jamais la branche et ne font jamais de validation. Seuls l'arborescence de travail et une entrée de cache changent.

Commencez à partir d'une copie ordinaire distincte du projet telle que la leçon 18 l'a laissée et laissez votre gittree-features original intact. Créez la branche, enregistrez DOC_STASH_BASE et validez-la. Enregistrez ensuite DOC_STASH_WORK sur le même fichier et DOC_HINT en tant que nouveau fichier, sans mise en scène non plus. DOC_STASH_OTHER et STASH_RESOLVED sont utilisés uniquement dans la copie de conflit distincte.

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.

docs/stash-conflict.md — DOC_STASH_BASE

Use a fictional address.

docs/stash-conflict.md — DOC_STASH_WORK

Use a complete fictional email address.

docs/signup-hint.md — DOC_HINT

Unfinished signup hint: use fictional data only.

docs/stash-conflict.md — DOC_STASH_OTHER

Do not send the address anywhere.

docs/stash-conflict.md — STASH_RESOLVED

Use a complete fictional email address. Nothing is sent.

Ouvrez la palette avec Commande+Maj+P (Ctrl+Maj+P sur Ubuntu). Les entrées de cache sont répertoriées dans le panneau de gauche sous Stashes ; les actions d'une réserve se trouvent dans son menu contextuel.

1. Construisez la branche et les deux modifications non planifiées comme le montre la section suivante. Lisez la liste des modifications : docs/stash-conflict.md est modifié et docs/signup-hint.md est nouveau.
2. Ouvrez la palette et exécutez Stash Changes…. Dans la boîte de dialogue, définissez Message sur signup hint rehearsal. Only staged changes est éteint. Include untracked files est activé. Keep staged changes in place too est éteint. Choisissez Stash.
3. Attendez le message « Saché vos modifications ». La liste des modifications est vide, la note a disparu du disque et la cache apparaît sous Stashes.
4. Survolez la ligne de cache : son info-bulle indique "Inclut les fichiers non suivis". Faites un clic droit dessus et choisissez Show Stash : le graphique sélectionne la réserve et le panneau de droite répertorie ses modifications suivies, docs/stash-conflict.md. La note non suivie est conservée dans une partie distincte de la réserve.
5. Cliquez à nouveau dessus avec le bouton droit et choisissez Apply Stash. L'avis indique "Appliqué la réserve ; elle est toujours dans la liste."
6. Vérifiez le résultat : docs/stash-conflict.md est à nouveau modifié, docs/signup-hint.md est de retour sous forme de fichier non suivi, la pointe de branche est la même validation et la cachette est toujours répertoriée.
7. Separate conflict copy. Dans une deuxième copie, après le stockage, validez DOC_STASH_OTHER dans le même fichier. Cliquez avec le bouton droit sur la réserve et choisissez Pop Stash. L'avertissement indique "Le cache est en conflit avec vos modifications : résolvez les conflits. Le cache est conservé."
8. Le fichier en conflit est répertorié avec Conflicted. Ouvrez-le, écrivez STASH_RESOLVED dans la sortie et choisissez Save and Mark Resolved. La cachette est toujours là. Lorsque vous êtes sûr que le travail est sécurisé, cliquez dessus avec le bouton droit et choisissez Delete Stash… ; la boîte de dialogue indique qu'il est supprimé de la liste et conservé dans les instantanés de récupération. L'annulation de GitTree ne restaure pas encore une réserve supprimée (leçon 30), alors considérez la suppression comme définitive.

Pour chaque commit ordinaire du cours : Summary est le sujet indiqué, Description est vide et les options Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit et Allow Empty Commit restent désactivées.

Dans une copie séparée du résultat de la leçon 18 :

git switch --create private/stash-hint

Enregistrez DOC_STASH_BASE sous docs/stash-conflict.md, puis :

git add -- docs/stash-conflict.md
git commit --quiet -m "docs: establish the stash conflict baseline"

Enregistrez DOC_STASH_WORK sur docs/stash-conflict.md et DOC_HINT sous docs/signup-hint.md, sans préparation. Ensuite, rangez les deux :

git stash push --include-untracked --message "signup hint rehearsal"
git status --short
git stash list --format=%s

On private/stash-hint: signup hint rehearsal

Le statut n'imprime rien : l'arborescence est propre. Conservez une copie intacte de cet état pour le conflit, puis appliquez :

git stash apply 'stash@{0}'
git status --short
git stash list --format=%s
git rev-parse HEAD

 M docs/stash-conflict.md
?? docs/signup-hint.md
On private/stash-hint: signup hint rehearsal

Les deux corps sont de retour, la cachette est toujours répertoriée et HEAD est le commit dont il s'agissait. Sans --include-untracked, le même push laisse docs/signup-hint.md sur le disque et stocke uniquement la modification.

Dans la copie séparée, enregistrez DOC_STASH_OTHER et validez-le, puis affichez :

git add -- docs/stash-conflict.md
git commit --quiet -m "docs: change the stash target"
git stash pop 'stash@{0}'
git ls-files --unmerged
git stash list --format=%s

Pop se termine avec 1 et affiche "CONFLIT (contenu)" et "L'entrée de cache est conservée au cas où vous en auriez à nouveau besoin." Trois entrées non fusionnées sont répertoriées, le fichier contient des marqueurs de conflit, docs/signup-hint.md est restauré et la cache est toujours répertoriée. Il n'y a pas de fusion ou de rebase pour continuer : enregistrez STASH_RESOLVED et exécutez git add -- docs/stash-conflict.md. Pour garer le travail sur sa propre branche, git stash branch rescue-hint 'stash@{0}' crée la branche au niveau de la validation où le cache a été créé, l'applique et supprime le cache seulement ensuite.

Where you end: dans la première copie, l'arborescence a à nouveau la modification et la note, HEAD n'a pas bougé et la réserve est toujours répertoriée. Dans la copie du conflit, Pop a signalé le conflit, la cachette a survécu et votre résolution est mise en scène. Aucune validation n'a été effectuée par aucune commande stash et rien n'a été poussé.

• Oublier que les fichiers non suivis ne sont pas cachés sauf si vous les incluez.
• En supposant que Pop ait supprimé la cachette après un conflit. Ce n’est pas le cas.
• Appliquer deux fois alors que la première application a déjà fonctionné, puis s'interroger sur les modifications en double.
• Utiliser une réserve comme magasin à long terme. Nommez le travail utile avec une branche.

Après un conflit Pop, laissez le cache en place, résolvez le fichier et vérifiez le résultat avant de supprimer quoi que ce soit. Si vous avez postulé dans la mauvaise branche, supprimez ce travail seulement après avoir confirmé que la réserve le contient toujours. Create Branch from Stash… donne au cache sa propre branche au niveau du commit où il a été créé.

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

   Que fait Pop Stash que Apply Stash ne fait pas ?

   Choisissez une réponse.

   Il supprime l'entrée de cache, mais uniquement lorsque l'application était propre.

   Il restaure également l'état mis en scène.

   Il valide les modifications cachées.

   Il déplace la branche vers le commit où le cache a été créé.

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

   Question 2 de 6

   Vous exécutez Stash Changes… avec l'option Inclure les fichiers non suivis. Lesquelles de ces affirmations sont vraies ?

   Choisissez chaque réponse qui s'applique.

   Les fichiers ignorés sont également cachés.

   La nouvelle note inédite entre également dans la réserve.

   L'arborescence de travail remonte au dernier commit.

   La modification du fichier suivi est placée dans la cachette.

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

   Question 3 de 6Obligatoire

   Après le cache, vous choisissez Appliquer le cache dessus. Que vois-tu ?

   Choisissez une réponse.

   Seule la modification est de retour ; la note reste dans la cachette.

   Un nouveau commit contient les modifications restaurées.

   La modification est de retour et la cachette a disparu.

   La modification et la note sont de retour, la pointe de la branche est inchangée et la cachette est toujours répertoriée.

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

   Question 4 de 6

   Modifiez l'entrée : dans une copie, désactivez Inclure les fichiers non suivis avant de les cacher. Qu'arrive-t-il à docs/signup-hint.md ?

   Choisissez une réponse.

   Il reste sur le disque en tant que fichier non suivi et la cachette ne contient que la modification.

   Il est caché de toute façon.

   Git le supprime.

   La cachette est refusée.

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

   Question 5 de 6Obligatoire

   Dans la copie des conflits, Pop Stash prévient : "Le cache est en conflit avec vos modifications : résolvez les conflits. Le cache est conservé." Vous craignez que le travail soit terminé. Qu'est-ce qui est vrai et que faites-vous ?

   Choisissez une réponse.

   Utilisez une réinitialisation matérielle pour recommencer.

   La cachette est toujours répertoriée. Résolvez et marquez le fichier comme résolu, vérifiez le résultat et supprimez la cache uniquement lorsque vous en êtes sûr.

   Exécutez à nouveau Pop immédiatement.

   Supprimez la cachette maintenant pour la nettoyer.

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

   Question 6 de 6Obligatoire

   Après Appliquer Stash dans la première copie, quelles relectures montrent que cela a fonctionné comme le dit la leçon ?

   Choisissez chaque réponse qui s'applique.

   git stash list --format=%s affiche toujours "Sur privé/indice de cache : répétition de l'indice d'inscription".

   git rev-parse HEAD est égal à l'ID que vous avez noté avant de le cacher.

   git status --short affiche la modification de docs/stash-conflict.md et docs/signup-hint.md comme non suivie.

   git ls-files --unmerged répertorie trois entrées.

   Vérifier la réponse

Prouvez que l'arborescence était propre après la cachette, qu'Apply a restauré les deux fichiers et que la cachette est toujours répertoriée. Prédisez ce qui différerait si Include untracked files était désactivé. Dans la copie conflictuelle, prouvez que la cachette a survécu au Pop.

• Choisissez volontairement les options de cache.
• Appliquer conserve l'entrée.
• Un Pop conflictuel le garde aussi.

• Mettez en scène l'instantané prévu et effectuez votre premier commit (leçon 5)
• Résoudre les conflits de fusion et de rebase (leçon 23)
• Télécharger GitTree

Cachette — مخبأ; postuler — تطبيق; pop — تطبيق وحذف; non suivi — غير متتبَّع.