Nos estamos moviendo de Bitbucket a GitHub y una cosa con la que estamos luchando son las revisiones de código de pares que funcionaron muy bien en Bitbucket de esta manera:

1. El autor abrió una solicitud de extracción (GitHub: lo mismo)
2. El autor agregó a sus colegas como revisores (GitHub: ?? luchando aquí con múltiples asignados)
3. Revisor ya sea:
   1. Aprobó el PR con una marca de verificación verde (GitHub: ??)
   2. Comentarios agregados (GitHub: lo mismo)
   3. Creó tareas livianas (GitHub: algo similar si - [ ]se usa la sintaxis en la descripción de relaciones públicas; lástima que no funcione para las tareas)
4. Hay una lista de relaciones públicas donde puedo ver de un vistazo que se revisan y se pueden fusionar y que necesitan más atención (GitHub: ??)

Debo señalar que queremos evitar las herramientas de revisión de código de terceros si es posible y nos gustaría permanecer en GitHub vanilla con algún tipo de soluciones.

Por lo que he visto, la mayoría de esos pasos se realizan en Github por convención, y no por ningún proceso oficial proporcionado por Github.

Mi empleador usa Github, ejecuto una buena cantidad de pequeños proyectos de código abierto y hago contribuciones ocasionales a otros proyectos de código abierto.

Así es como generalmente lo he visto hacer:

Autor que agrega a sus colegas como revisores:

Esto varía de un proyecto a otro, pero en general, los revisores pares asignados son todos los contribuyentes al proyecto .

Los proyectos de código abierto parecen tener una jerarquía aproximada, tal vez su convención sería fusionarse solo después de que un contribuyente "principal" haya dado su aprobación.

En la tienda donde actualmente estoy empleado, nos fusionamos después de que cualquiera de las media docena de desarrolladores del equipo haya dado su aprobación.

En raras ocasiones, alguien en el equipo puede usar un comentario para llamar específicamente a otro desarrollador que cree que debería revisar por pares el código antes de que se fusione, pero de lo contrario, quien llegue primero y sienta que puede hacerlo puede revisar y hacer comentarios.

Aprobación del revisor:

La aprobación generalmente se muestra al hacer un comentario en la solicitud de extracción que dice "+1" o "lgtm" (me parece bien).

Tareas ligeras:

También he usado las casillas de verificación, pero en la mayoría de los casos, cada comentario sobre una solicitud de extracción se considera una "tarea" implícita que se resuelve mediante:

• cambiando el código que la línea está comentando
• respondiendo con otro comentario

Ver de un vistazo lo que está aprobado y lo que aún necesita revisión:

He utilizado la extensión Looks Good To Me para Chrome, que le ofrece una vista desde la pantalla Solicitudes de extracción. Sin embargo, la vista de la lista de solicitudes de extracción parece haberse roto debido a los recientes cambios de Github.