1. Scénario de test 1 :
Supposons que index.html soit déjà dans le référentiel de code. Maintenant, vous modifiez la page index.html, puis ajoutez pour stocker temporairement la page index.html, puis continuez à modifier l'index. .html, puis git stash, cette fois l'entrepôt de code est propre, les modifications sont temporairement stockées, puis exécutez git stash pop pour restaurer les modifications. À ce moment, on constate que les modifications dans l'espace de travail sont restaurées, mais les modifications dans la zone de transit sont perdues. C'est-à-dire que git status a constaté qu'aucune modification n'avait été effectuée et que les modifications précédemment effectuées avaient été supprimées, mais que les modifications dans l'espace de travail étaient complètement conservées.
2. Scénario de test deux :
Ajoutez maintenant la page test01.html, git status montre que test01.html n'est pas suivi par git, puis modifiez le fichier index.html à ce moment, git stash trouve cela. le fichier index.html est temporairement enregistré, mais le fichier test01.html n'est pas temporairement enregistré. Autrement dit, git status ne stocke pas temporairement les fichiers qui ne sont pas suivis par git.
3. Testez le scénario trois :
Continuez le scénario deux, modifiez le fichier index.html et ajoutez le fichier test01.html en tant que nouveau fichier. À ce stade, git ajoutez le fichier test01.html, laissez test01. html soit suivi par git, puis git stash, vous pouvez voir que le fichier test01.html est temporairement stocké via la méthode git stash show, puis git stash pop, les modifications sont restaurées, git status a révélé que le fichier test01.html est dans un état temporaire et que index.html est toujours une modification de l'espace de travail conservée. C'est-à-dire que git ajoute un fichier qui n'a pas été suivi par git auparavant. Après git stash, ce fichier sera temporairement stocké, et après git stash pop, le fichier nouvellement ajouté sera toujours dans un état comparatif. scénario 1, index Dans le fichier .html, seules les modifications dans l'espace de travail sont stockées temporairement, et les modifications dans la zone de stockage temporaire sont perdues.
4. Testez le scénario quatre :
Continuez le scénario trois, modifiez le fichier index.html et ajoutez le fichier test01.html en tant que nouveau fichier. À ce stade, git ajoutez le fichier test01.html, laissez test01. html soit suivi par git, puis modifiez le fichier test01.html, puis git stash, git stash pop, et constatez que test01.html est toujours dans un état temporaire, mais le contenu du fichier temporairement enregistré est le contenu final modifié de l'espace de travail. C'est-à-dire que git ajoute un fichier qui n'a pas été suivi par git auparavant, puis modifie le fichier après git stash, le fichier sera temporairement stocké, et après git stash pop, le fichier nouvellement ajouté sera toujours présent. un état temporaire, mais le contenu de modification temporairement enregistré est le contenu de modification de l'espace de travail précédent plutôt que le contenu de modification temporaire via l'ajout.
Grâce au test ci-dessus, je n'ai pas trouvé le modèle de fonctionnement de git stash, et j'étais très confus. J'espère qu'un expert git pourra me donner des conseils et une analyse.
Tout d'abord, laissez-moi vous expliquer la fonction de base de la commande
git stash
: gère l'état sale du répertoire de travail, c'est-à-dire les fichiers de suivi modifiés et les modifications temporaires , puis les modifications inachevées sont enregistrées dans une pile . Après avoir appris cela, jetons un œil à quelques points clés que j'ai résumés :La commande
git stash
poussera les fichiers suivis sur la pile, tandis que les fichiers non suivis ne seront pas poussés sur la pile, comme décrit dans l'expérience 2 de l'affiche.Si le travail précédent a été ajouté à la zone de stockage temporaire , la commande
git stash
n'ajoutera pas la modification qui place la pile dans la zone de stockage temporaire par défaut, comme décrit dans l'expérience de l'affiche 1 C'est le cas, mais la description de l'affiche est en réalité fausse. Les modifications précédemment enregistrées temporairement n'ont pas été abandonnées ou perdues mais sont restées dans la zone de travail, mais n'ont pas été ajoutées à la zone de stockage temporaire.Concernant le fichier nouvellement ajouté test01.html dans les expériences 2 et 3 de l'affiche, il s'agit en fait d'une situation particulière. Nous pouvons le comprendre ainsi : le résultat de
stash pop
est de restaurer les modifications précédentes, et l'opération de récupération qu'il peut effectuer pour test01.html ne peut être que de rejoindre la zone de stockage temporaire, sinon test01.html redeviendra. statut non suivi.Si vous souhaitez réappliquer les modifications de la sauvegarde temporaire précédente, vous pouvez ajouter l'option
git stash pop
après--index
, afin de pouvoir la restaurer exactement à l'identique comme avant, c'est-à-dire que le précédent temporaire Ce qui a été enregistré sera désormais dans un état temporaire, et ce qui est temporairement enregistré sera toujours dans un état non intermédiaire.Enfin, je dois préciser ce que dit l'affiche :
ou
En fait, la description est fausse, ou il ne faut pas la décrire ainsi, car cela nous ferait mal comprendre - on peut penser à tort que
, mais la situation réelle devrait être la suivante :git stash
ne sauvegardera que temporairement les modifications de l'espace de travailgit stash
conservera les opérations restaurées dans l'espace de travail par défaut, mais ne les remettra pas automatiquement en scène pour vous .L'affiche peut refaire l'expérience ci-dessus pour vérifier ma déclaration.