Accidentalmente, incluyendo cambios no relacionados en las confirmaciones

8

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

Cuando me desarrollo, usualmente me enfoco en tales unidades. Pero a veces, mi atención se desvía hacia otro lugar y trabajo por un tiempo en una unidad diferente. Probablemente esto no sea óptimo, pero he aprendido a comprometerme con cuidado ( git add --interactive es un buen amigo mío).

Sin embargo, podría suceder que me olvide de poner en escena mis cambios de forma selectiva y de cometer todo el archivo, creyendo que todos los cambios que veo en el diff están relacionados con la misma unidad, aunque podría haber un cambio o dos completamente sin relación.

Entonces yo git push .

¿Es esto peligroso? ¿Debería hacer un esfuerzo para modificar el compromiso de modo que solo incluya los cambios previstos? Mi principal preocupación es que quienquiera que mire la historia verá el cambio y probablemente se rascará la cabeza durante varios minutos antes de darse cuenta de que es muy probable que sea un error. Peor aún, puedo imaginar que el cambio se verá incluso relacionado y que el programador podría no reconocer el error.

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

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

    
pregunta Robert Rossmann 04.06.2015 - 16:19

3 respuestas

9

La historia de confirmación es de vital importancia, pero por 3 motivos:

  1. fusionarse en otro lugar. Necesitas recoger las piezas de una rama y pegarlas en otra parte, es importante tener todas las piezas que deseas y nada que no quieras. Entonces, si su compromiso 'desordenado' contiene cambios destinados a la función en la que está trabajando (y no, digamos un compromiso accidental de otra cosa), entonces está bien.
  2. Auditar lo que sucedió algún tiempo después, generalmente para determinar cuándo se introdujo un error o una característica en particular. En este caso, no importa lo que haya en las confirmaciones siempre que pueda identificar el cambio en el que está interesado.
  3. Revisión de código. Las buenas revisiones por pares se realizan y luego se revisan (¡no retenga 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 las confirmaciones realizadas, revertidas, repetidas es un ejercicio de pérdida de tiempo en comparación con la revisión de las 3 confirmaciones a la vez.

Por lo tanto, aunque la unidad de trabajo compromete el ideal de sonido, no hay nada en lo que insistir en términos prácticos. Intentaría mantener los compromisos sensibles, 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 paréntesis se alineen de la forma que prefieras: agradable, pero inútil.

Ahora, si ha realizado un poco de trabajo destinado a una rama diferente, revertirlo y asignarlo correctamente a la rama correcta. Eso es importante, pero si has actualizado un poco de código de servidor cuando has estado trabajando en la GUI ... no tienes que preocuparte por eso.

    
respondido por el gbjbaanb 04.06.2015 - 16:47
1

Cuando esto sucede, no es un gran problema simplemente revertir el cambio en el próximo compromiso. 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 del código.

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

Este es el problema real:

  

Sin embargo, podría suceder que me olvide de poner en escena mis cambios de forma selectiva y en lugar de confirmar todo el archivo

Debes acostumbrarte a nunca cometer un archivo completo (o, lo que es peor, ¡a toda tu área de trabajo!). Siempre cometa línea por línea o por un Hunk completo que haya examinado.

Al cometer de esta manera (lo que parece que estás haciendo la mayor parte del tiempo) es mucho menos probable que se introduzcan cambios inadvertidos en tus compromisos.

    
respondido por el pkamb 18.02.2016 - 22:52
0

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? Normalmente tengo al menos cinco, por lo que puedo trabajar en una cosa en un repositorio, corregir un error en otra sin tocar el primer repositorio, que podría estar en un estado incompleto, y así sucesivamente.

    
respondido por el gnasher729 14.06.2015 - 08:35

Lea otras preguntas en las etiquetas