Me equivoco git stash: git stash pop y terminó con conflictos de fusión

Hice un git stash pop y terminé con conflictos de fusión. Quité los files del sistema de files y git checkout un git checkout como se muestra a continuación, pero cree que los files aún no están fusionados. Luego intenté replace los files y hacer un git checkout nuevamente y el mismo resultado. He intentado forzarlo con -f flag. ¡Cualquier ayuda sería apreciada!

 chirag-patels-macbook-pro:haloror patelc75$ git status app/views/layouts/_choose_patient.html.erb: needs merge app/views/layouts/_links.html.erb: needs merge # On branch prod-temp # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: db/schema.rb # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # unmerged: app/views/layouts/_choose_patient.html.erb # unmerged: app/views/layouts/_links.html.erb chirag-patels-macbook-pro:haloror patelc75$ git checkout app/views/layouts/_choose_patient.html.erb error: path 'app/views/layouts/_choose_patient.html.erb' is unmerged chirag-patels-macbook-pro:haloror patelc75$ git checkout -f app/views/layouts/_choose_patient.html.erb warning: path 'app/views/layouts/_choose_patient.html.erb' is unmerged 

Ver man git merge ( CÓMO RESOLVER CONFLICTOS ):

Después de ver un conflicto, puedes hacer dos cosas:

  • Decide no fusionar. Las únicas limpiezas que necesita son restablecer el file de índice al compromiso HEAD para invertir 2. y limpiar los cambios de tree de trabajo hechos por 2. y 3 .; git-reset –hard se puede usar para esto.

  • Resuelve los conflictos. Git marcará los conflictos en el tree de trabajo. Edite los files en forma y git agréguelos al índice. Usa git commit para sellar el trato.

Y bajo TRUE MERGE (para ver a qué se refieren 2. y 3.):

Cuando no es obvio cómo conciliar los cambios, sucede lo siguiente:

  1. El puntero HEAD permanece igual.

  2. La reference MERGE_HEAD está configurada para apuntar a la otra cabeza de bifurcación.

  3. Las routes que se fusionaron limpiamente se actualizan tanto en el file de índice como en el tree de trabajo.

Entonces, use git reset --hard si quiere eliminar los cambios de escondite de su tree de trabajo, o git reset si quiere simplemente limpiar el índice y dejar que los conflictos en su tree de trabajo se combinen a mano.

En man git stash ( OPTIONS, pop ) puedes leer además:

Aplicar el estado puede fallar con conflictos; en este caso, no se elimina de la list oculta. Debes resolver los conflictos a mano y llamar a git stash drop manualmente después.

Me pasó algo similar a mí. No quería representar los files por el momento, así que los agregué con git add y luego simplemente git reset . Esto básicamente acaba de agregar y luego no escalonó mis cambios, pero borró las routes no fusionadas.

Si, como yo, lo que generalmente desea es sobreescribir el contenido del directory de trabajo con el de los files escondidos, y todavía tiene un conflicto, entonces lo que quiere es resolver el conflicto usando git checkout --theirs -- . desde la raíz

Después de eso, puede git reset para traer todos los cambios desde el índice al directory de trabajo, ya que aparentemente en caso de conflicto los cambios en los files no conflictivos permanecen en el índice.

Es posible que también desee ejecutar git stash drop [<stash name>] para eliminar el alijo, ya que git stash pop no lo elimina en caso de conflicto.

Tenga en count que Git 2.5 (Q2 2015) un futuro Git podría intentar que ese escenario sea imposible.

Ver commit ed178ef por Jeff King ( peff ), 22 de abril de 2015.
(Fusionada por Junio ​​C Hamano – gitster – en commit 05c3967 , 19 de mayo de 2015)

Nota: Esto ha sido revertido. Ver a continuación .

stash : requiere un índice limpio para aplicar / pop

Problema

Si ha organizado contenidos en su índice y ejecuta " stash apply/pop ", podemos golpear un conflicto y poner nuevas inputs en el índice.
Recuperarse a su estado original es difícil en ese punto, porque herramientas como "git reset –keep" soplarán cualquier escena .

En otras palabras:

" git stash pop/apply " se olvidó de asegurarse de que no solo el tree de trabajo esté limpio, sino que el índice esté limpio.
Esto último es importante ya que una aplicación oculta puede entrar en conflicto y el índice se usará para la resolución de conflictos.

Solución

Podemos hacer esto más seguro al rechazar aplicar cuando hay cambios por etapas.

Eso significa que si se fusionaron antes debido a la aplicación de un alijo en los files modificados (agregados pero no confirmados), ahora no se fusionarían porque el alijo aplicar / pop se detendría inmediatamente con:

 Cannot apply stash: Your index contains uncommitted changes. 

Obligar a cometer los cambios significa que, en caso de fusiones, puede restaurar fácilmente el estado inicial (antes de que git stash apply/pop ) con un git reset --hard .


Consulte la confirmación 1937610 (15 de junio de 2015) y confirme ed178ef (22 de abril de 2015) por Jeff King ( peff ) .
(Fusionada por Junio ​​C Hamano – gitster – in commit bfb539b , 24 de junio de 2015)

Ese compromiso fue un bash de mejorar la security de la aplicación de un alijo, porque el process de request puede crear inputs de índice en conflicto, después de lo cual es difícil restaurar el estado del índice original.

Desafortunadamente, esto daña algunos flujos de trabajo comunes en torno a " git stash -k ", como:

 git add -p ;# (1) stage set of proposed changes git stash -k ;# (2) get rid of everything else make test ;# (3) make sure proposal is reasonable git stash apply ;# (4) restre original working tree 

Si "cometer git" entre los pasos (3) y (4), entonces esto simplemente funciona. Sin embargo, si estos pasos forman parte de un enganche precompromiso, no tiene esa oportunidad (debe restaurar el estado original independientemente de si las testings pasaron o fallaron).