Supongo que permite mover los cambios de una rama a la siguiente, pero para eso está el picking de cerezas y, si no estás comprometiendo tus cambios, ¿no deberías moverlos?¿Por qué el alijo git no es único por rama?
En ocasiones he aplicado el alijo incorrecto en la rama incorrecta, lo que me dejó pensando acerca de esta pregunta.
Como se mencionó, si desea un "alijo por rama", realmente desea una nueva rama de bifurcación de la sucursal existente.
Además, además del hecho ya mencionado de que el escondite le permite pasar a una rama en la que está trabajando, también le permite cambiar las ramas antes de haber comprometido todo. Esto no es útil para el "cherry-picking" en el sentido habitual sino para el "cherry-picking" en su copia de trabajo.
F.ex., mientras trabajo en una rama de características, a menudo notaré errores menores o impurezas cosméticas en el código que no son relevantes para esa rama. Bueno, solo arreglo esos de inmediato. Cuando llega el momento de cometer, me comprometo selectivamente con los cambios relevantes, pero no con los arreglos y los cosméticos. En cambio, guardo esos, lo que me permite cambiar a mi rama de arreglos menores en establo, donde luego puedo aplicar el alijo y comprometer cada arreglo menor por separado. (Dependiendo de los cambios en cuestión, también esconderé algunos de ellos otra vez, para cambiar a una rama de función diferente, donde aplique esos.)
Esto me permite profundizar en el modo de programación cuando estoy trabajando, y no se preocupe por la adecuada biblioteconomía de mi código. Luego, cuando tomo un descanso mental, puedo regresar y ordenar cuidadosamente mis cambios en todos los estantes correctos.
Si el alijo no fuera global, este tipo de flujo de trabajo sería mucho más difícil de hacer.
No estoy de acuerdo con esto: 'Como se mencionó, si quiere un "alijo por rama", realmente quiere una nueva rama que se bifurque de la sucursal existente. En particular, a menudo cambio entre dos versiones del mismo programa, y ejecutar una 'marca' completa lleva 10 minutos; ser capaz de esconder los binarios construidos, por rama, sería muy agradable. Y ciertamente no quiero los binarios en el registro o en una rama. –
¿Por qué? (Creo que sí, simplemente no lo sabe). –
si quiere un "alijo" que se ejecuta en una sucursal, haga algo como esto para almacenar sus cambios en una nueva rama de su sucursal actual.
git checkout -b new_stash
git commit -a -m "stashed changes"
para deshacer el alijo
git reset HEAD^
git branch -d new_stash
git alijo es especialmente útil porque se puede tirar de cambios en un árbol sucio, es decir, si usted tiene ediciones pendientes y quieren hacer un
git pull
y no puede, puede ocultar sus cambios, extraer y luego aplicar el alijo
git stash
git pull
git stash apply
git stash clear
Espero que esto haya sido de ayuda.
¿Qué pasa si las cosas que intentas esconder son, por ejemplo, un montón de binarios que resultan de ejecutar 'make' en esa rama? (un alijo por rama ahorraría tiempo la próxima vez que haga una compilación incremental en esa rama, pero ciertamente no desea agregar los binarios al índice) –
git-stash me resulta más útil para mover los cambios aún no registrados a una rama diferente a la que está actualmente desprotegida.
Por ejemplo: a menudo me encuentro haciendo cambios simples en una rama de corrección de errores; solo para descubrir que un cambio en el que estoy trabajando es más complejo de lo que creía. Git-stash es la forma más fácil de mover ese conjunto de cambios a una rama diferente.
A partir de Git 1.6, ahora se puede aplicar a las sucursales usando stashes
git stash branch name_of_new_branch
Git creará la nueva rama para usted, y comprobar que funciona! Para obtener más información, consulte
info git-stash y la búsqueda de la opción = branch.
supongo que puede mover alrededor de usar stashes
git stash branch <branch | new_branch> [<stash>]
y para ver una lista de sus escondites, utilice
git stash list
¡Gracias! No sabía que podías aplicar escondites a las ramas, pero este parece ser el comportamiento después de todo. Al tener un alijo en una sucursal, revisé otra sucursal y trabajé allí. Al final resultó que necesitaba esconder algunos de sus cambios pendientes también antes de que pudiera volver a la base para dominar. Mi actualización "' gitk --all' "ya no mostró mi primer alijo; Pensé que podría ser golpeado. Después de terminar mi trabajo en la segunda sucursal, extraje ese alijo. Después de eso, mi actualización "' gitk --all' "mostró nuevamente el alijo original. –
Git le falta algo, que le permite asociar cambios no confirmados con una bifurcación (o cabecera). Esto se hace evidente cuando tienes trabajo en progreso para más de una rama a la vez. Como las respuestas aquí señalan, stash tiene aplicaciones útiles basadas en sus características, no obstante. 'git stash-here' ¿alguien? –