Incluyendo accidentalmente cambios no relacionados en confirmaciones

Mi enfoque personal para un git commit es que cada commit debe incluir una unidad de cambio , en su totalidad.

Cuando desarrollo, generalmente me concentro en tales unidades. Pero a veces, mi atención se desvía en otro lugar y trabajo por un tiempo en una unidad diferente. Esto probablemente no sea óptimo, pero he aprendido a comprometerme con cuidado ( git add --interactivees un buen amigo mío).

Sin embargo, podría suceder que me olvide de organizar selectivamente mis cambios y, en su lugar, confirme todo el archivo, creyendo que todos los cambios que veo en la diferencia están realmente relacionados con la misma unidad, a pesar de que puede haber un cambio o dos completamente no relacionados.

Entonces yo git push.

¿Es esto peligroso? ¿Debería hacer un esfuerzo para enmendar el commit para que solo incluya los cambios previstos? Mi principal preocupación es que quien vea el historial vea el cambio y probablemente se rasque la cabeza durante varios minutos antes de darse cuenta de que es muy probable que sea un error. Peor aún, me imagino que el cambio incluso se verá relacionado y el programador podría no reconocer el error.

El problema es que, como ya lo he presionado, no puedo reescribir con seguridad el historial del servidor, por lo que probablemente primero deba revertir la confirmación, dividirla correctamente y volver a confirmar. Alternativamente, podría enmendar el commit con un mejor mensaje de commit, pero tendría que ser realmente rápido ya que también requiere reescribir el historial. Como último recurso, podría simplemente confirmar la unidad en la que estaba trabajando como siguiente, dejando una nota de que hay un cambio relacionado en la confirmación anterior (pero esto se siente mal).

Entiendo que en una configuración de múltiples desarrolladores con un flujo de trabajo de revisión de código adecuado, esto probablemente no sucederá. También entiendo que si soy el único desarrollador de un proyecto, reescribir el historial es la mejor solución para esto.

La historia de compromiso es de vital importancia, pero por 3 razones:

1. fusionándose a otro lugar. Necesitas sacar las piezas de una rama y pegarlas en otro lugar, es importante tener todas las piezas que quieras allí y nada que no quieras. Entonces, si su confirmación 'desordenada' contiene cambios destinados a la función en la que está trabajando (y no, digamos una confirmación accidental de otra cosa), entonces está bien.
2. Auditar lo que sucedió en algún momento posterior, generalmente para determinar cuándo se introdujo un error o característica particular. En este caso, no importa lo que haya en las confirmaciones siempre que pueda identificar el cambio que le interesa.
3. Revisión de código. Las buenas revisiones de pares se comprometen y luego se revisan (¡no demore el proceso de desarrollo / confirmación esperando a un revisor!) Y en estos casos el revisor querrá comprender qué cambios se realizaron. Sin embargo, en general, un revisor estará más interesado en los cambios generales: tratar de revisar los compromisos realizados, revertidos, re-realizados es un ejercicio de pérdida de tiempo en comparación con la revisión de los 3 compromisos a la vez.

Por lo tanto, aunque los compromisos de unidad de trabajo suenan ideales, no hay nada en lo que insista en términos prácticos. Intentaría mantener los compromisos razonables, y la unidad de trabajo es una buena manera de mantener los compromisos sanos, pero no se moleste en tratar de jugar con el historial de compromisos solo para mantener los compromisos ordenados. Es como actualizar un archivo de código para que todos los corchetes se alineen de la manera que prefiera: agradable, pero inútil.

Ahora, si ha comprometido un poco de trabajo destinado a una rama diferente, revísela y comprométala adecuadamente a la rama correcta. Eso es importante, pero si ha actualizado un poco de código de servidor cuando ha estado trabajando en la GUI ... no hay necesidad de preocuparse por eso.

Cuando esto sucede, no es un gran problema simplemente revertir el cambio en la próxima confirmación. Agregar un mensaje de confirmación adecuado ( Removing the XYZ that I accidentally added in C92A891) será suficiente para que otros desarrolladores lo entiendan en la revisión de código.

En lugar de preocuparse por arreglar cualquier incidente específico, trate de evitar la situación en primer lugar.

Este es el verdadero asunto:

Sin embargo, podría suceder que me olvide de organizar selectivamente mis cambios y, en cambio, confirme todo el archivo

Debes acostumbrarte a nunca comprometer un archivo completo (¡o lo peor de todo tu espacio de trabajo!). Siempre cometa línea por línea o por un Hunk completo que haya examinado.

Cuando se compromete de esta manera (lo que parece que está haciendo la mayor parte del tiempo), los cambios inadvertidos son mucho menos propensos a colarse en sus confirmaciones.

Parece que tiene un repositorio local en su computadora y un repositorio compartido con sus compañeros de trabajo en un servidor. ¿Por qué solo tiene un repositorio en su computadora local? Por lo general, tengo al menos cinco, por lo que puedo trabajar en una cosa en un repositorio, corregir un error en otro sin tocar el primer repositorio, que podría estar en un estado incompleto, y así sucesivamente.