2011-08-15 9 views
5

Siempre estoy interesado en probar cosas nuevas con mi flujo de trabajo, y pensé que podría ser un experimento interesante comprometer automáticamente entre rojo, verde y pasos de refactorización, pero luego aplazar manualmente las confirmaciones una vez que termine una característica específica (y antes de empujar).Compromiso automático de git entre los pasos rojo, verde y refactorizador?

Me preguntaba si alguien más ha intentado esto antes? Creí haber leído sobre esto una vez, pero no puedo encontrar ninguna referencia.

Espero que un beneficio sea centrarse más en comprometerme con frecuencia, así como también poder ver mi flujo de trabajo visualmente para poder mejorarlo. Por ejemplo, antes de aplastar puedo ver si mi tiempo entre rojo y verde es demasiado largo, o si el número de cambios de código que hago es mayor de lo necesario entre cada paso.

que iba a poner en práctica esta forma de plugin guard de manera que al guardar un archivo de especificaciones o en la biblioteca, se ejecuta las especificaciones y confirma el cambio con un mensaje de confirmación como:

Green: 1621 examples, 0 failures, 2 pending (1659 tests/s, 0.0006 p/test) 

La idea es que Podría escanear visualmente esto al aplastar y determinar dónde agrupar los compromisos Rojo/Verde/Refactor relacionados mediante cambios lógicos.

En el peor de los casos pensé que podría ser un experimento divertido, en el mejor de los casos podría darme una forma diferente de ver cómo trabajo.

Respuesta

1

Me gusta la idea.

Mostrar la especificación nueva/actualizada podría ser una ventaja. :)

Puede ser difícil para este complemento saber cuándo el código alcanzó un estado "verdadero" Rojo/Verde.

¿Sería:

  • commits --amend 'Roja' cuando especificaciones no están pasando y ningún archivo que no sea de especificaciones '' se cambian?
  • después de eso, ¿se aplica 'Verde' tan pronto como las especificaciones pasen debido a una actualización en lib?
+0

Pensé en ese tipo de flujo de trabajo. Para el comienzo, me iba a comprometer después de cada ejecución de especificación. Sin embargo, modificar el cambio de estado puede reducir el ruido. – dkubb

1

Sí, creo que sería un experimento divertido, ya que la información reunida sería interesante de analizar. Puede ver los tiempos de ciclo promedio y ver qué partes de los proyectos (archivos) tienen tiempos de ciclo más lentos que podrían ser vistos como una métrica de código. Cuanta más información en el registro de git, mejor ... es decir, qué especificaciones están fallando, etc. Por favor comparta cualquier progreso y/o resultado que surja de la idea.

1

¡Guau! Lo creas o no, tuve una idea similar hace unos días (para hacer como un proyecto de fin de semana), cuando estaba leyendo en Unit Testing, que quería construir un módulo para que git hiciera algo similar.

Mi idea no era completamente automática, sino una parte. Por ejemplo, una confirmación personalizada verá qué son los RED y les dará alguna identificación, y el VERDE siguiente verá lo que resuelve todos los RED, y agregará un comentario adecuado en el mensaje de confirmación junto con el ID de la prueba y los compromisos RED.

alguna funcionalidad adicional puede incluir la navegación por estas confirmaciones sobre la base de unos criterios ...

De todas formas, si usted encuentra esta referencia que está hablando, por favor, actualice este hilo.

1

Me gusta esto y lo he considerado una o dos veces. Sin embargo, no estoy seguro de ver el valor por completo. A primera vista, pensé que sería más fácil retroceder a mi último estado verde conocido. Después de ver JUnitMax, tiene incorporada la funcionalidad "revertir a verde", por lo que no he sentido el deseo desde la confirmación automática.

Cuestiones relacionadas