Il existe de nombreuses façons différentes en fonction de votre progression et de la ou des branches sur lesquelles vous les souhaitez.
Prenons une erreur classique:
$ git checkout master
... pause for coffee, etc ...
... return, edit a bunch of stuff, then: oops, wanted to be on develop
Alors maintenant, vous voulez que ces changements, auxquels vous ne vous êtes pas encore engagés master, soient appliqués develop.
Si vous ne disposez pas d' une developencore, la méthode est triviale:
$ git checkout -b develop
Cela crée une nouvelle developbranche à partir de l'endroit où vous vous trouvez maintenant. Vous pouvez maintenant vous engager et les nouveautés sont activées develop.
Vous avez un develop. Voyez si Git vous permettra de changer sans rien faire:
$ git checkout develop
Cela réussira ou se plaindra. Si ça réussit, tant mieux! Engagez-vous. Sinon ( error: Your local changes to the following files would be overwritten ...), vous avez encore beaucoup d'options.
Le plus simple est probablement git stash(comme l'ont dit tous les autres répondants qui m'ont battu en cliquant post). Exécutez git stash saveou git stash push, 1 ou tout simplement git stashqui est l'abréviation de save/ push:
$ git stash
Cela valide votre code (oui, cela fait vraiment des commits) en utilisant une méthode étrange non-branch-y. Les commits qu'il fait ne sont "sur" aucune branche mais sont maintenant stockés en toute sécurité dans le référentiel, vous pouvez donc maintenant changer de branche, puis "appliquer" la cachette:
$ git checkout develop
Switched to branch 'develop'
$ git stash apply
Si tout se passe bien et que vous aimez les résultats, vous devriez alors git stash drople cacher. Cela supprime la référence aux commits étranges non-branch-y. (Ils sont toujours dans le référentiel et peuvent parfois être récupérés en cas d'urgence, mais dans la plupart des cas, vous devriez les considérer comme partis à ce stade.)
L' applyétape effectue une fusion des modifications cachées, en utilisant la puissante machine de fusion sous-jacente de Git, le même genre de chose qu'elle utilise lorsque vous effectuez des fusions de branches. Cela signifie que vous pouvez obtenir des "conflits de fusion" si la branche sur laquelle vous travailliez par erreur est suffisamment différente de la branche sur laquelle vous vouliez travailler. C'est donc une bonne idée d' inspecter soigneusement les résultats avant de supposer que la réserve s'est appliquée proprement, même si Git lui-même n'a détecté aucun conflit de fusion.
Beaucoup de gens utilisent git stash pop, ce qui est un raccourci pour git stash apply && git stash drop. C'est bien dans la mesure où cela se passe, mais cela signifie que si l'application entraîne un désordre et que vous décidez que vous ne voulez pas suivre cette voie, vous ne pouvez pas récupérer la réserve facilement. C'est pourquoi je recommande de séparer apply, d'inspecter les résultats, dropuniquement si / lorsqu'ils sont satisfaits. (Cela introduit bien sûr un autre point où vous pouvez prendre une autre pause-café et oublier ce que vous faisiez, revenir et faire la mauvaise chose, donc ce n'est pas un remède parfait.)
1 Le savein git stash saveest l'ancien verbe pour créer une nouvelle réserve. La version 2.13 de Git a introduit le nouveau verbe pour rendre les choses plus cohérentes popet pour ajouter plus d'options à la commande de création. La version 2.16 de Git a formellement déprécié l'ancien verbe (bien qu'il fonctionne toujours dans Git 2.23, qui est la dernière version au moment où je modifie ceci).
git stashgit-scm.com/book/en/Git-Tools-Stashing