¿Cómo fusiono mis cambios locales no confirmados en otra rama de Git?
¿Cómo puedo hacer lo siguiente en Git?
Mi rama actual es rama1 y he realizado algunos cambios locales. Sin embargo, ahora me doy cuenta de que en realidad tenía la intención de aplicar estos cambios a la rama2. ¿Hay alguna manera de aplicar/combinar estos cambios para que se conviertan en cambios locales en la rama2 sin confirmarlos en la rama1?
Dado que sus archivos aún no están confirmados en branch1:
git stash
git checkout branch2
git stash pop
o
git stash
git checkout branch2
git stash list # to check the various stash made in different branch
git stash apply x # to select the right one
Arriba está la versión más larga y explícita de la respuesta de rbento :
git stash
git stash branch branch2
Usa:
git stash branch <branchname> [<stash>]
- Crea y verifica una nueva rama nombrada
<branchname>a partir de la confirmación en la que se<stash>creó originalmente.- aplica los cambios registrados en
<stash>el nuevo árbol de trabajo e índice.Si esto tiene éxito y
<stash>es una referencia del formulariostash@{<revision>}, entonces elimina el archivo<stash>.Esto es útil si la rama en la que ejecutó
git stash pushha cambiado lo suficiente como paragit stash applyfallar debido a conflictos.
Dado que la entrada oculta se aplica encima de la confirmación que era HEAD en el momentogit stashde la ejecución, restaura el estado oculto original sin conflictos.
Como comentó benjohn ( ver git stashpágina de manual ):
Para guardar también los archivos actualmente sin seguimiento (recién agregados), agregue el argumento
-u, por lo que:
git stash -u
El ocultamiento, las confirmaciones temporales y el cambio de base pueden ser excesivos. Si aún no ha agregado los archivos modificados al índice, es posible que pueda verificar la otra rama.
git checkout branch2
Esto funcionará siempre que ningún archivo que esté editando sea diferente entre la rama1 y la rama2. Lo dejará en la rama 2 con los cambios de trabajo conservados. Si son diferentes, puede especificar que desea fusionar sus cambios locales con los cambios introducidos al cambiar de sucursal con la -mopción de pagar.
git checkout -m branch2
Si ha agregado cambios al índice, primero querrá deshacer estos cambios con un reinicio. (Esto preservará su copia de trabajo, solo eliminará los cambios preparados).
git reset
Una alternativa más corta a la respuesta aceptada sería:
Mueva temporalmente los cambios a un alijo.
git stash
Crea y cambia a una nueva rama y luego introduce el alijo en ella en un solo paso.
git stash branch new_branch_name
Entonces solo addy commitlos cambios en esta nueva rama.
ADVERTENCIA: No para principiantes en git.
Esto aparece lo suficiente en mi flujo de trabajo que casi intenté escribir un nuevo comando git para ello. El flujo habitual git stashes el camino a seguir , pero es un poco incómodo. Por lo general, primero hago una nueva confirmación, ya que si he estado observando los cambios, toda la información está fresca en mi mente y es mejor simplemente comenzar git commita revisar lo que encontré (generalmente una corrección de error perteneciente a master que descubro mientras trabajo en un rama de funciones) de inmediato.
También es útil (si te encuentras con situaciones como esta con frecuencia) tener otro directorio de trabajo junto al actual que siempre tenga la
masterrama desprotegida.
Entonces, cómo logro esto es así:
git commitlos cambios de inmediato con un buen mensaje de confirmación.git reset HEAD~1para deshacer la confirmación de la rama actual.- (opcional) continúe trabajando en la función.
A veces más tarde (de forma asincrónica) o inmediatamente en otra ventana de terminal:
cd my-project-masterque es otro WD que comparte el mismo.gitgit reflogpara encontrar la corrección de error que acabo de hacer.git cherry-pick SHA1del compromiso.
Opcionalmente (aún asíncrono), puede cambiar la base (o fusionar) su rama de funciones para obtener la corrección de errores, generalmente cuando está a punto de enviar un PR y ya ha limpiado su rama de funciones y WD:
cd my-projectque es el WD principal en el que estoy trabajando.git rebase masterpara obtener las correcciones de errores.
De esta manera, puedo seguir trabajando en la función de forma ininterrumpida y no tener que preocuparme por git stashhacer nada o tener que limpiar mi WD antes de git checkout(y luego volver a verificar la rama de la función) y aún tener todas mis correcciones de errores masteren lugar de oculto en mi rama de funciones.
En mi opinión git stash, es git checkoutuna PIA real cuando estás trabajando en alguna característica importante.
Si se tratara de cambios confirmados, deberías echarle un vistazo a git-rebase, pero como lo señaló el comentario de VonC, como estás hablando de cambios locales, git-stash sin duda sería la buena manera de hacerlo.
