¿Cómo resolver el conflicto de git stash sin commit?

Como se preguntó en esta pregunta , también quiero saber cómo resolver un conflicto git stash popsin agregar todas las modificaciones a una confirmación (al igual que "git stash pop" sin conflicto).

Mi enfoque actual es muy poco interesante porque lo hago de esta manera:

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

[Actualización] Una forma de reproducirlo:

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: se agregó un nuevo archivo llamado 'tercero' al ejemplo para mostrar que soluciones alternativas como la solución de scy solo funcionan para HEADs vacías pero no solucionan el problema inicial de que HEAD no tiene el mismo contenido como para un git stash popsin conflicto.

No sigas otras respuestas

Bueno, puedes seguirlos :). Pero no creo que hacer una confirmación y luego restablecer la rama para eliminar esa confirmación y soluciones similares sugeridas en otras respuestas sean la forma más clara de resolver este problema.

Solución limpia

La siguiente solución parece ser mucho más limpia para mí y también es sugerida por el propio Git : intente ejecutar git statusen el repositorio con un conflicto:

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

Entonces, hagamos lo que Git sugiere (sin hacer ninguna confirmación inútil):

1. Manualmente (o usando alguna herramienta de fusión , ver más abajo) resuelve los conflictos.
2. Se usa git resetpara marcar los conflictos como resueltos y desestabilizar los cambios. Puede ejecutarlo sin ningún parámetro y Git eliminará todo del índice. No tienes que ejecutar git addantes.
3. Finalmente, elimine el alijo con git stash drop, porque Git no lo hace en caso de conflicto.

Traducido a la línea de comandos:

$ git stash pop

# ...resolve conflict(s)

$ git reset

$ git stash drop

Explicación del comportamiento predeterminado.

Hay dos formas de marcar los conflictos como resueltos: git addy git reset. Mientras git resetmarca los conflictos como resueltos y elimina los archivos del índice, git addtambién marca los conflictos como resueltos, pero mantiene los archivos en el índice.

Agregar archivos al índice después de resolver un conflicto es a propósito. De esta manera, puede diferenciar los cambios del alijo anterior y los cambios que realizó después de que se resolvió el conflicto. Si no le gusta, siempre puede usar git resetpara eliminar todo del índice.

Herramientas de fusión

Recomiendo usar cualquiera de las herramientas de combinación de 3 vías para resolver conflictos, por ejemplo , KDiff3 , Meld , etc., en lugar de hacerlo manualmente. Por lo general, resuelve todos o la mayoría de los conflictos automáticamente. ¡Es un gran ahorro de tiempo!

Supongamos que tiene este escenario en el que oculta sus cambios para extraerlos del origen. Posiblemente porque sus cambios locales son solo debug: trueen algunos archivos de configuración. Ahora tiras y alguien ha introducido una nueva configuración allí, creando un conflicto.

git status dice:

# 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")

Bueno. Decidí seguir con lo que Git sugirió: resolví el conflicto y me comprometí:

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

Ahora mi copia de trabajo está en el estado que quiero, pero he creado una confirmación que no quiero tener. ¿Cómo me deshago de esa confirmación sin modificar mi copia de trabajo? ¡Espera, hay un comando popular para eso!

git reset HEAD^

Mi copia de trabajo no ha cambiado, pero la confirmación WIP se ha ido. Eso es exactamente lo que quería! (Tenga en cuenta que no lo estoy usando --softaquí, porque si hay archivos fusionados automáticamente en su alijo, se almacenan automáticamente y, por lo tanto, terminaría con estos archivos nuevamente reset).

Pero queda una cosa más: la página del manual git stash popnos recuerda que "la aplicación del estado puede fallar con los conflictos; en este caso, no se elimina de la lista oculta. Es necesario resolver los conflictos a mano y llamar git stash dropmanualmente después". Entonces eso es exactamente lo que hacemos ahora:

git stash drop

Y hecho.

En lugar de agregar los cambios que realice para resolver el conflicto, puede usarlo git reset HEAD filepara resolver el conflicto sin organizar sus cambios.

Sin embargo, es posible que deba ejecutar este comando dos veces. Una vez para marcar el conflicto como resuelto y una vez para desestimar los cambios organizados por la rutina de resolución de conflictos.

Es posible que haya un modo de reinicio que haga ambas cosas simultáneamente, aunque ahora no hay ninguno.

git checkout stash -- .

trabajó para mi.

Nota : esto puede ser peligroso ya que no intenta fusionar los cambios del alijo en su copia de trabajo, sino que lo sobrescribe con los archivos escondidos. Para que pueda perder sus cambios no comprometidos.

git add .
git reset

git add . organizará TODOS los archivos diciéndole a git que ha resuelto el conflicto

git reset desestabilizará TODOS los archivos organizados sin crear una confirmación

Parece que esta puede ser la respuesta que estás buscando, aún no lo he intentado personalmente, pero parece que puede ser el truco. Con este comando, GIT intentará aplicar los cambios como estaban antes, sin intentar agregarlos todos para confirmar.

git stash apply --index

Aquí está la explicación completa:

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

git stash branchwill works, que crea una nueva rama para usted, comprueba el commit en el que estaba cuando escondió su trabajo, vuelve a aplicar su trabajo allí y luego deja caer el alijo si se aplica con éxito. mira esto

La forma más rápida que he encontrado es resolver el conflicto, luego hacer git add -u, y luego hacer git reset HEAD, que ni siquiera implica un compromiso.

Según las preguntas de git stash , después de arreglar el conflicto, git add <file>es el curso de acción correcto.

Fue después de leer este comentario que entendí que los cambios se agregan automáticamente al índice (por diseño). Es por eso que git add <file>completa el proceso de resolución de conflictos.

No es la mejor manera de hacerlo, pero funciona:

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