La semana pasada hablábamos sobre el manejo de ramas de desarrollo con Git. Hoy voy a hablaros sobre el stashing con Git.
Stashing es un concepto super simple que es increíblemente útil y muy fácil de usar. Si estamos trabajando en nuestro código y necesitamos cambiar a otra rama por cualquier motivo o quizás hacer un pull en el repositorio, y no queremos hacer un commit de nuestro trabajo por que se encuentra en un estado parcial, podemos usar stashing.
Para usar Git stashing solo tenemos que ejecutar git stash que lo que hace es congelar nuestros cambios desde nuestro último commit y almacenarlos de forma temporal dejando nuestro diectorio de trabajo completamente limpio.
En el ejemplo de abajo tengo cambios en mi directorio de trabajo a los que aún no he hecho commit por que no es un trabajo completo.
$ git status
# On branch master
# Changed but not updated:
# (use "git add file..." to update what will be committed)
# (use "git checkout -- file..." to discard changes in working directory)
#
# modified: http_request.py
# modified: inform.py
# modified: status.py
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git stash
Saved working directory and index state WIP on master: e87b43b bugfix for initialize spot
HEAD is now at e87b43b bugfix for initialize spot
$ git status
# On branch master
nothing to commit (working directory clean)Ahora tenemos el directorio de trabajo limpio igual que si no hubiéramos realizado cambios en los archivos. Ahora podemos cambiar de rama trabajar un rato, hacer un pull y después de realizar nuestro trabajo, podemos volver a recuperar nuestros cambios. Con stash list podemos ver la lista de stashes.
$ git stash list
stash@{0}: WIP on master: e87b43b bugfix for initialize spot
stash show stash@{#}$ git stash show stash@{0}
http_request.py | 1 +
inform.py | 1 +
status.py | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)git diff$ git diff stash@{0}
diff --git a/http_request.py b/http_request.py
index de10111..e69de29 100644
--- a/http_request.py
+++ b/http_request.py
@@ -1 +0,0 @@
-import sys
diff --git a/inform.py b/inform.py
index de10111..e69de29 100644
--- a/inform.py
+++ b/inform.py
@@ -1 +0,0 @@
-import sys
diff --git a/status.py b/status.py
index de10111..e69de29 100644
--- a/status.py
+++ b/status.py
@@ -1 +0,0 @@
-import sysgit stash appy stash@{#}$ git stash apply stash@{0}
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- </file><file>..." to discard changes in working directory)
#
# modified: http_request.py
# modified: inform.py
# modified: status.py
#
no changes added to commit (use "git add" and/or "git commit -a")</file>git stash apply
Más en Genbeta Dev | Manejo de ramas de desarrollo con git
Más Información | Manual de Git Stash
Comentarios
Para mí el uso del stash es otro.
Si estás en una rama y necesitas cambiar, no veo motivo para no hacer un commit de lo que lleves, aunque esté a medias. La verdadera utilidad del stash es que es un cambio aplicable a cualquier commit. Mi uso principal (que seguro que no es el que pensaron en su momento) es arreglar equivocaciones sin perder el trabajo hecho. Por ejemplo, acabas una issue, commiteas, haces push al code review de master y empiezas la siguiente. Y cuando llevas 45 minutos trabajando en la nueva, te das cuenta de que te habías olvidado de cambiar de rama.
No hay problema, guardas los cambios en un stash, cambias a master, creas la rama de la nueva issue (git branch -d nueva_issue) y aplicas el stash (git stash pop). Listo, ya tienes tu trabajo de la rama equivocada en la rama correcta. pop es como apply pero elimina el stash una vez usado.
Efectivamente Miguel, también se puede usar para eso y para muchas más cosas que se nos ocurran, es lo maravilloso de Git.
Un saludo.
Buenas
Nunca he usado git pero en cambio tengo bastante nivel con svn y por lo que he leido en estos dos articulos y en otros, tienen forma de trabajo diferentes pero se puede hacer lo mismo con uno y con otro, salvo lo que se pueda hacer con la "descentralizacion" de git, que como svn no tiene y mi cabeza esta amueblada para usar svn, no se me ocurren ni ventajas ni inconvenientes...
No escribo para defender o atacar a uno o a otro, en serio. LAs guerras de religion no me van. Son herramientas distintas que sirven para lo mismo y hoy usas una y si mañana tienes que usar la otra, pues te pasas un par de horas blasfemando y despues como si nada.
Pero aqui viene mi peticion y mi pregunta.
La peticion es que tras las capturas de pantalla de la shell (muy buenas, por cierto) añadas que tiempo mas o menos tardan enejecutarse los comandos. No hace falta exactitud. Un "instantanemente" o un "despues de un rato" o incluso un "aburra a las vacas" es suficiente. Para hacernos una idea de lo que es trabajar con git. He leido que es muy rapido.
Y la duda tiene que ver con los merges, que al fin y al cabo es lo que hace que trabajar en equipo con estas cosas sea un coñazo (aunque peor seria no tenerlas). ¿Git te puede hacer un merge el solito por su cuenta y riesgo? ¿Cuando decide que hay un conflicto? ¿Cuando dos han tocado el mismo fichero o cuando dos han tocado la misma linea de un fichero? Supongo que uses lo que uses, al final tendras que hablar con el programador con el que has colisionado para ponerte de acuerdo en los cambios.
Es que estuve viendo una presentacion de Linus Torvalds sobre git y hablaba de los merges como si fueran automaticos, diciendo que hacia cientos al dia, y sinceramente no entiendo como una herramienta puede hacerlos.
Gracias.
En git todos los comandos son instantáneos. Centésimas de segundo. Tan solo hacer push o pull/fetch pueden tardar, lo que tarde la conexión en enviar o recibir los datos. Si el commit es gordo gordo (normalmente por tener imágenes) puedes llegar a apreciar el segundo y medio que puede tardar la compresión antes de enviar un commit (se comprime en un tar), pero la gran mayoría de las veces es inapreciable.
Los merges muchas veces sí son automáticos. Git almacena diferencias entre archivos en diferentes momentos del tiempo (los commits). Si el archivo original tenía 200 líneas, y en la 122 ponía una cosa, y ahora pone otra, es esta última la que tiene validez. Si el programador añadió nuevo código entre la linea 48 y 49 (una función de 10 líneas por ejemplo, con lo cual ahora la 49 será la 59), git almacena solo esas 10 líneas y las introduce entre la 48 y la 49.
Este tipo de flujo no provoca colisiones. Las colisiones se resuelven automáticamente dando prioridad a los cambios más recientes (el HEAD).
Las colisiones puede venir cuando el programador A comenzó a trabajar sobre un fichero en un estado inicial. Otro programador B hizo lo mismo, sobre el documento en el mismo estado.
Uno de ellos acabará sus cambios antes que otro.
Esa persona no tendrá problemas para mezclar sus cambios cuando acabe. Cuando el programador B va a mezclar sus cambios, el fichero ya no está en el estado inicial del que él partió. Si en sus cambios modificó lineas diferentes que el programador A, tampoco tendrá colisiones, pero si ambos hicieron cambios sobre las lineas 49-58, no hay forma para git de saber cual de los dos cambios debe prevalecer. Cuando el programador B quiera hacer merge, todas las líneas que puedan mezcarse automaticamente lo harán, pero en la zona conflictiva se pondrán los dos códigos separados por unos comentarios, indicando cuales son de qué versión. Algo así:
<<<<<<<<< HEAD
def hello_world
say_hello + "world"
end
<<<<<<< ISSUE_PROGRAMADOR_B
def salute(who = world)
"hello " + who
end
>>>>>>>
En este caso, quien mergea tiene que manualmente decidir que fragmento es el que vale, y borrar el otro. Al acabar hace un commit nuevo con los cambios, y ya está.
-- editado por última vez a las 11:02
Iba a responderte pero veo que Miguel lo ha dejado bastante claro.
Un saludo.
Gracias por la respuesta. Veo que somos unos cuantos los que curioseamos por la web los sabados...
En cuanto al tiempo, tengo una duda. Por ejemplo, sin conocer git, el comando "git stash" como minimo tendra que revisar que esta modificado, que es recorrer el arbol de directorios, copiarlo a algun sitio para quitar de en medio lo cambiado y volver a copiar lo que se bajo en su momento. Recorrer el arbol de directorios y hacer las copias no puede llevar mucho tiempo, pero como minimo tiene que llevar mas tiempo que un "du", y los dus en algunos proyectos no son instantaneos. Y eso suponiendo que git guarde el fichero original que se bajo pra hacer comparaciones como hace svn y no se lo tenga que volver a bajar, que entonces habra que añadir tiempo de red. Por eso preguntaba lo de los tiempos, porque a veces creo que la gente o exagera con la velocidad de git o tiene proyectos pequeños (yo uso unos cuantos que generan un war de 60 Mb, gracias a usar todos los frameworks habidos y por haber en la blogocosa).
En cuanto al merge, veo que hace mas o menos como svn. Si puede mezcla y si no, pues avisa. Y el primero que le da al boton se queda con el commit.
Y en otro orden de cosas, ese comportamiento de hacer el merge automaticamente no me gusta, porque en un programa no hay lineas independientes. Si en una funcion el programador A añade en la linea 15 un "i++" y el programador B añade un "i++" en la linea 25, se hara el merge automaticamente, pero el resultado no es el que ninguno de los dos espera.
En fin, muchas gracias y espero siguientes articulos. Sobre todo alguno en el que se explique como se trabaja con un gestor descentralizado.
A mi el stash siempre me ha funcionado de forma inmediata lo mismo que el cambio de rama. No se a los demás.
interesante
En realidad no tiene que hacer todo eso. Los commits son inmutables y completos en sí mismos. En todo momento tienes disponible el local una copia de cada una de las imágenes/commits del proyecto a lo largo del tiempo. Cada commit contiene un puntero que apunta al siguiente commit.
Cuando vuelves a un estado anterior, la única operación que se realiza es la reasignación de un puntero, el HEAD de la rama en las que estás. Los archivos que están en la "lista de archivos" de HEAD, se ponen disponibles. Los que no, se ocultan. Pero en realidad no se mueven del sitio, siguen estando el el mismo lugar, pero ocultos. Este sistema es rapidísimo pero ocupa más espacio en disco duro. Pero normalmente los proyectos de programación, solo se hace tracking de los fuentes y algunas imágenes (y los archivos binarios no suelen cambiar). Todo lo que no interesa, como el archivo de la base de datos, los archivos compilados, los logs, ect, git los ignora (lo hace si le indicas cuales son en un fichero llamado .gitignore). Al final tener multiples copias de ficheros de texto plano no es una gran perdida de espacio.
Cuando se hace un stash, solo se copian los cambios a un commit igual que uno cualquiera. Es decir, se hace una copia de los ficheros que han cambiado desde el commit anterior, y se cambia un puntero.
La diferencia entre un stash y un commit es que, si consideramos la lista de commits como una estructura de árbol en que unos nodos "cuelgan" de otros, el stash es nodo suelto que no cuelga de la estructura, que "flota", esperando que apliques sus cambios. Es en el momento de aplicarlos cuando git compara los ficheros, obteniendo las diferencias (hace un diff) y esas diferencias se aplican. Pero no es una operación tan complicada como puede parecer. Los ficheros que se crean y se destruyen, no hay que analizarlos. Solo hay que ocultar los que se destruyen, y hacer visibles los que se crean. Solo los ficheros que se modifican necesitan análisis, y un commit cuantas lineas puede tener? Si tiene 2000 lineas ya es un commit enorme, y significa que probablemente estás trabajando mal, porque la idea es hacer commits frecuentemente. 2000 lineas git se las merienda, y de hecho, git no es tonto, si un archivo es grande, y los cambion superan un determinado umbral que no se cual es, pongamos un 70% de cambios, git cree conveniente considerarlo como que el fichero ha sido totalmente sobreescrito, así que ni siquiera lo procesa.
-- editado por última vez a las 16:04
Sabes mucho de como funciona git a nivel interno.
No sabía lo del puntero del HEAD. Muchas gracias por tus comentarios Miguel.
En realidad yo me llevaba MUY mal con git. La curva de aprendizaje de git no es un curva, es una pared vertical con la que darse de morros y romperse los dientes. Pero luego vi este screencast. http://pragprog.com/screencasts/v-jwsceasy/source-control-made-easy
Te enseñan git desde una perspectiva completamente diferente a todo tutorial que yo haya visto. El guion del screencast de 55 minutos es: - Vamos a crear un sistema de control de código fuente desde 0.
Lo va concibiendo paso a paso, de la formas más lógica y razonada. Paso a paso, cada decisión que toma parece evidente. Y al final del screencast, ves en retrospectiva lo que ha hecho y te dice: Pues esto que hemos creado ya existe, y se llama GIT.
Es de pago, vale unos 7€, pero de verdad que es un must-have en toda regla.
" Por eso preguntaba lo de los tiempos, porque a veces creo que la gente o exagera con la velocidad de git o tiene proyectos pequeños (yo uso unos cuantos que generan un war de 60 Mb, gracias a usar todos los frameworks habidos y por haber en la blogocosa)."
.
Hombre, teniendo en cuenta que se usa para el kernel de linux, no creo que sea por "proyectos pequeños", así que como mucho sería que la gente exagera. Y te aseguro que no es así.
"En cuanto al merge, veo que hace mas o menos como svn. Si puede mezcla y si no, pues avisa. Y el primero que le da al boton se queda con el commit."
.
No, no lo hace más o menos como svn. Lo hace muchísimo mejor. Hay que usarlo para creerlo, en serio
Svn trabaja considerando los cambios en un fichero o sistema de ficheros sobre el tiempo. Git trabaja a nivel de snapshots del filesystem completo, por lo que tiene una gran cantidad de información para hacer los merges.
Recientemente hemos hecho un merge de 3 ramas al master (digamos que es como el trunk en svn) y ha ido perfecto, y como han dicho, instantáneo.
En otra empresa en la que colaboro acabamos de migrar a git, y simplemente en lo que ganas en velocidad ya merece la pena. Y eso que en windows es ligeramente más lento que en mac o linux. Pues ha tardado 20 segundos en hacer el fetch inicial (por que resulta que el proyecto es grande y tiene un montón de ficheros binarios), y es lo único que ha tardado.
svn se tira entre 3 y 4 minutos para hacer un checkout del mismo proyecto.
En serio, cuando dicen que git es rápido, se quedan muy cortos.
"Y en otro orden de cosas, ese comportamiento de hacer el merge automaticamente no me gusta, porque en un programa no hay lineas independientes. Si en una funcion el programador A añade en la linea 15 un "i++" y el programador B añade un "i++" en la linea 25, se hara el merge automaticamente, pero el resultado no es el que ninguno de los dos espera."
.
Es que eso no es un problema de la gestión de versiones, es un problema de comunicación del equipo. Esos problemas pueden darse sin necesidad de hacer un merge.
-- editado por última vez a las 16:54
---borrado: no sabía que podían editarse los posts, sorry---
-- editado por última vez a las 16:55
En git no tienes por qué trabajar con un gestor descentralizado. La diferencia es que en vez de obtener una copia de trabajo del servidor, lo que obtienes es una copia del repositorio completo, es decir tienes toda la historia, ramas, tags, etc en una sola operación.
Sin embargo, al igual que en svn no puedes hacer commit sin actualizar, en git no puedes hacer push si tu repositorio local no está sincronizado con el repositorio remoto antes.
En pocas palabras, en git puedes trabajar de la misma manera que subversion, la diferencia es que todas las operaciones son locales, excepto cuando subas cambios al servidor.
De hecho git permite trabajar de más formas que subversion, aquí tienes algunos workflows:
http://progit.org/book/ch5-1.html
Un saludo!
¡Me estáis picando con git!, habrá que probarlo :D
Por otro lado, no me parece suficiente la respuesta: "es un problema de comunicación del equipo".
Las herramientas deben eliminar cualquier posibilidad de error (siempre que puedan, claro).
SVN, si detecta una posible ambigüedad, advertirá y pedirá confirmación al humano, puesto que él no es capaz de resolverla.
No conocemos el contexto del ejemplo del "i++" y probablemente cuando se aplique en un equipo estará pactado y/o git permitirá configurar el comportamiento, pero (en mi opinión), si git exige que esa incidencia esté pactada (¡y nadie se olvide!) por el equipo, me parece mala solución.
En cualquier caso, me ha enganchado el post más de lo que pensaba... :D
-- editado por última vez a las 13:03
Es un problema de comunicación desde el momento en que dos personas están tocando a la vez el mismo método, que es cuando se produciría el problema que presentas.
SVN no detecta ambiguedades, detecta líneas que han sido modificadas simultaneamente, al igual que git, y si no pueden resolverse habrá un conflicto.
Lo que git no hace es averiguar que dos personas distintas han metido la misma sentencia en el mismo método en dos líneas distintas. pero es que eso no te lo hace tampoco svn, ni ningún gestor de versiones, para empezar porque no es su trabajo.
Que puedas hacer muchas ramas no implica que en cada rama puedas tocar cualquier parte del código sin preguntar a nadie. De la misma manera el hecho de que hacer merges sea instantáneo, tampoco significa que de repente la integración sea mágica y elimine errores automáticamente, y para eso están los tests.
-- editado por última vez a las 16:01
Has comentado exactamente lo mismo (es decir, has dicho lo mismo que antes sin tener en cuenta mi comentario ¿?).
Lo que yo he dicho, es que las herramientas debe evitar cualquier error accidental y, en este caso, de eso se trata, que tú comentas que git no lo hace y yo dicho que svn sí (aunque supongo, como he dicho, que en git será configurable).
Yo no he dicho que SVN detecte que se ha modificado el mismo método (aparte que hablar de eso no tiene sentido, porque igual estamos modificando un archivo de configuración, que una hoja de estilos, etc...).
Lo que he dicho, es que se detecta una ambigüedad ¿cual?, ¡pues que no se puede determinar el orden de actuación de las modificaciones! (puesto que las modificaciones se han realizado en el mismo trozo de código y no hay información disponible [líneas previas, posteriores e implicadas] para realizar la inferencia de actuaciones).
Dada la ambigüedad, SVN solicita al (segundo) usuario que la resuelva.
¿Que el equipo se pone de acuerdo? ¡pues SVN no se quejará!.
¿Qué un usuario ha metido la pata, está distraído, etc...? ¡pues SVN le avisa y ¿git no?!.
A eso me refiero.
-- editado por última vez a las 19:25
"pues que no se puede determinar el orden de actuación de las modificaciones! (puesto que las modificaciones se han realizado en el mismo trozo de código y no hay información disponible [líneas previas, posteriores e implicadas] para realizar la inferencia de actuaciones)."
no entiendo lo que quieres decir con eso. ¿Podrías poner un ejemplo?
Como ya dije git actua a nivel de snapshots por lo cual puede acceder a toda la información disponible, y si mal no recuerdo, si es necesario retrodcede hasta un ancestro común en el árbol para saber el estado inicial y saber cómo aplicar los cambios.
Si lo que preguntas es si git resuelve las ambiguedades (aka conflictos) por su cuenta la respuesta es obviamente no.
"aparte que hablar de eso no tiene sentido, porque igual estamos modificando un archivo de configuración, que una hoja de estilos, etc..." Tanto da que da lo mismo. De todas maneras lo del método lo dije por lo de i++ :P
Saludos!
Otra cosa que se me pasó. Git tiene un comando para interactuar con un servidor svn, de forma que puedas trabajar con git en local y luego subir los cambios al repositorio svn
Eso si, no es recomendable trabajar al "estilo git" es decir, ni usando varios repositorios remotes, ni creando muchas ramas, por que puedes confundir a svn con la historia, pero si tu localmente usas git para tus cosas y luego subes una historia a svn que sea lineal, te puede servir para probarlo y evaluar su velocidad. Por ejemplo podrías usarlo para hacer commits locales y cuando todo funcione subirlo al svn, así consigues mantener un historial de cambios local, sin necesidad de subir cosas a svn que rompan la build (y ahorrarnos broncas del resto del equipo :P)
Aquí tienes más info por si te interesa: http://progit.org/book/ch8-1.html
[A] Código inicial:
int a = 3;
printf("%i",a);
[B] Usuario 1 modifica (desde A):
int a = 3;
a++;
printf("%i",a);
[C] Usuario 2 modifica (desde A):
int a = 3;
a <<= 1;
printf("%i",a);
Cuando "git" intente pasar de A a B no tiene problemas, pero al pasar de A a C habiendo actualizado B sí tiene problemas pues ¿cual de las dos líneas insertadas va primero? (entre otras posibilidades).
Desde mi punto de vista, independientemente que el equipo se ponga de acuerdo o no, la herramienta debe avisar que hay una ambigüedad.
-- editado por última vez a las 23:30
Eso no es una ambiguedad es un conflicto. Como ya he dicho, es gente cambiando el mismo código sin comunicación, lo que normalmente es un error.
También he dicho que aunque git sea muy eficiente gestionando ramas, los problemas básicos de editar simultaneamente un mismo código no van a desaparecer, no es mágico. Simplemente es más eficiente y rápido, pero no elimina el hecho de que cuando mezclas dos ramas tienes que juntar a la gente que se encarga de ello por si acaso han tocado código común.
En tu ejemplo, como se están modificando las mismas líneas se provocará un conflicto cuando B y C se mezclen en algún momento, y mostrará el típico diff de conflicto indicando las dos ramas que lo provocaron.
Este comportamiento es básico en un svc, no entiendo por qué crees que git no avisa de algo así.
Esto es lo que obtendrás si haces las operaciones que dices:
1 int a = 3;
2 <<<<<<< HEAD
3 a <<= 1;
4 =======
5 a++;
6 >>>>>>> origin/master
7 printf("%i",a);
En mi caso acabo de crear dos repos locales, el segundo clonado del primero (eso implica que automáticamente el segundo apuntará al primero como repositorio remoto)
Modifiqué los archivos en ambos repositorios, e hice commits en ambos repositorios, sin problema ni conflictos.
El conflicto apareció cuando desde el segundo repo (el clonado) hice un pull. Esa operacion obtiene los cambios del primer repositorio (fetch) y luego los aplica al repositorio actual (merge) produciendo el conflicto que te muestro arriba.
-- editado por última vez a las 01:27
"Eso no es una ambiguedad es un conflicto."
Coloquialmente, mi ejemplo, desde el punto de vista del repositorio es una ambigüedad (múltiples elecciones posibles, de hecho, siempre se puede generar un conjunto de resoluciones que incluyan la correcta, el problema es saber cual tomar), que supone un conflicto al gestor a la hora de intentar conciliar los cambios.
Las terminologías no aportan información si no se han pactado las definiciones primero.
"no entiendo por qué crees que git no avisa de algo así"
"jubete, 30 jul 2011 13:29" "...ese comportamiento de hacer el merge automaticamente no me gusta, porque en un programa no hay lineas independientes..."
Pero bueno, ya veo entonces que git sí advierte al programador del conflicto y él no realiza niguna acción cuando hay ambigüedades.
Gracias ;D
Lo que tu denominas ambigüedad es básicamente añadir una capa semántica a lo que desde hace muchos años se conoce como conflicto (conflict en inglés) que es un cambio en la misma línea que el gestor no puede resolver por si mismo.
Y digo que es una capa semántica más, por que si, existe ambigüedad al existir diferentes soluciones al conflicto pero no deja de ser añadir palabrería teórica; en el día a día se usa conflicto, tanto en cvs, svn, git o mercurial.
¡Pero si la diferenciación entre ambigüedad y conflicto la has hecho tú!
2 ago 2011 01:21 "Eso no es una ambiguedad es un conflicto."
Yo, desde el post "31 jul 2011 13:02" lo único que he dicho es que:
[*] caso de detectarse cualquier conflicto, la herramienta (git, svn, ...) debe avisar. Ahí, bastaba con decir: "sí, git te avisa (ya lo dijo Miguel en 30 jul 2011 11:00)".
Como yo había entendido (por el post "jubete, 30 jul 2011 13:29") que git no lo hacía, me extrañaba.
Gracias de todos modos por el esfuerzo de hacerme comprender.
;D
Escribir un comentario
Para hacer un comentario es necesario que te identifiques: ENTRA o conéctate con FacebookConnect