Cache Git : enregistrez les modifications, changez de branche et restaurez votre travail

Le cache Git enregistre les modifications non validées afin que vous puissiez travailler sur autre chose, puis restaurer ces modifications. Commencez par git stash push -m "WIP: checkout form" ; restaurez avec git stash apply lorsque vous souhaitez conserver l'entrée enregistrée, ou git stash pop lorsque vous souhaitez la supprimer après une restauration réussie. Ajoutez -u lorsque de nouveaux fichiers non suivis appartiennent également à l'œuvre.

Ce guide utilise comme exemple une interruption de formulaire de paiement : mettre le formulaire en pause, corriger un bug de production sur une autre branche, puis revenir au formulaire. La procédure visuelle utilise GitTree, le client que nous créons pour macOS, Windows et Linux. La gestion des réserves est incluse dans le plan gratuit ; Les versions officielles actuelles nécessitent une connexion.

Quand utiliser stash, un commit ou un worktree

Pour des tâches parallèles plus longues, utilisez le guide worktree. Une réserve est un stockage temporaire pratique, mais ne doit pas être votre seule sauvegarde d'un travail précieux. Nommez les entrées après la tâche, car stash@{0} signifie la dernière entrée et les numéros changent à mesure que la liste change.

Enregistrer les modifications et changer de branche : un exemple complet

Inspectez d'abord git status : une réserve par défaut inclut les modifications apportées aux fichiers suivis, y compris les modifications par étapes, mais laisse seuls les fichiers non suivis et ignorés. Dans cet exemple, le formulaire inclut un fichier nouvellement créé, utilisez donc -u. Ces commandes supposent que feature/checkout et hotfix/payment existent déjà ; remplacez vos propres noms de succursales.

git status
git stash push -u -m "WIP: checkout form"
git stash list
git status
git switch hotfix/payment

Terminez, testez et validez le correctif avant de revenir. Vérifiez la liste de cachette et ses différences avant de postuler : une autre tâche a peut-être créé une entrée plus récente entre-temps. Citer un sélecteur tel que "stash@{0}" empêche également les shells d'interpréter ses caractères spéciaux.

git switch feature/checkout
git stash list
git stash show -p --include-untracked "stash@{0}"
git stash apply "stash@{0}"
git status

Git stash apply vs pop : lequel choisir ?

Pour une modification importante inachevée, appliquez-la d'abord, examinez-la et testez-la, puis supprimez l'entrée enregistrée une fois que vous avez validé le travail restauré. Appliquer deux fois peut créer des conflits ou répéter des modifications ; inspectez les fichiers de travail avant de réessayer. Ni apply ni pop ne transmettent quoi que ce soit à un serveur.

Cachez les fichiers non suivis, les fichiers spécifiques ou les modifications par étapes

git stash push -u -m "WIP: include new files"
git stash push -m "WIP: checkout only" -- src/checkout.ts
git stash push --staged -m "WIP: staged changes only"
git stash push --keep-index -m "WIP: keep staged work ready"

Ce sont des commandes alternatives, pas une séquence à exécuter ensemble. Un chemin après -- limite le stockage à ce chemin. --staged enregistre uniquement les modifications par étapes ; --keep-index laisse les modifications par étapes en place afin que vous puissiez les tester ou les valider tout en mettant de côté les autres modifications. Ils résolvent différents problèmes. Les anciennes installations Git peuvent ne pas prendre en charge --staged ; consultez git --version et l'aide pour votre version installée.

Vous souhaitez suivre ces étapes avec votre propre référentiel ? Télécharger GitTree, connectez-vous et ouvrez le dossier du référentiel. Vos caches existantes restent des cachettes Git ordinaires, également visibles depuis le terminal.

Comment résoudre les conflits git stash pop

Une réserve peut entrer en conflit lorsque la branche de destination a modifié les mêmes lignes. Un pop échoué conserve la réserve, mais certaines modifications peuvent déjà avoir été appliquées. Ne le faites pas sauter à plusieurs reprises. Exécutez git status, résolvez chaque fichier non fusionné et préparez uniquement les résolutions prévues. Le guide des conflits de fusion explique les marqueurs et l'éditeur à trois voies.

git status
git diff --name-only --diff-filter=U
# Edit and test each conflicted file, then stage its resolution:
git add -- src/checkout.ts
git diff --cached
git status

Il n'y a pas de git stash --continue ou de git stash --abort. Une fois les fichiers résolus, examinez et validez normalement. Si vous souhaitez abandonner la tentative, conservez tout travail existant avant l'application et inspectez chaque chemin modifié avant de supprimer quoi que ce soit. Une réinitialisation matérielle générale peut effacer les modifications sans rapport. Lorsque la destination a trop divergé, git stash branch rescue/checkout "stash@{0}" restaure sur une nouvelle branche à la base d'origine ; une opération réussie supprime cette entrée de cache.

Supprimez une réserve seulement après avoir vérifié le résultat

Utilisez à nouveau git stash list avant git stash drop "stash@{0}" : la position a peut-être changé. git stash clear supprime toute la liste. La récupération d'une réserve supprimée dans Git simple est incertaine et dépend de l'existence ou non de ses objets ; ne comptez pas le retrouver plus tard. Dans GitTree, Supprimer le cache conserve l'entrée supprimée dans les instantanés de récupération afin qu'Annuler puisse la restaurer. Cette récupération spécifique à l'application ne fait pas de la suppression du terminal une action récupérable garantie. Pour des options de récupération plus larges, consultez annuler les erreurs Git.