Gestión de cambios de código estético en git

Question

Me parece que hago muchos pequeños cambios en mi código fuente, a menudo cosas que casi no tienen ningún efecto funcional. Por ejemplo:

• Mejorando o corrigiendo comentarios.
• Mover definiciones de funciones dentro de una clase para un orden de lectura más natural.
• Espaciando y alineando algunas declaraciones para facilitar la lectura.
• Colapsar algo utilizando varias líneas en una.
• Eliminación de una pieza antigua de código descompuesto.
• Corregir algunos espacios en blanco inconsistentes.

Supongo que tengo una formidable atención a los detalles en mi código. Pero el problema es que no sé qué hacer con estos cambios y hacen que sea difícil cambiar de rama, etc. en git. Me parece que no sé si cometer los cambios menores, esconderlos, o ponerlos en una rama separada de pequeños retoques y fusionar eso más tarde. Ninguna de esas opciones parece ideal.

El principal problema es que este tipo de cambios son impredecibles. Si tuviera que cometer esto, habría tantas confirmaciones con el mensaje "Cambio estético de código menor", porque, en el momento en que realizo tal compromiso, noto otro problema similar. ¿Qué debo hacer cuando hago un cambio menor, un cambio significativo y luego otro cambio menor? Me gustaría fusionar los tres cambios menores en un compromiso. También es molesto ver los archivos modificados en git status cuando el cambio apenas merece mi atención. Sé de git commit --amend, pero también sé que es una mala práctica, ya que hace que mi repo sea inconsistente con los controles remotos.

Answer 1

Por un lado, no creo que los cambios menores moderadamente frecuentes hagan mucho daño a nada ni a nadie. Siempre realizo pequeños cambios cosméticos de inmediato y en nuestro equipo, hemos acordado que solo usamos la palabra cosmética en nuestro mensaje de compromiso y eso es todo.

¡Lo que no recomendaría es comprometer cosméticos junto con otros cambios!

Por otro lado, si es un problema para usted y le gustaría cambiar algo, le sugiero que haga sesiones cosméticas donde arregle todo tipo de cosas de la lista que mencionó a la vez. También podría ser más eficiente concentrarse en los cosméticos solo en un determinado momento. De lo contrario, los cambios estéticos pueden convertirse en una actividad procrastinacional.

Answer 2

No creo que deba incluirlos con otros cambios "reales". Al hacerlo, es difícil revisar los cambios al fusionar sucursales.

Quizás su idea de mantener estos pequeños cambios en su propia sucursal tenga sus méritos.

Cuando estaba usando Perforce (con sus múltiples listas de cambios) podía mantener estas ediciones en una lista de cambios por separado hasta que tuve "suficiente" para justificar un check in. El registro contendría múltiples archivos y cada archivo podría tener múltiples diseños cambios pero no cambios "reales".

Answer 3

Creo que debe confirmar estos cambios individualmente con mejores mensajes de confirmación. En lugar de 'Cambio estético de código menor'. debe escribir algo como "Separación cambiada del encabezado en la sección X en la vista X".

Eso no te hará daño de ninguna manera.

Answer 4

En git, recuerde que hasta que presione (o publique) sus commits, puede editarlos como mejor le parezca. En su ejemplo, suponiendo que aún no haya impulsado su cambio principal, creo que estaría completamente justificado en fusionar los dos cambios menores. Si te preocupa contaminar la base de código principal, entonces puedes hacer tu trabajo, confirmando como de costumbre, y justo antes de presionar, edita las confirmaciones para que los cambios menores estén todos juntos como la confirmación más reciente, verifica si es lo suficientemente grande ser empujado y simplemente no empujar ese compromiso (todavía) si parece demasiado pequeño.

Answer 5

Sugiero mantenerlos separados y apegados a eso para que al menos los otros desarrolladores puedan fusionarlos sin demasiado miedo. :-) Tengo una tendencia a hacer lo que describes también.

Otra sugerencia que funciona es definir un formato estandarizado para el código y usar su IDE o algún otro proceso (compilación/checkin) para formatear automáticamente el código al guardar o registrar. Con eso, aún puede tener su propio formato localmente si es rebelde :-) pero luego todo el código se ve igual cuando está registrado.

Creo que git tiene la capacidad de definir los ganchos antes de la captura, pero también hay objetivos ant, plug-ins maven y funciones/complementos IDE que harán el formateo automático de una manera poco común.

Answer 6

¡Tienes suerte de estar usando git! Como han señalado otros, puede combinar cambios antes de enviarlos al repositorio. Este es uno de los mejores diferenciadores de git. Puedo caminar a pesar de que si se trabaja en una rama:

> git checkout dev # branch for work 
>> ... do some stuff 
> git commit -am 'cosmetic only 1' 
>> ... do some more stuff 
> git commit -am 'cosmetic stuff I missed last time' 
>> ... do some real stuff 
> git commit -am 'real work' 
> git checkout master && git pull && git checkout dev 
    # optional, if you repo is out of date 
> git rebase --interactive master 

En este punto se puede volver a organizar sus confirmaciones, y combinarlos juntos-- exactamente lo que quiere. Entonces, finalmente:

> git checkout master && git merge dev && git push && git checkout dev 

Así que los secretos son: capacidad

• de git para trabajar fácilmente en una rama
• conveniencia del git de comprobar en frecuencia
• la capacidad del GIT para editar confirmaciones que ya están en el sistema

Para ser sincero, generalmente no me preocupo tanto por el registro de commit. Solo busco en la historia pocas veces lo suficiente como para hacer que este tipo de mantenimiento valga la pena.

BTW Estoy seguro de que hay una forma de hacerlo si no trabajas en una sucursal, pero no lo sé. Aquí hay una referencia para trabajar en una rama: http://osteele.com/archives/2008/05/my-git-workflow