Git en sí no define un mecanismo de revisión de código: eso lo agregan las plataformas (o el propio flujo de correo) que se construyen alrededor de él.
El modelo dominante en plataformas como GitHub, GitLab o Bitbucket: se sube una rama al remoto y se abre una solicitud para fusionarla a otra rama (normalmente la principal). La plataforma muestra el diff acumulado, permite comentarios línea por línea, y registra aprobaciones antes de permitir la fusión. Todo el proceso de discusión queda fuera del propio historial de Git: vive en la base de datos de la plataforma.
El flujo original de Git, todavía en uso en proyectos como el propio kernel de Linux: en vez de subir una rama a un servidor central, se genera un archivo de parche por cada commit y se envía por correo a una lista de distribución.
git format-patch origin/main git send-email *.patch
Quien revisa responde al correo citando líneas específicas del
parche; quien mantiene el proyecto aplica los parches aprobados con
git am. Este modelo no depende de ninguna plataforma
particular y funciona igual de bien de forma completamente
descentralizada, pero requiere más disciplina manual que una
interfaz web.
Ambos modelos cumplen la misma función: dar a alguien más la oportunidad de revisar el código antes de que se incorpore de forma permanente al historial compartido.