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.