Manejo de cambios temporales (no se comprometerán) en Git

A menudo, mientras trabajo en una sucursal, necesito introducir algunos cambios "temporales" (como información de debugging adicional o un cambio que me permite observar mejor en qué estoy trabajando realmente ).

Acerca de estos cambios "temporales":

  • Los quiero en mi copy de trabajo de mi sucursal , porque me ayudan a trabajar en el cambio real,
  • No quiero que se comprometan con la sucursal , porque la sucursal se fusionará en master alguna vez y no son códigos de producción.

Actualmente solo los mantengo como no configurados y los omito de forma manual al organizar cada confirmación. Sin embargo, no puedo quedarme con esta solución porque:

  • Todo el time tengo que recordar qué files necesito omitir,
  • Algún día voy a terminar con 2 cambios en un file, uno temporal, otro comprometido, y va a ser muy problemático.

¿Cómo debería lidiar con eso?


gitignore está obviamente fuera de cuestión porque no quiero ignorar todos los files y todavía estoy interesado en los cambios de otros committers (necesito volver a establecer la base de la twig para dominar de vez en cuando).

Normalmente trato de esto usando:

 git add -p 

… para escenificar los cambios hunk-by-hunk. Entonces solo tienes que asegurarte de presionar n para tus cambios de debugging.


Si tengo más cambios involucrados de este tipo, crearé una twig llamada algo así como local-changes con una confirmación en su punta que introduce el código de debugging. Después de crear algunos commits más, usaría:

 git rebase -i master 

… reorderarlos para que la confirmación con los cambios locales esté en la punta nuevamente. Luego, para actualizar el maestro y regresar a la twig de cambios locales, puede hacer:

 git checkout master git merge local-changes^ git checkout local-changes 

Pruebe git update-index --assume-unchanged <file> . De esta forma, git no agregará el file al índice cuando use git add o git commit -a .

EDITAR: Esto no le permite lidiar con el caso de tener un file con cambios temporales y permanentes.

Esta es una forma de lidiar con esto que, una vez configurada, solo requiere que recuerde un paso para configurarlo y un paso antes de cada inserción.

La puesta en marcha:

 git branch tempChanges [branch for temporary changes] [create your temporary changes] git add -A git commit 

Tenga en count el sha para ese compromiso. Luego cambie a su twig de trabajo, y:

 git cherry-pick shaOfTempChangesCommit 

Ahora tiene los cambios en su twig de trabajo. Haz tu trabajo y haz commits. Luego, antes de presionar:

 git rebase -i 

Verás algo como esto:

 pick bfd4d2e This first commit is your temporary changes. pick 186a99d Some stuff done on the working branch. pick ec871c6 More stuff done on the working branch. (etc.) 

Elimina la línea con tus cambios temporales. Luego guarda y sal. Su historia se reescribirá para excluir los cambios temporales. (Los cambios seguirán existiendo en la twig tempChanges ). Una vez hecho esto, haga las testings que necesite y luego git push .

Cuando esté listo para trabajar nuevamente, puede volver a colocar los cambios temporales en su twig de trabajo actual (o una nueva twig de trabajo):

 git cherry-pick shaOfTempChangesCommit 

Entonces, en resumen , todo lo que tiene que recordar en este método es

  • después de crear una twig de trabajo

    git cherry-pick shaOfTempChangesCommit

  • después de que haya terminado de trabajar y listo para empujar

    git rebase -i [para eliminar los cambios temporales antes de presionar]

Puedes usar

 git stash 

para savelo en un espacio temporal. Después de hacer su fusión, puede usar

 git stash pop 

para cargar sus cambios temporales en su directory de trabajo.

Usualmente pongo todo mi código de debugging en su propia confirmación, entonces antes de hacer la fusión, revert esa confirmación. He usado algunas variaciones de la mayoría de las otras respuestas a veces, pero me gusta esta por su simplicidad y por el hecho de que conserva mi historial de desarrollo. Sí, no quiero que mi código de debugging esté en el producto final, de ahí la revert , pero si la testing encuentra un problema, quiero poder restablecer ese código de debugging para seguir trabajando.

He encontrado una solución limpia a este problema: (perdón por mi asci-arte). Requiere una twig adicional para la twig de tema. (Esto tiene defectos y está siendo disputado / corregido, ver comentarios)

El trabajo se ve así inicialmente:

 master \ \ commit1 ---- commit2 ---- "branch" 

El trabajo se realiza en "twig".

Para introducir algunos cambios temporales:

  • crear una twig "branch-temp" desde "master"
  • cometer los cambios temporales allí
  • rebase "twig" de "maestro" a "twig-temperatura"

El repository ahora se ve así:

 master \ \ "branch-temp" ----- commit1 ---- commit2 ---- "branch" 

El trabajo ahora continúa felizmente en la sucursal y los cambios temporales no son visibles en el estado.

Para cambiar o extender los cambios temporales:

  • checkout branch-temp
  • commit –amend los cambios temporales allí – esto es incorrecto, ya que hace que "branch-temp" diverja

Para fusionar los cambios de twig a principal :

Esto es solo un poco más complicado. Queremos fusionarnos en todos los cambios, excepto en los cambios introducidos por "branch-temp". Mi idea es:

  • ejecutar una fusión normal de "twig" a "maestro"
    (ahora tenemos una fusión, pero con algunos cambios temporales innecesarios, eliminémoslos)
  • git revert –no-commit branch-temp
  • git commit – enmienda
    (estos dos pasos deben modificar la confirmación de fusión, para que ya no contenga los cambios de la temperatura de twig)

¿Qué pasa con la escritura de un sencillo script de shell que corregirá y deshará los cambios de debugging a petición (y luego lo hará como alias de git).

P.ej

 git apply-my-debug ... do coding ... git remove-my-debug git add . git commit -m "Don't worry about debug changes" 

Para evitar saturar el área de ensayo mientras crea una function, confirme sus cambios de debugging con una shiny advertencia intermitente de que no deberían pasar a la fusión final:

 #warning - DEBUG ONLY - DO NOT MERGE print(debugInfo) #warning - DEBUG ONLY - DO NOT MERGE 

Cuando esté listo para fusionar la sucursal, si se ha olvidado de ellos, usted o alguien más detectará estos cambios en la revisión del código de su request de extracción.

A continuación, tendrá diferentes forms de eliminar las confirmaciones de debugging:

  1. revert las confirmaciones de debugging específicas. Esto retendrá su historial en la twig.

  2. cherry-pick los buenos compromisos. Esto eliminará las confirmaciones de debugging por completo.

  3. Algo más complicado como rebase -interactive para eliminar los commits en el lugar.

Las funcionalidades ocultas de GIT proporcionan exactamente lo que estás pidiendo. Al less para la parte "mantener". Hacer la buena / mala selección al comprometerse no se puede evitar así.

Tiendo a mantener cambios no confirmados como ese. Simplemente siempre uso git add -i o git add -p para cambios de escenario (a less que esté seguro de querer todos los cambios que tenga el tree). De esa manera, reviso todos los cambios que quiero comprometer y omito fácilmente los temporales. También ayuda a realizar cambios que sabes que querrás cometer temprano y mantenerlos en escena o incluso cometerlos y luego agregar más cambios con git commit --amend .