Comment résoudre un conflit de git stash sans commettre?

Comme demandé dans cette question , je veux aussi savoir comment résoudre un git stash pop conflictuel sans append toutes les modifications à un commit (tout comme “git stash pop” sans conflit).

Mon approche actuelle est très désagréable parce que je le fais de cette façon:

 git stash pop -> CONFLICT git stash drop [resolve conflict] [add conflict files] git reset HEAD  

[Mise à jour] Une façon de le reproduire:

 mkdir foo; cd foo; git init echo "1" > one echo "2" > two git add -A; git commit -m "first" echo "1.1" > one echo "2.1" > two git stash echo "2.2" > two git commit -a -m "second" echo "Only this file would stay in HEAD without the conflict" > third git add third git stash pop git status 

2016-06-27: Ajout d’un nouveau fichier appelé ‘third’ à l’exemple pour montrer que les solutions de contournement comme la solution de scy ne fonctionnent que pour les HEADs vides mais ne résolvent pas le problème initial, à savoir que HEAD n’a pas le même contenu pour une git stash pop sans conflit.

Supposons que vous ayez ce scénario dans lequel vous rangez vos modifications afin de tirer de l’origine. Peut-être parce que vos modifications locales ne sont que du debug: true dans certains fichiers de parameters. Maintenant, vous tirez et quelqu’un a introduit un nouveau paramètre, créant un conflit.

git status dit:

 # On branch master # Unmerged paths: # (use "git reset HEAD ..." to unstage) # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: src/js/globals.tpl.js no changes added to commit (use "git add" and/or "git commit -a") 

D’accord. J’ai décidé d’aller avec ce que Git a suggéré: j’ai résolu le conflit et je me suis engagé:

 vim src/js/globals.tpl.js # type type type … git commit -a -m WIP # (short for "work in progress") 

Maintenant, ma copie de travail est dans l’état que je veux, mais j’ai créé un commit que je ne veux pas avoir. Comment puis-je me débarrasser de ce commit sans modifier ma copie de travail? Attendez, il y a une commande populaire pour ça!

 git reset HEAD^ 

Ma copie de travail n’a pas été modifiée, mais la validation WIP a disparu. C’est exactement ce que je voulais! (Notez que je n’utilise pas --soft ici, car s’il y a des fichiers auto-fusionnés dans votre réserve, ils sont automatiquement mis à niveau et vous devriez donc retrouver ces fichiers après la reset .)

Mais il y a encore une chose: la page de manuel pour git stash pop nous rappelle que “l’application de l’état peut échouer avec des conflits; dans ce cas, elle n’est pas supprimée de la liste. Vous devez résoudre les conflits manuellement et appeler git stash drop manuellement après. “ Donc, c’est exactement ce que nous faisons maintenant:

 git stash drop 

Et fait.

Je ne pense pas que faire une validation et puis réinitialiser la twig pour supprimer cette validation et les solutions de contournement similaires suggérées dans d’autres réponses sont la manière propre de résoudre ce problème.

La solution suivante me semble beaucoup plus propre et Git luimême suggère d’ exécuter git status dans le repository avec un conflit:

 Unmerged paths: (use "git reset HEAD ..." to unstage) (use "git add ..." to mark resolution) 

Faisons ce que Git suggère sans faire aucun engagement:

  1. Manuellement (ou à l’aide d’un outil de fusion par interface graphique), résolvez le ou les conflits.
  2. Utilisez git reset pour marquer les conflits comme résolus et décomposer les modifications. Vous pouvez l’exécuter sans aucun paramètre et Git va tout supprimer de l’index. Vous n’avez pas besoin d’exécuter git add avant.
  3. Enfin, supprimez le cache avec Git git stash drop , car Git ne le fait pas en cas de conflit.

Alors:

 $ git stash pop # ...manually resolve conflict(s) $ git reset $ git stash drop 

Remarque: l’ ajout de fichiers à l’index après la résolution d’un conflit est délibéré. De cette façon, vous pouvez différencier les modifications du cache précédent et les modifications apscopes après la résolution du conflit. Si vous ne l’aimez pas, vous pouvez toujours utiliser git reset pour tout supprimer de l’index.

Autre remarque: je recommande fortement d’utiliser l’un des outils de fusion à trois voies pour résoudre les conflits, par exemple KDiff3 . Il résout généralement la majorité des conflits automatiquement.

Au lieu d’append les modifications que vous apportez pour résoudre le conflit, vous pouvez utiliser le git reset HEAD file pour résoudre le conflit sans mettre en place vos modifications.

Vous devrez peut-être exécuter cette commande deux fois, cependant. Une fois pour marquer le conflit comme résolu et une fois pour dissocier les modifications apscopes par la routine de résolution de conflit.

Il est possible qu’il y ait un mode de réinitialisation qui effectue ces deux opérations simultanément, bien qu’il n’y en ait pas une maintenant.

 git checkout stash -- . 

travaillé pour moi

Remarque : cela peut être dangereux car il n’essaie pas de fusionner les modifications du cache dans votre copie de travail, mais le remplace par les fichiers cachés. Vous pouvez donc perdre vos modifications non validées.

Il semble que cela puisse être la réponse que vous recherchez, je ne l’ai pas encore essayé personnellement, mais il semble que cela puisse faire l’affaire. Avec cette commande, GIT essaiera d’appliquer les modifications comme auparavant, sans essayer de les append toutes pour la validation.

git stash apply --index

voici l’explication complète:

http://git-scm.com/book/en/Git-Tools-Stashing

 git add . git reset 

git add . mettra en scène TOUS les fichiers en disant que vous avez résolu le conflit

git reset désinstallera TOUS les fichiers mis en scène sans créer de commit

git stash branch va fonctionner, ce qui crée une nouvelle twig pour vous, vérifie la validation sur laquelle vous étiez lorsque vous avez caché votre travail, réapplique votre travail là-bas, puis supprime le cache s’il s’applique correctement. vérifier ceci

Le moyen le plus rapide que j’ai trouvé est de résoudre le conflit, puis de faire git add -u , puis de git reset HEAD , ce qui n’implique même pas de validation.

Selon git stash questions , après avoir corrigé le conflit, git add est la bonne ligne de conduite.

C’est après avoir lu ce commentaire que j’ai compris que les modifications sont automatiquement ajoutées à l’index (par conception). C’est pourquoi git add complète le processus de résolution de conflit.

Ce n’est pas la meilleure façon de le faire mais ça marche:

 $ git stash apply $ >> resolve your conflict << $ >> do what you want to do with your code << $ git checkout HEAD -- file/path/to/your/file