Cuando cambia la propuesta

Vamos a descubrir juntos

1. 1

   Reviewer añade una línea al README en main y la envía al remoto local. Author sigue en la rama de corrección. Un archivo nuevo o un cambio de base puede alterar el contexto sin editar la función revisada.

2. 2

   En author, confirma status limpio, haz fetch origin y examina diferencias antes de git merge origin/main. Este recorrido usa merge para conservar commits compartidos; rebase y reescritura quedan para después. No uses force push para evitar divergencias.

3. 3

   Repite pruebas tras integrar base. Un nuevo commit en head cambia la propuesta. Registra la versión con git rev-parse HEAD e informa al revisor; una aprobación antigua no prueba que se revisó el código nuevo.

4. 4

   Nuestro acuerdo didáctico exige revisar el estado actual. En GitHub, descartar aprobaciones antiguas o exigir nuevas depende de las reglas. Cuando checks prueban un merge temporal, revisa también head y base; no compares solo una etiqueta verde.