Comment résoudre le conflit de git stash sans commit?

Comme demandé dans cette question , je veux également savoir comment résoudre un conflit git stash popsans ajouter toutes les modifications à un commit (tout comme "git stash pop" sans conflit).

Mon approche actuelle est très peu cool car je le fais de cette façon:

git stash pop -> CONFLICT
git stash drop
[resolve conflict]
[add conflict files]
git reset HEAD <all files that are in commit-mode>

[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é «troisième» à l'exemple pour montrer que des solutions de contournement comme la solution de scy ne fonctionnent que pour les HEAD vides mais ne résolvent pas le problème initial que la HEAD n'a pas le même contenu comme pour un git stash popsans conflit.

Ne suivez pas les autres réponses

Eh bien, vous pouvez les suivre :). Mais je ne pense pas que faire un commit puis réinitialiser la branche pour supprimer ce commit et les solutions de contournement similaires suggérées dans d'autres réponses soient la bonne façon de résoudre ce problème.

Solution propre

La solution suivante semble être beaucoup plus propre pour moi et elle est également suggérée par le Git lui - même - essayez de l'exécuter git statusdans le référentiel avec un conflit:

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

Faisons donc ce que Git suggère (sans faire de commits inutiles):

1. Résolvez manuellement le conflit (ou en utilisant un outil de fusion , voir ci-dessous).
2. Permet git resetde marquer les conflits comme résolus et de supprimer les modifications. Vous pouvez l'exécuter sans aucun paramètre et Git supprimera tout de l'index. Vous n'avez pas à exécuter git addavant.
3. Enfin, supprimez la cachette avec git stash drop, car Git ne le fait pas en cas de conflit.

Traduit en ligne de commande:

$ git stash pop

# ...resolve conflict(s)

$ git reset

$ git stash drop

Explication du comportement par défaut

Il existe deux façons de marquer les conflits comme résolus: git addet git reset. Bien que git resetmarque les conflits comme résolus et supprime les fichiers de l'index, git addmarque également les conflits comme résolus, mais conserve les fichiers dans l'index.

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 de la sauvegarde précédente et les modifications apportées après la résolution du conflit. Si vous ne l'aimez pas, vous pouvez toujours utiliser git resetpour tout supprimer de l'index.

Outils de fusion

Je recommande fortement d'utiliser l'un des outils de fusion à 3 voies pour résoudre les conflits, par exemple KDiff3 , Meld , etc., au lieu de le faire manuellement. Il résout généralement automatiquement la totalité ou la majorité des conflits. C'est un énorme gain de temps!

Supposons que vous ayez ce scénario dans lequel vous planifiez vos modifications afin de tirer de l'origine. Peut-être parce que vos modifications locales ne se trouvent que debug: truedans certains fichiers de paramètres. Maintenant, vous tirez et quelqu'un y a introduit un nouveau paramètre, créant un conflit.

git status dit:

# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." 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é de suivre ce que Git a suggéré: j'ai résolu le conflit et commis:

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 --softici, car s'il y a des fichiers fusionnés automatiquement dans votre stash, ils sont automatiquement mis en scène et vous vous retrouveriez donc avec ces fichiers en cours de mise en scène après reset.)

Mais il reste une chose: la page de manuel pour git stash popnous rappelle que "L'application de l'état peut échouer avec des conflits; dans ce cas, il n'est pas supprimé de la liste de dissimulation. Vous devez résoudre les conflits à la main et appeler git stash dropmanuellement par la suite." C'est exactement ce que nous faisons maintenant:

git stash drop

Et.. Voila.

Au lieu d'ajouter les modifications que vous apportez pour résoudre le conflit, vous pouvez utiliser git reset HEAD filepour résoudre le conflit sans mettre en scène vos modifications.

Cependant, vous devrez peut-être exécuter cette commande deux fois. Une fois pour marquer le conflit comme résolu et une fois pour mettre en scène les changements qui ont été mis en place par la routine de résolution de conflit.

Il est possible qu'il y ait un mode de réinitialisation qui fasse ces deux choses simultanément, bien qu'il n'y en ait pas maintenant.

git checkout stash -- .

travaillé pour moi.

Remarque : cela peut être dangereux car il n'essaie pas de fusionner les modifications de la cachette dans votre copie de travail, mais l' écrase à la place avec les fichiers cachés. Vous pouvez donc perdre vos modifications non validées.

git add .
git reset

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

git reset décompactera TOUS les fichiers intermédiaires sans créer de commit

Il semble que ce soit la réponse que vous cherchez, je n'ai pas encore essayé personnellement, mais il semble que cela puisse faire l'affaire. Avec cette commande, GIT essaiera d'appliquer les modifications telles qu'elles étaient auparavant, sans essayer de les ajouter toutes pour les valider.

git stash apply --index

voici l'explication complète:

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

git stash branchwill works, qui crée une nouvelle branche pour vous, vérifie le commit sur lequel vous étiez lorsque vous avez caché votre travail, y réapplique votre travail, puis supprime la cachette si elle s'applique correctement. vérifier ça

Le moyen le plus rapide que j'ai trouvé est de résoudre le conflit, puis de le faire git add -u, puis de le faire git reset HEAD, cela n'implique même pas un commit.

Selon Git Stash , après avoir réglé le conflit, git add <file>c'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 <file>achève le processus de résolution des conflits.

Ce n'est pas la meilleure façon de le faire, mais cela fonctionne:

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