El stashing, las confirmaciones temporales y el rebasing pueden ser excesivos. Si aún no ha agregado los archivos modificados al índice, entonces es posible que pueda simplemente verificar la otra rama.

git checkout branch2

Esto funcionará siempre y cuando ningún archivo que esté editando sea diferente entre branch1 y branch2. Te dejará en branch2 con los cambios de trabajo preservados. Si son diferentes, puede especificar que desea combinar sus cambios locales con los cambios introducidos cambiando ramas con la opción -m para 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, simplemente eliminará los cambios por etapas.)

git reset

Aquí hay una alternativa más corta al enfoque de alijo anteriormente mencionado:

Mover temporalmente los cambios a un alijo.

git stash

Cree y cambie a una nueva rama y luego haga estallar el alijo en un solo paso.

git stash branch new_branch_name

Luego add y commit los cambios a esta nueva rama.

ADVERTENCIA: No es para los novatos de git.

Esto aparece lo suficiente en mi flujo de trabajo que casi he intentado escribir un nuevo comando git para él. El flujo habitual git stashes el camino a seguir pero es un poco incómodo. Normalmente hago un nuevo commit primero desde si he estado mirando los cambios, toda la información está fresca en mi mente y es mejor simplemente comenzar git commit - ing lo que encontré (generalmente una corrección de error perteneciente a master que descubro mientras trabajo en una característica branch) de inmediato.

También es útil-si se encuentra con situaciones como esta mucho-tener otro directorio de trabajo junto con el actual que siempre tenga la rama master comprobada.

Así que cómo logro esto es así: {[19]]}

1. git commit los cambios de inmediato con un buen mensaje de confirmación.
2. git reset HEAD~1 para deshacer la confirmación de la rama actual.
3. (opcional) continuar trabajando en el 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 error que acabo de hacer.
3. git cherry-pick SHA1 del commit.

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

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

De esta manera puedo seguir trabajando en la característica sin interrupciones y no tener que preocuparse por git stash-ing nada o tener que limpiar mi WD antes de un git checkout (y luego tener el check the feature branch backout de nuevo.) y todavía tengo todas mis correcciones de errores va a master en lugar de 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.

Si se tratara de cambios confirmados, debería echar un vistazo a git-rebase, pero como se señaló en el comentario de VonC, ya que está hablando de cambios locales, git-stash sería sin duda la buena manera de hacer esto.

Las respuestas dadas hasta ahora no son ideales porque requieren mucho trabajo innecesario para resolver conflictos de fusión, o hacen demasiadas suposiciones que con frecuencia son falsas. Así es como se hace perfectamente. El enlace es a mi propio sitio.

Cómo hacer Commit a una rama diferente en git

Tiene cambios sin confirmar en my_branch que desea confirmar en master, sin confirmar todos los cambios desde 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

Comienza fusionando master en tu rama, ya que tendrás que hacerlo eventualmente de todos modos, y ahora es el mejor momento para resolver cualquier conflicto.

La opción -u (también conocida como --include-untracked) en git stash -u evita que pierda archivos no rastreados cuando luego haga git clean -f -d dentro de master.

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

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

git checkout . y git clean -f -d descartar todo lo que no está confirmado: 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 conflictos de fusión innecesarios al volver a my_branch.

El último git stash pop se basará en el my_branch original, por lo que no causará ningún conflicto de fusión. Sin embargo, si tu stash contiene archivos no rastreados que has confiado a master, git se quejará de que "No pudo restaurar archivos no rastreados desde stash". Para resolver este conflicto, elimine esos archivos del árbol de trabajo y, a continuación,git stash pop, git add ., y git reset.