¿Proceso de revisión de código cuando se usa GIT como repositorio?

¿Cuál es el mejor proceso para la revisión de código cuando se usa GIT? Tenemos un proveedor externo de GIT (Unfuddle) y tenemos límites en el uso de recursos, por lo que no podemos tener repositorios remotos dedicados para cada desarrollador.

Proceso actual:

• Tenemos un servidor GIT con una masterrama a la que todos se comprometen
• Los desarrolladores trabajan desde el masterespejo local o una rama de características locales
• Los desarrolladores empujan a la mastersucursal del servidor
• Revisión del código de solicitud de desarrolladores en la última confirmación

Problema:

• Cualquier error en la revisión del código ya está en el maestro cuando se detecta.
• Peor aún, por lo general alguien ha quemado algunas horas tratando de descubrir qué pasó ...

Entonces, nos gustaría

• Para hacer la revisión del código ANTES de la entrega al 'maestro'.
• Tenga un proceso que funcione con un equipo global (¡no hay reseñas sobre el hombro !)
• algo que no requiere que un desarrollador individual esté en su escritorio / máquina para que se encienda de modo que alguien más pueda acceder de forma remota (eliminar la dependencia humana, los desarrolladores se van a casa en diferentes zonas horarias)

Usamos TortoiseGIT para una representación visual de una lista de archivos modificados, archivos diferidos, etc. Algunos de nosotros caemos en un shell GIT cuando la GUI no es suficiente, pero idealmente nos gustaría que el flujo de trabajo sea simple y basado en GUI (Quiero que la herramienta levante cualquier carga, no mis desarrolladores).

Un modelo simple pero efectivo es el modelo de solicitud de extracción de GitHub , donde los contribuyentes presentan solicitudes de "fusionar en mi código". Un responsable de mantenimiento revisa los conjuntos de cambios y decide si necesitan más trabajo o si son adecuados para la fusión. Luego puede fusionarse con la rama maestra. Por lo general, no se permite a los encargados de enviar directamente a la rama maestra (esto se puede personalizar según sus gustos, permitimos que los compromisos "menores" entren directamente).

Git es un sistema de control de versiones distribuido: ¡no tenga solo un repositorio con una rama!

Puede configurar múltiples repositorios, uno para cada desarrollador, y otro que es el repositorio principal. Cuando una de sus sucursales está lista para fusionarse, el desarrollador solicita una fusión y sus cambios se transfieren de su sucursal / repositorio al maestro.

Antes de que ocurra esa fusión, el revisor puede llevar los cambios a su entorno y revisarlos antes de presionarlos para que dominen.

Las ventajas adicionales son que de esta manera un desarrollador puede tener tantas sucursales como desee, nombrar lo que diga que quiera, sin interferir entre sí o incluso tener que ver tanto la ropa sucia del otro.

Además, aprenda la jerga: por "Los desarrolladores se comprometen con la rama maestra del servidor", ¿quieren decir que empujan sus cambios a maestro?