Hay un montón de formas diferentes dependiendo de qué tan avanzado esté y en qué rama (s) las quiere.
Tomemos un error clásico:
$ git checkout master
... pause for coffee, etc ...
... return, edit a bunch of stuff, then: oops, wanted to be on develop
Así que ahora desea que estos cambios, los cuales aún no se han comprometido a master
, para estar en develop
.
Si aún no tiene uno develop
, el método es trivial:
$ git checkout -b develop
Esto crea una nueva develop
rama a partir de donde sea que esté ahora. Ahora puedes comprometerte y todo lo nuevo está listo develop
.
Usted tienen una develop
. Vea si Git le permitirá cambiar sin hacer nada:
$ git checkout develop
Esto tendrá éxito o se quejará. Si tiene éxito, ¡genial! Solo comprométete. Si no ( error: Your local changes to the following files would be overwritten ...
), todavía tiene muchas opciones.
La más fácil es probablemente git stash
(como postdijeron todos los otros contestadores que me ganaron a hacer clic ). Ejecutar git stash save
o git stash push
, 1 o simplemente, git stash
que es la abreviatura desave
/ push
:
$ git stash
Esto confirma su código (sí, realmente realiza algunas confirmaciones) utilizando un método extraño que no es de ramificación. Las confirmaciones que realiza no están "en" ninguna rama, sino que ahora se almacenan de forma segura en el repositorio, por lo que ahora puede cambiar de rama y luego "aplicar" el alijo:
$ git checkout develop
Switched to branch 'develop'
$ git stash apply
Si todo va bien y le gustan los resultados, entonces debería git stash drop
guardarlos. Esto elimina la referencia a los extraños commits no-branch-y. (Todavía están en el repositorio, y a veces se pueden recuperar en una emergencia, pero para la mayoría de los propósitos, debe considerar que desaparecieron en ese momento).
El apply
paso fusiona los cambios escondidos, utilizando la poderosa maquinaria de fusión subyacente de Git, el mismo tipo de cosas que utiliza cuando realiza fusiones de ramas. Esto significa que puede obtener "conflictos de fusión" si la rama en la que estaba trabajando por error es lo suficientemente diferente de la rama en la que desea trabajar. Por lo tanto, es una buena idea inspeccionar los resultados cuidadosamente antes de asumir que el alijo se aplicó limpiamente, incluso si Git no detectó ningún conflicto de fusión.
Mucha gente usa git stash pop
, que es abreviatura para git stash apply && git stash drop
. Eso está bien en lo que respecta, pero significa que si la aplicación resulta en un desastre y decides que no quieres seguir por este camino, no puedes recuperar el alijo fácilmente. Es por eso que recomiendo por separado apply
, inspeccionar los resultados, drop
solo si / cuando esté satisfecho. (Por supuesto, esto introduce otro punto en el que puede tomar otro descanso para tomar un café y olvidar lo que estaba haciendo, regresar y hacer lo incorrecto , por lo que no es una cura perfecta).
1 El save
in git stash save
es el antiguo verbo para crear un nuevo alijo. La versión 2.13 de Git introdujo el nuevo verbo para hacer las cosas más consistentes pop
y para agregar más opciones al comando de creación. La versión 2.16 de Git desaprobó formalmente el verbo antiguo (aunque todavía funciona en Git 2.23, que es la última versión en el momento en que estoy editando esto).
git stash
git-scm.com/book/en/Git-Tools-Stashing