Pregunta ¿Cómo fusionar mis cambios locales no confirmados en otra rama de Git?


¿Cómo puedo hacer esto en git?

Mi rama actual es branch1 y realicé algunos cambios locales. Sin embargo, ahora me doy cuenta de que en realidad quería aplicar estos cambios a branch2. ¿Hay alguna forma de aplicar / fusionar estos cambios para que se conviertan en cambios locales en branch2 sin comprometerlos en branch1?


546
2018-02-17 14:02


origen


Respuestas:


Dado que sus archivos aún no están comprometidos 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

Como se comentó por benjohn (ver git stash página man)

Para esconder también archivos actualmente sin seguimiento (recién agregados), agregue el argumento -u, asi que:

git stash -u

809
2018-02-17 14:16



El almacenamiento, las confirmaciones temporales y las modificaciones pueden ser excesivas. Si aún no ha agregado los archivos modificados al índice, entonces puede simplemente ingresar a la otra rama.

git checkout branch2

Esto funcionará siempre que ningún archivo que esté editando sea diferente entre branch1 y branch2. Te dejará en la rama2 con tus cambios de trabajo conservados. Si son diferentes, puede especificar que desea fusionar sus cambios locales con los cambios introducidos al cambiar de rama con el -m opción para pagar.

git checkout -m branch2

Si ha agregado cambios al índice, primero querrá deshacer estos cambios con un reinicio. (Esto conservará su copia de trabajo, simplemente eliminará los cambios por etapas).

git reset

78
2018-02-17 19:53



Aquí hay una alternativa más corta al enfoque de ocultación antes mencionado:

Mueva temporalmente los cambios a un escondite.

git stash 

Cree y cambie a una nueva sucursal y, a continuación, extraiga el alijo en un solo paso.

git stash branch new_branch_name

Entonces add y commit los cambios a esta nueva rama


9
2017-08-23 05:46



ADVERTENCIA: No para git novatos.

Esto aparece lo suficiente en mi flujo de trabajo que casi he tratado de escribir un nuevo comando git para ello. Lo normal git stash el flujo es el camino a seguir pero es un poco incomodo Normalmente hago un nuevo compromiso primero desde si he estado mirando los cambios, toda la información está fresca en mi mente y es mejor comenzar git commit-lo que encontré (por lo general, una corrección de error perteneciente al maestro que descubrí mientras trabajaba en una rama de características) de inmediato.

También es útil, si te encuentras en situaciones como esta mucho, tener otro directorio de trabajo junto a su actual que siempre tienen el master rama desprotegida

Entonces, cómo logro esto es así:

  1. git commit los cambios de inmediato con un buen mensaje de compromiso.
  2. git reset HEAD~1 para deshacer la confirmación de la rama actual.
  3. (opcional) continúe trabajando en la función.

A veces más tarde (asincrónicamente), o inmediatamente en otra ventana de terminal:

  1. cd my-project-master que es otro WD que comparte el mismo .git
  2. git reflog para encontrar la corrección de errores que acabo de hacer.
  3. git cherry-pick SHA1 del compromiso.

Opcionalmente (aún asíncrono) puede volver a establecer una base (o fusionar) su rama de características para obtener la corrección de errores, generalmente cuando está a punto de enviar un RP y ya ha limpiado su rama de características y WD:

  1. cd my-projectcuál es el WD principal en el que estoy trabajando.
  2. git rebase master para obtener las correcciones de errores.

De esta forma puedo seguir trabajando en la función ininterrumpidamente y no tener que preocuparme por git stashhacer cualquier cosa o tener que limpiar mi WD antes de una git checkout (y luego tener el cheque de la rama de la función de retroceso de nuevo.) y todavía tienen todas mis correcciones de errores va a master en lugar de estar oculto en mi rama de características.

IMO git stash y git checkout es una verdadera PIA cuando estás en el medio de trabajar en alguna gran característica.


7
2018-04-08 08:22



Si se tratara de cambios comprometidos, deberías echar un vistazo a git-rebase, pero como se señala en el comentario de VonC, ya que estás hablando de cambios locales, git-stash sin duda sería la mejor manera de hacerlo.


2
2018-02-17 14:04



Las respuestas dadas hasta ahora no son ideales porque requieren mucho trabajo innecesario resolviendo conflictos de fusión, o hacen demasiadas suposiciones que a menudo son falsas. Esta es la forma de hacerlo a la perfección. El enlace es a mi propio sitio.

Cómo comprometerse con una rama diferente en git

Tiene cambios sin compromiso en my_branch a quien quieres comprometerte master, sin comprometer todos los cambios de my_branch.

Ejemplo

git merge master
git stash -u
git checkout master
git stash apply
git reset
git add example.js
git commit
git checkout .
git clean -f -d
git checkout my_branch
git merge master
git stash pop

Explicación

Comience por fusionarse master en su sucursal, ya que de todos modos tendrá que hacerlo eventualmente, y ahora es el mejor momento para resolver cualquier conflicto.

los -u opción (aka --include-untracked) en git stash -u le impide perder archivos no rastreados cuando lo hace más tarde git clean -f -d dentro master.

Después git checkout master es importante que NO lo hagas git stash pop, porque necesitarás este escondite más tarde. Si sacas el alijo creado en my_branch y luego hacer git stash en master, provocará innecesarios conflictos de fusión cuando más tarde aplique ese alijo en my_branch.

git reset desestabiliza todo lo que resulta de git stash apply. Por ejemplo, archivos que se han modificado en el escondite pero que no existen en master organizarse como conflictos "eliminados por nosotros".

git checkout . y git clean -f -d descartar todo lo que no está comprometido: todos los cambios en los archivos rastreados y todos los archivos y directorios no rastreados. Ya están guardados en el alijo y si se dejan en master causaría innecesarios conflictos de fusión al volver a my_branch.

El último git stash pop se basará en el original my_branch, y por lo tanto no causará ningún conflicto de fusión. Sin embargo, si su escondite contiene archivos no rastreados que se ha comprometido a dominar, git se quejará de que "No se pudieron restaurar los archivos no rastreados del alijo". Para resolver este conflicto, elimine esos archivos de su árbol de trabajo, luego git stash pop, git add .y git reset.


1
2017-08-15 06:41