Deshacer cambios temporales con Git

Diga, estoy en 'maestro' y tengo una burbuja:

DEBUG = FALSE CACHE_SIZE = 100 code code code 

Ahora empiezo a depurar en una nueva twig …

 DEBUG = TRUE # Don't forget to turn off! CACHE_SIZE = 0 # Don't forget to set back to 100! 

… corregir algunos errores, cambiar algún código … y fusionar mis correcciones en 'maestro'. Pero lamentablemente he olvidado devolver estos "no olvidar" -s al valor original.

¿Cómo puedo automatizar el process de devolver algunas líneas al valor original? O al less acortarlo a un solo command.

Tal vez, algún compromiso temporal, o escondite, o alguna otra técnica?

Cameron tiene algunas buenas ideas para cambios de debugging a corto ploop. Quería agregar uno común que funcione incluso para sets más grandes o más permanentes de cambios de debugging locales, como si habitualmente realizara los mismos cambios de "no olvidar" cada vez que agrega una function. Lo he oído llamar un telar, una colcha, twigs astackdas y una tubería. Puede encontrar complementos con esos nombres para ayudar a mantener este tipo de flujo de trabajo, pero hay sutiles diferencias entre ellos que nunca he captado realmente, y la técnica no es demasiado difícil de hacer manualmente.

La idea básica es agregar otra twig entre maestro y característica , llamémosla debugging . Realiza todos los cambios "no olvidar" en esa twig, luego se bifurca nuevamente desde la function de debugging hasta hacer, que contiene todos los cambios que entrarán en producción de forma normal. Luego, para eliminar todos los cambios de "no olvidar" en la function , haga lo siguiente:

 git rebase --onto master debug feature 

Eso hace que parezca que usted se ramificó directamente desde el maestro y nunca agregó los cambios en la twig de debugging . Entonces te fundes en el maestro como lo normal. La próxima vez que quiera agregar una function, simplemente fusionará el maestro en la debugging y sus cambios de "no olvidar" se volverán a aplicar automáticamente al último código en sentido ascendente. Luego solo crea una nueva twig de características desde la debugging y el ciclo comienza de nuevo.

Obviamente, todavía tienes que recordar hacer la rebase antes de fusionarte en master . La idea del gancho de Cameron se puede usar para evitar fusiones si lo olvida.

Probablemente no haya forma de automatizar la reversión de líneas particulares (ya que Git realmente no tiene ningún conocimiento de la semántica del contenido del file), pero hay varias forms en que puede evitar que esto vuelva a ocurrir en el futuro.

  1. Asegúrese de inspeccionar siempre los diffs antes de comprometerse. git diff /path/to/file le mostrará los cambios y puede search "No te olvides de …".
  2. Puedes automatizar esto un poco con grep: git diff | grep "Don't forget" git diff | grep "Don't forget"
  3. Incluso podría tener un gancho que verifica una expresión regular (por ejemplo, "No olvidar") y prohíbe los commits que coincidan. Esto podría estar en su repository local o en el repository al que está presionando.

La opción 2 es probablemente la más fácil. Todavía requiere un poco de disciplina: debes asegurarte de poner siempre "No olvides" (o "TODO", o "FIXME" o lo que sea) en el comentario y debes ejecutar git diff | grep git diff | grep , pero eso no es demasiado caro.

La opción 3 facilitará a largo ploop la prevención de este problema, especialmente si usted es parte de un equipo. Por supuesto, cualquiera puede cambiar el comentario a "No olvidar" (o simplemente eliminar el comentario por completo) y omitir el control, pero es mejor que nada.

Algunos usuarios evitan el índice de Git (por ejemplo, siempre usando git commit -a y solo usando git add para introducir nuevos files), pero el índice me resulta bastante útil para casos como este.

La idea es nunca comprometer sus cambios de "debugging" en primer lugar.

  1. git diff para revisar los cambios que puedo realizar (es decir, la diferencia entre el índice y el tree de trabajo).

    1. Para los files que no tienen ningún cambio de "debugging", yo uso

       git add <pathspec> … 

      para escenificar los cambios a esos files.

    2. Si algunos files tienen "debugging" y cambios previstos, entonces yo uso

       git add -p <pathspec> … 

      en esos files para omitir todos los trozos de "debugging".

      Si un trozo tiene tanto "debugging" como los cambios previstos, entonces utilizo los commands de split y / o edición en git add -p para representar solo los cambios previstos.

  2. Antes de comprometerme, uso git diff --cached para revisar cuidadosamente los cambios por etapas (es decir, la diferencia entre HEAD y el índice).

    • Si un cambio de "debugging" lo convirtió en el índice final, entonces uso

       git reset -p <pathspec> … 

      (posiblemente utilizando sus commands de split o edición) para descartar los cambios de "debugging" del índice.


Nota: Si realiza testings directamente desde su tree de trabajo de "debugging", debe tener en count que siempre está probando con los cambios de "debugging" en su lugar. En algunas bases de código, la presencia de ciertos cambios de "debugging" puede cambiar significativamente el comportamiento del sistema bajo testing. Si es importante para su equipo que ninguna confirmación publicada falle alguna vez en una testing, entonces debe tomarse el time para probar exactamente lo que ha confirmado (sin los cambios de debugging).

Puedes usar git stash después de cada commit para esconder tus cambios de "debugging", rebuild y probar exactamente lo que has cometido. Una vez que la testing haya finalizado, puede git stash pop para restaurar sus cambios de "debugging" en su tree de trabajo.


git reset -p estaba primero disponible en Git 1.6.5 (también git checkout -p y git stash -p ). git add -p estuvo primero disponible en Git 1.5.4.