¿Qué es un buen flujo de trabajo de git para TDD?

No estoy seguro de que esto sea representativo, pero solo hablando como un desarrollador, uso git-flow y aquí está (más o less) mi flujo de trabajo para una nueva function:

• Crear una twig de características
• Escriba la testing de aceptación de alto nivel que falla (pepino) que falla con una @wip (trabajo en progreso) por lo que queda fuera del package de testing por ahora, y confírmelo a la nueva twig
• (A veces) escriba la testing de request de rspec para la testing de integración de casos extremos, y la confíe a la twig de características
• Escriba testings de nivel inferior (rspec / jasmine) para componentes individuales de la característica, y para cada "unidad" aproximadamente definida, comprométase con la twig de características
• Cuando la function haya finalizado lo suficiente como para pasar la testing de aceptación, quítese la label @wip , asegúrese de que pase y comprométase con la twig de características.
• Combina la twig de características en la twig de desarrollo usando git merge (y no git flow finish ). Esto deja la twig de funciones allí para que pueda actualizar la function más adelante si es necesario.
• Una vez que la twig se fusiona para desarrollarse, travis-ci ejecuta el set completo de testings y si hay algún problema, recibo un correo electrónico. (Solo incluyo las twigs de desarrollo y maestra en mi file .travis.yml).

Debo decir que este es mi flujo de trabajo "ideal": en la práctica, rompo estas reglas mucho: confirmo un cambio no probado antes de escribir la testing, empiezo a trabajar en partes de la function antes de realizar la testing de aceptación de alto nivel, etc. Básicamente, soy el único comprometido con el proyecto, así que tengo la libertad de hacerlo; si trabajas en un grupo más grande, creo que tendrías que ser más estricto al seguir cualquier flujo de trabajo que tengas.

De todos modos, así es como lo hago. También me gustaría escuchar a otras personas, así que he votado a favor.

ACTUALIZAR:

Después de escribir esto, me di count de que hay un sentido en el que me desvío del flujo anterior, que es cuando estoy agregando "características" que no son estrictamente el tipo normal orientado al usuario (es decir, no cosas que el usuario sabría de). Por ejemplo, desde el principio en el desarrollo de una aplicación, decidimos que queríamos usar backbone.js para estructurar nuestro código js, ​​así que creé una twig de características para él y @javascript tags @javascript a varias características existentes de pepino. Lo fusioné una vez que la twig fue capaz de hacer (con backbone.js) lo que la aplicación original estaba haciendo con las vistas HTML.

También planeo cambiar al uso de require.js, y en este caso también crearé una twig de características para hacer esto, y una vez hecho esto, lo fusionará nuevamente. No habrá ninguna testing de integración de alto nivel, siempre y cuando las testings existentes pasen, todo está bien.

La forma más sencilla de pensar cuándo deberías comprometerte es:

1. ¿Puedo describir lo que estoy comprometiendo con un post de compromiso que tenga sentido?
2. ¿Hay alguna razón por la que desee volver a este punto o diferir de este punto?

Eso significa que realmente depende de la persona. Si nunca te encuentras haciendo una diferencia en una de las etapas, tal vez porque lo arreglas lo suficientemente rápido como para que aún puedas recordar lo que has cambiado, entonces realmente no necesitas comprometerte. Sin embargo, tampoco hay daño, excepto por el time que lleva escribir el command.

Otra alternativa si realmente no sientes que un paso amerita un compromiso a más largo ploop es simplemente git add un git add . De esta forma, git diff le mostrará qué ha cambiado desde el complemento, y git diff --cached le mostrará qué cambió antes. Esto es lo que hago, porque prefiero mis compromisos para ser comstackble y aprobar testings unitarias. De esta manera, es fácil volver a un buen estado conocido.

Creo que una buena y simple pauta sería comprometerse cada vez que esté "verde", o al less cada ciclo de testing :

• O bien Rojo -> Verde -> Refactorio -> Confirmar
• o Rojo -> Verde -> Confirmar -> Refactorizar -> Commitir

No creo que exista un flujo de trabajo de compromiso específico para TDD, la única regla que trato de cumplir y que está relacionada es que bash no enviar commits con testings rotas a la twig principal (a less que ya esté roto). En mis twigs de características, por lo general, solo se testingn las testings relacionadas con las características, pero todas las testings se verifican al realizar la fusión de nuevo a maestro. Si sé que la confirmación deja algunas de las testings de funciones rotas o alguna otra razón que hace que así sea, solo entonces la indicaré como inactiva. En el lado más práctico de las cosas, creo que hay más beneficios en tener un cuidado especial para evitar empujar los compromisos a las twigs equivocadas.

Mi flujo de trabajo es muy similar, pero piense en hacer un mejor uso del área de preparación.

1. Escribe una testing, git add.
2. La testing puede generar errores debido a interfaces inexistentes, corrige esto, git add.
3. Haz el pase de testing (ahora solo en su defecto), commit de git.
4. Refactor, git commit enmendar.
5. Ir a 1.

Esto impone la disciplina que, en cada compromiso, todas las testings pasan. Durante las etapas 1-3, puedo retroceder al último git add en cualquier momento usando git checkout.