Git esconde dos ramas

6 minutos de lectura

Avatar de usuario de Gabriel Ferraz
gabriel ferraz

Esta es la situación:

  1. Hice cambios en la rama A
  2. git stash en la rama A
  3. git checkout B
  4. Hizo cambios en la rama B
  5. git stash en la rama B
  6. git checkout A
  7. git stash pop en la rama A

Después del paso 7 de la lista anterior, los cambios que había realizado en la rama A antes del ocultamiento no regresaron, pero los cambios que había realizado en la rama B aparecieron en la rama A. Usé cmd z en la rama A y el archivo pasó a su estado anterior, que tenía los cambios que había hecho. Parecía que el JEFE de la sucursal A se movió al JEFE de la sucursal B. Lo mismo sucedió cuando git checkout B y git stash pop en esa rama: la rama B tenía todos los cambios realizados en la rama A pero no los cambios que había hecho en la rama B. Usé cmd z de nuevo para volver al estado de la rama que necesitaba.

Esto me causó muchos problemas durante algún tiempo, hasta que se me permitió confirmar el código nuevamente en el proyecto (nadie pudo confirmar durante un tiempo porque hubo un envío automático al servidor en las confirmaciones y el administrador no quería código nuevo en el servidor hasta que realizaron algunas pruebas). ¿Cómo puedo mostrar solo los cambios realizados en las propias ramas y no los cambios realizados en otras ramas?

  • No conozco una función que ate un alijo a una rama. Sin embargo, una entrada oculta tiene una descripción y, de forma predeterminada, esa descripción incluye el nombre de la rama desde la que se creó. Puedes usar git stash list para ver estas descripciones. Entonces, por ejemplo, use git stash pop stash@{1} para recuperar el segundo elemento de la pila.

    – Rafael

    26 de junio de 2016 a las 0:47


  • ¡Además, la inserción automática después de la confirmación parece una idea horrible! Las confirmaciones locales son LA mejora más importante de los sistemas de control de versiones distribuidos sobre el enfoque centralizado clásico. Eso y copia de seguridad.

    – Rafael

    26 de junio de 2016 a las 0:50

  • @Raffael: Probaré ese comando. Sobre el impulso automático, creo que fue temporal por cualquier razón que tuviera que ser (en general, estoy de acuerdo con usted). Llegué al proyecto hace aproximadamente 2 semanas y todavía me estoy acostumbrando a la forma en que funcionan las cosas.

    – Gabriel Ferraz

    26 de junio de 2016 a las 1:21


  • Empujar automáticamente a un servidor de respaldo sería una característica; con lo que estás trabajando es simplemente estúpido. +++ Aprendí a no abusar git stash de la manera difícil y te recomiendo que lo uses solo para cosas simples. Cuando las cosas se complican, busco sucursales temporales. Incluso con entradas ocultas correctamente nombradas, es demasiado fácil perderse. +++ También hay git stash show -p stash@{1} para verlo con detalles y cosas parecidas, pero trabajar con ramas es más sencillo.

    – maaartinus

    26 de junio de 2016 a las 3:53

  • Estoy de acuerdo, la ramificación es mejor. O cree una confirmación temporal al principio de la rama actual (me gusta llamarla WIP – trabajo en progreso). Lo que mejor se adapte a su escenario.

    – Rafael

    26 de junio de 2016 a las 8:49

avatar de usuario de torek
Torek

Qué git stash lo que hace es hacer un compromiso.1

por supuesto, que git commit lo que hace es hacer un compromiso. Entonces, ¿por qué tenemos git stash ¿en absoluto?

Una diferencia significativa entre estos comandos es que las confirmaciones git stash hace son no en ninguna rama. Esto te permite stash cuando esté en una rama, luego muévase a otra rama y aplique el alijo allí. En otras palabras, le permite mover el trabajo en curso.

A menudo, pero no siempre, puede mover el trabajo en curso de todos modos. Consulte Git: consulte otra rama cuando haya cambios no confirmados en la rama actual. Cuando usted no podersin embargo, puedes usar git stash para lidiar con esto.

Por otro lado, si desea “almacenar en una rama”, como en su caso, probablemente sea mejor que haga una confirmación regular, en lugar de una confirmación oculta especial. Estos compromisos son más fáciles de manejar y tampoco tienen un error que git stash posee. No es probable que te encuentres con este error, pero “las confirmaciones regulares son más simples y más fáciles de manejar” (confirmaciones en ramas, frente a escondites) es una muy buena razón para evitar git stash.

Si prefieres usar git stash de todos modos, tenga en cuenta que cada nuevo alijo “empuja” a los anteriores hacia arriba en una “pila de alijo”. El viejo alijo se convierte stash@{1}y que fue stash@{1} se convierte stash@{2}, y así. Cuando usted drop (descartar) o pop (intentar aplicar, luego descartar) un alijo, los apilados encima se mueven hacia abajo, por lo que si tuviera que git stash drop stash@{3} cuando tuviste stash@{4} y stash@{5} además, te quedarías con stash@{3} y stash@{4} ahora.

Puedes nombrar cualquier alijo, incluido el más reciente, de esta manera: stash@{0} significa lo mismo que stash. (Git en realidad implementa todo esto usando el reflog por stash.)


1De hecho, hace al menos dos comete, y a veces tres. Las dos confirmaciones almacenan el índice y el estado del árbol de trabajo; el tercer compromiso, si está presente, es de -u o -a y almacena lo no organizado (-u) o todo (-a) archivos. La confirmación del árbol de trabajo es una confirmación de combinación muy extraña, con la confirmación de índice como su segundo padre y la tercera confirmación, si está presente, como su tercer padre. El primer padre de la confirmación del árbol de trabajo, y el único padre de la confirmación del índice, es la confirmación actual cuando ejecutó git stash.

Si dibuja fragmentos de gráficos de confirmación, lo cual, siempre que esté haciendo algo complicado en Git, es una buena idea, el par de confirmación de índice y árbol de trabajo cuelga de la confirmación original, con el refs/stash referencia que apunta al par, en lugar del nombre de la rama. Parece casi un bolso pequeño, o un alijo de comida colgado de la rama de un árbol para mantenerlo alejado de los osos, o algo así, así que me gusta referirme a esto como una “bolsa de almacenamiento”.

Torek (como de costumbre) brinda una excelente respuesta, pero creo que la respuesta sucinta aquí es solo para notar que el alijo contiene datos como una pila (LIFO). Entonces, cuando empujaste el trabajo de A y luego el trabajo de B, primero aparece B y luego A. Entonces, cuando regresaste a A y luego hiciste el primer pop, obtuviste el trabajo B guardado.

¡Abrir un alijo vuelve a aplicar ese último alijo independientemente de la rama que escondiste! Entonces, el problema que está publicando es que el último alijo que se creó en la rama B se volvió a aplicar en la rama A. La próxima vez, debe especificar qué alijo desea abrir.

Solución al problema dado:

  1. Guardar de nuevo el estado actual
  2. Pop el alijo que está antes del último

Eso es todo.

si escribes git stash list algo como esto se mostrará en función de su situación dada

stash@{0}: WIP on branch-b
stash@{1}: WIP on branch-a

mecanografía git stash pop siempre obtendrá el stash@{0} nodo.

Entonces, si estás dentro branch a y quieres aplicar tu progreso en esa rama. Basándose en la lista, debe escribir:

git stash pop stash@{1}

¿Ha sido útil esta solución?