- Control total sobre que se mergea.
- El dueño del repo es el único responsable del código.
- El dueño es cuello de botella.
Cuando el repositorio tiene un responsable claro (también puede ser un equipo), y los demás son colaboradores circunstanciales.
- "Agilidad": si una persona está conforme, mergea.
- El reviewer podría no tener información suficiente para revisar en profundidad.
- No aplica bien para múltiples reviewers.
- El merge queda a nombre del reviewer cuando, en realidad, el responsable de ese código es el autor original.
- El autor no tiene la posibilidad de hacer un rebase en lugar de un merge tradicional, generando grafos más complejos.
- Hay excepciones, bastante comunes, en que inevitablemente que mergee el autor. Por ejemplo, cuando hay conflictos o cuando el autor tiene dudas y espera respuestas de los reviewers.
- Si en base al review el autor decide hacer cambios, podría ser demasiado tarder.
Cuando los reviewers entienden bien el contexto de la tarea y el código y están claros los criterios a tener en cuenta para mergear.
Podría ser también cuando se espera un review rápido solo para evitar errores groseros.
- Aplica bien cuando hay más de un reviewer.
- Queda a discreción del autor (responsable del código) evaluar cuando su PR está suficientemente revisado.
- El merge queda a nombre del autor, que es el reponsable del código.
- El autor tiene la posibilidad de rebasear antes de mergear, simplificando el grafo de commits.
- El mismo flujo aplica bien cuando hay conflictos.
- Si en base al review el autor decide hacer cambios, puede hacerlo.
- Requiere un poco más de interacción.
- Equipos de pares donde cualquiera puede escribir en la rama destino.