¿Git crea una rama desde el maestro actual verificado?

Hay una carpeta controlada por git en un servidor donde se extrae la rama principal y se ha modificado y no confirmado un montón de archivos. ¿Hay alguna forma de confirmar los cambios en una rama separada para poder volver a una versión limpia?

es decir, quiero deshacer eficazmente todos los cambios de esta persona, pero almacenarlos en otra oportunidad para que, si esa persona quiere sus cambios, pueda cambiar a esa rama.

(Sí, sé que no es así como git está diseñado para funcionar, ¡pero esa es mi situación!) Cualquier idea muy apreciada.

— corydoras
fuente

similar a < stackoverflow.com/questions/1394797/… >. y bueno, git funciona muy bien en tu caso, no diría que no está diseñado para tal flujo de trabajo. ¡es!

— Knittl

Solo para aclarar, espero que los cambios nunca se utilicen, pero necesito un registro permanente por si acaso.

— corydoras

Respuestas:

136

En primer lugar, moverse a una rama diferente basada en el HEAD actual se realiza así:

git checkout -b newbranch

Confirme todos los cambios (suponiendo que no haya archivos recién agregados, de lo contrario, git addellos):

git commit -a

Regrese a la rama maestra:

git checkout master

Los cambios no confirmados anteriormente estarán todos en la nueva rama y el maestro seguirá en el estado en el que estaba sin esos cambios.

— CB Bailey
fuente

Explicación: el contenido del repositorio de trabajo y los cambios por etapas no pertenecen a ninguna rama. La simple creación de una nueva rama de HEAD (última revisión) es suficiente para que la nueva confirmación vaya a la rama recién creada <newbranch>.

— Jakub Narębski

Gracias chicos, pensé que cambiar a una nueva rama podría borrar los cambios. Viniendo de un entorno SVN, no pensé que cambiar así fuera posible. Probándolo ahora.

— corydoras

Este método es útil:

git checkout -B <new_branch> <start point>

Dónde:

<new_branch> es su nueva rama (por ejemplo, my_branch )
<start point> es tu rama inicialmaster en tu caso)
-Bcrea una nueva rama a partir de <start point>, si ya existe, luego reiníciela a (no fallará como-b cuando la rama ya existe)
A veces -mpuede ser útil especificar al cambiar de rama, esto realizará una combinación de tres vías entre la rama actual, el contenido de su árbol de trabajo (útil para scripts).

Ver: man git-checkoutpara más detalles.

— Kenorb
fuente

Siempre puedes guardar tus cambios.

git stash
git checkout -b bravenewmaster
git stash apply

También tenga en cuenta que si se compromete con la rama "incorrecta", siempre puede mover esa rama hacia atrás, porque la rama no es más que un puntero a una confirmación.

— Michael Krelin - hacker
fuente

¿Por qué molestarse en guardar si va a volver a aplicar inmediatamente los mismos cambios? También puede hacerlo git checkout -b bravenewmaster. Es menos tipeo y no tocará todos los archivos modificados innecesariamente.

— CB Bailey

Bueno, no lo he intentado, pero asumí que gitpor alguna razón no deja git checkout -bcuando hay cambios. De lo contrario, ¿por qué preguntar? ;-)

— Michael Krelin - hacker

En realidad, por lo que puedo decir con "Quiero deshacer eficazmente todos los cambios de estas personas, pero almacenarlos en otra oportunidad para que, si esa persona quiere sus cambios, pueda cambiar a esa rama", comenta: solo guardarlo debería ser suficiente sin ramificaciones ni aplicaciones. .

— Michael Krelin - hacker

Si está almacenando los cambios (en lugar de "esconderlos" temporalmente), entonces probablemente sea más apropiado tener una confirmación (con un mensaje) en una rama con nombre que un alijo que no deba ser eliminado accidentalmente. Sin embargo, ambos funcionarían.

— CB Bailey

Por supuesto que no puedo entender completamente las intenciones de otras personas, pero tengo la sensación de que "Quiero trabajar en esta instancia, pero lo modificó muchísimo, ¿podría eludirlo y tratarlo usted mismo más tarde" ;-)

— Michael Krelin - hacker