Flujo de trabajo para la revisión del código basado en GitHub

Estoy considerando usar GitHub como nuestra herramienta principal para hacer una revisión del código. Con funciones como comentarios en línea y vista de comparación, parece tener muchas características que ofrecen herramientas como Gerrit.

Alguien más ha usado GitHub para esto? Si es así, ¿cuál es su flujo de trabajo? ¿Y qué han estado haciendo tus experiencias, tanto positivas como negativas?

A medida que tenga algunas ideas sobre esto y sepa lo que funcionará mejor para nosotros, editare mi pregunta para compartir mi propio flujo de trabajo propuesto.

EDITADO con flujo de trabajo propuesto

Paso 0. Configure un gancho posterior a la recepción usando el impresionante reviewth.is .

Entonces:

  1. Comience como de costumbre con commit -a -s , pero en el post de #reviewthis @username .

  2. Si la construcción falla, la revisión se salta hasta que se restaura la construcción.

  3. Comentarios del revisor sobre la confirmación línea por línea o en el nivel de file.

  4. GitHub notifica automágicamente al usuario de comentarios.

  5. El revisor notifica al revisor por correo electrónico cuando los comentarios se completan con un resumen de revisión.

  6. Reviewee responde a los comentarios de los revisores dentro de GitHub, lo que permite que el proyecto tenga acceso al historial de revisiones de códigos.

Mis mayores problemas son con el Paso 2 y los Pasos 4/5. Gerrit funciona bien para no solicitar revisiones a less que la construcción tenga éxito; Me gustaría una forma de hacer esto dentro de GitHub. Los pasos 4/5 también pueden ser molestos (múltiples correos electrónicos) y networkingucir la naturaleza automática del process de revisión (que requiere un resumen enviado por correo electrónico).

Usamos Hudson como nuestro server de compilation, si eso ayuda.

Cualquier idea sobre estos problemas también sería útil.

Lo he usado para esto El flujo de trabajo que he utilizado es para hacer su trabajo en una twig de tema y enviar una request de extracción en esa twig. La (s) persona (s) revisora ​​(s) examinan el código y las confirmaciones, usando comentarios por línea (y por confirmación). El codificador toma esa retroalimentación y hace una rebase destructiva en esa twig de tema, la vuelve a presionar (reescribiendo el historial en su repository github), luego el ciclo de revisión se repite hasta que sea aceptable fusionarse.

Editar: Un Githubber publicado en su blog que describe el método que utilizan para desarrollar github en sí, y es bastante similar a lo que propuse. enlazar

Actualización: ahora he estado usando este flujo de trabajo tanto en mis proyectos de código abierto como en mi trabajo profesional, pero sigue funcionando muy bien.

En mi trabajo, prácticamente seguimos el process descrito en "Uso de requestes de extracción" para la revisión del código y estamos muy contentos con ello.