git - remove - ¿Vale la pena el esfuerzo de crear un bonito historial de revisión en un DVCS?
git tag commit id (5)
Me esfuerzo por limpiar mi historial de revisión. Mi flujo de trabajo sigue las líneas de hacer una edición pequeña pero significativa, confirmar, repetir hasta que se realicen algunas series de modificaciones más grandes. Luego vuelvo atrás y reorganizo / agrupo los compromisos en compromisos atómicos funcionales, y elimino los compromisos revisados. Esto permite que otros desarrolladores vean confirmaciones que crean diferencias funcionales, en lugar de muros masivos de compromisos triviales. Facilita la depuración de regresiones cuando ocurren.
Solía volver y editar mis commits de Mercurial para tratar de crear una bonita historia. Podría haber puesto dos cosas no relacionadas en una confirmación, o podría haber hecho varias confirmaciones que se entendieron mejor como una única confirmación, pero finalmente me pareció una pérdida de tiempo y superé la pequeña vergüenza de tener una historia menos que perfecta.
¿Todavía haces esto? ¿Por qué vale la pena para ti? ¿Por qué no lo haces más? ¿Alguna vez lo hiciste o estás pensando en comenzar?
Si yo estuviera contribuyendo al kernel de Linux, esto obviamente valdría la pena, porque de lo contrario Linus rechazaría mi parche, pero IMO uno de los grandes errores de los usuarios de dvcs es imaginar que su proyecto es como el kernel de Linux. Mis proyectos generalmente solo tienen algunos desarrolladores.
Si se trata de una aplicación que puede ir y venir entre las revisiones, como la bifurcación de versiones anteriores para mantener versiones diferentes, consideraría tener mensajes de compromiso limpios y acrecentados para que sean una herramienta valiosa para el proyecto.
Si solo está trabajando en actualizaciones incrementales con poca posibilidad de romper la construcción en condiciones raras, no me molestaría demasiado en que sean extremadamente precisas.
Si solo se agrega al historial y mira la última versión, no le importa.
Recientemente estuve trabajando en un proyecto en el que alguien hizo una "fusión" mediante la aplicación de un parche grande en dos ramas. Lo encontré buscando un cambio que introdujo una función para ver qué pruebas se presentaron. Perdió mucho tiempo.
También verás que la nueva dimensión que se fusiona hace que la bisección sea mucho más difícil. Ya no es solo izquierda o derecha.
No vale la pena el esfuerzo.
Mientras que ''propina'' sea bonita, es mejor que deje que la historia sea fea y refleje con precisión cómo surgió el trabajo, en lugar de cómo deseaba que ocurriera el trabajo.
Cuando estoy investigando la historia la mitad del tiempo me pregunto "¿cómo se veía esto?" pero la otra mitad del tiempo me pregunto "¿por qué terminó así?" y quiero ver los intentos fallidos del desarrollador, incluso si él prefiere borrar el hecho de que alguna vez trató de tomar un camino que no lo hizo. Salir.
Estoy intentando recordar que los comentarios de compromiso aparecerán en la vista de anotaciones más adelante. Por lo tanto, intento explicar la intención y el efecto general de los cambios comprometidos, pero no el cambio en sí mismo.