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

git ver archivos modificados

Question

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 mensaje 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 archivo.

4. GitHub notifica automágicamente al revisor de los 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 menos 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 reducir la naturaleza automática del proceso de revisión (que requiere un resumen enviado por correo electrónico).

Usamos Hudson como nuestro servidor de compilación, si eso ayuda.

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

Answer 1

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

Answer 2

Lo he usado para esto El flujo de trabajo que he utilizado es para hacer su trabajo en una rama de tema y enviar una solicitud de extracción en esa rama. 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 rama de tema, la vuelve a presionar (reescribiendo el historial en su repositorio 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. link

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.