La lección 06-06 cerró el bloque técnico del curso con una constatación incómoda: Ana, Bruno y Carla dominan la herramienta, pero no han acordado cómo trabajar juntos. Y la primera de esas preguntas sin responder es también la más concreta: cuando alguien termina un cambio, ¿cómo lo propone? ¿Lo envía directamente a main y avisa por el chat? ¿Y qué pasa si esa persona no tiene permiso de escritura en el repositorio?

Ese caso ha dejado de ser hipotético. La empresa ha decidido publicar gestor-tareas como proyecto abierto en git.ejemplo.es/equipo/gestor-tareas, y ya ha aparecido el primer colaborador de fuera: Diego Rueda, desarrollador de una consultora que usa la aplicación en un cliente. Diego ha encontrado un fallo —la lista de tareas no se reordena al marcar una como completada— y quiere arreglarlo. Puede clonar el repositorio, porque es público. Puede crear una rama en su portátil. Lo que no puede es hacer git push: el servidor le responderá con un error de permisos.

Esta lección resuelve exactamente ese problema. Y de paso cierra la promesa pendiente del módulo 4: qué significa realmente el remoto llamado upstream.

1. El problema: proponer un cambio sin permiso de escritura
2. Qué es un fork y por qué no es un concepto de Git
3. El triángulo: origin, upstream y tu repositorio local
4. Montar el triángulo paso a paso
5. Mantener el fork al día
6. Qué es una pull request (o merge request)
7. Anatomía de una buena pull request
8. Pull requests en borrador
9. El recorrido completo de Diego, de principio a fin
10. Descargar la rama de una PR para probarla en local
11. Forks o ramas en el mismo repositorio: criterios para elegir

Recordemos cómo funciona el envío de cambios (lección 04-05). Cuando Ana ejecuta git push origin funcionalidad/orden-alfabetico, ocurren dos cosas:

1. Git negocia con el servidor qué objetos faltan y los transfiere.
2. El servidor actualiza una referencia: crea o mueve refs/heads/funcionalidad/orden-alfabetico.

El paso 2 es una escritura en el repositorio del servidor, y toda plataforma de alojamiento la protege con permisos. Ana, Bruno y Carla los tienen porque son el equipo. Diego no.

Si Diego lo intenta, ve esto:

Aquí es donde mucha gente se atasca, y conviene decirlo claro: Git no tiene ninguna respuesta a este problema. Git es un sistema distribuido; en su diseño original, la forma de proponer un cambio era enviar parches por correo electrónico (lo veremos en la lección 07-02). No existe un comando git propose ni git pull-request.

La respuesta la inventaron las plataformas de alojamiento, y consta de dos piezas complementarias:

Ninguna de las dos es parte de Git. Ambas se construyen encima de operaciones de Git que ya conoces: clonar, enviar y fusionar.

La definición, sin adornos:

Un fork es una copia del repositorio hecha en el propio servidor, alojada bajo tu cuenta, sobre la que tienes permiso total de escritura.

Es decir: un git clone que ocurre de servidor a servidor, no de servidor a tu portátil. Diego pulsa el botón de crear fork y la plataforma crea git.ejemplo.es/drueda/gestor-tareas con todo el historial, todas las ramas y todas las etiquetas del original.

Fíjate en la flecha de puntos: el fork no devuelve nada automáticamente. Diego puede llenar su fork de commits durante meses y el repositorio original no se enterará. La pull request es el mecanismo explícito que dice "mira lo que tengo, ¿lo quieres?".

Tres consecuencias que conviene tener claras desde el principio:

• El fork es un repositorio Git normal y corriente. Tiene su URL, se clona igual, acepta push igual. Lo único especial es que la plataforma recuerda de dónde salió, para poder ofrecerte crear pull requests contra el original.
• El fork no se actualiza solo. Es una foto del momento en que lo creaste. Si el equipo sigue trabajando, tu fork se queda atrás. Mantenerlo al día es responsabilidad tuya (apartado 5).
• La palabra tiene otro significado histórico. En el mundo del software libre, "hacer un fork" significaba tradicionalmente escindir un proyecto para llevarlo en otra dirección, con otro equipo (LibreOffice de OpenOffice, por ejemplo). Ese sentido sigue existiendo. El fork del que hablamos aquí es puramente técnico y temporal: una copia para poder contribuir.

Nombres en cada plataforma. GitHub, GitLab y Gitea lo llaman fork. Bitbucket también. GitLab, además, mantiene un enlace visible entre el fork y el original que permite sincronizar desde la interfaz.

Ahora Diego tiene tres repositorios en juego, no dos. Y ahí es donde entra la convención que el módulo 4 dejó anunciada.

En la lección 04-01 vimos que un remoto no es más que un nombre corto para una URL, y que origin y upstream no son palabras reservadas de Git: son costumbres. También avisamos de que upstream significa dos cosas distintas. Aquí usamos la primera:

upstream (como nombre de remoto): el remoto que apunta al repositorio original del que hiciste el fork.

El reparto convencional queda así:

Léelo como un ciclo: el trabajo baja del original, pasa por tu local, sube a tu fork y vuelve al original en forma de propuesta. Ese recorrido triangular es la razón de que a esta configuración se la llame triangular workflow, y Git incluso tiene opciones pensadas para ella (remote.pushDefault, push.default = current), que veremos en el apartado 4.

El error más habitual de quien empieza es hacer git pull esperando traer los cambios del proyecto original, cuando pull habla con origin, que es tu fork, que no se ha movido. Se queda uno mirando la pantalla convencido de que "Git no baja nada". Y tiene razón: no hay nada que bajar de ahí.

Diego ya ha creado el fork en la plataforma. Ahora, en su portátil:

Un detalle práctico: como Diego nunca va a poder escribir en upstream, conviene usar la URL de solo lectura (https://) para ese remoto, o directamente desactivar el envío:

Comprobamos el resultado:

Ahora git push upstream muere en local con un error claro en lugar de intentar autenticarse y fallar con un 403 confuso.

Estas tres opciones convierten el triángulo en algo cómodo:

Y una más, muy útil: hacer que la rama main local siga al original, no al fork. Así git status le dice a Diego cuánto se ha alejado del proyecto de verdad, que es lo que le importa:

Ojo con la coincidencia de palabras: aquí estamos usando los dos sentidos de upstream en la misma línea. --set-upstream-to configura la rama de seguimiento (lección 04-06) y upstream/main es la rama del remoto llamado upstream. Que el nombre coincida es casualidad de la convención, no magia.

El fork envejece. Mientras Diego prepara su corrección, Ana y Carla siguen integrando cosas en equipo/gestor-tareas. Si Diego construye su rama sobre una base de hace tres semanas, su pull request llegará con conflictos y con código que ya no encaja.

La rutina de puesta al día son tres comandos:

Merece la pena detenerse en cada uno.

git fetch upstream solo actualiza las referencias remotas upstream/*. No toca ninguna rama local ni el directorio de trabajo. Es siempre seguro.

git merge --ff-only upstream/main es deliberadamente estricto. Como vimos en la lección 03-03, --ff-only aborta si la fusión no puede resolverse avanzando el puntero. Y eso es exactamente lo que queremos: si falla, significa que hay commits en tu main local que no están en el original, lo cual en un fork casi siempre es un error (trabajaste directamente sobre main en lugar de crear una rama). Mejor enterarse con un error que con una fusión sorpresa.

Si de verdad quieres tirar tu main y adoptar el del original sin preguntas:

Esto es legítimo en tu propio fork, porque tu main no es un historial compartido: nadie más lo consume. Sigue aplicando la regla de oro de la lección 05-06 (no reescribas lo que otros han recibido), pero aquí el "otros" eres tú mismo. Y --force-with-lease en lugar de --force, siempre (lección 04-05).

Distinto caso. Si Diego ya tiene commits en correccion/reordenar-al-completar y el original ha avanzado, tiene dos opciones que ya conoce:

Cuál elegir depende del acuerdo del proyecto, y ese acuerdo es materia de la lección 08-02. Como orientación: mientras la pull request no tenga revisiones publicadas, el rebase es limpio y no molesta a nadie. Una vez hay comentarios sobre commits concretos, un rebase los descoloca y suele preferirse la fusión (o esperar a integrar y dejar que quien fusiona decida).

Sobre el botón "Sync fork". Muchas plataformas ofrecen sincronizar el fork desde la web con un clic. Hace exactamente lo del bloque de arriba, pero solo actualiza el fork en el servidor: tu clon local sigue sin enterarse hasta que hagas git fetch origin o git pull. Es una fuente clásica de confusión.

Definición operativa:

Una pull request es una petición formal de integrar los commits de una rama en otra, acompañada de un hilo de conversación, un diff calculado por la plataforma y un conjunto de comprobaciones automáticas.

Fíjate en lo que no dice. No dice "los cambios de un fork": una PR puede ir perfectamente de una rama a otra dentro del mismo repositorio, y de hecho así es como trabajan la mayoría de equipos internos (apartado 11). El fork es un caso particular, no la definición.

Una pull request tiene siempre estos elementos:

El nombre cambia según la plataforma, pero la cosa es la misma:

El nombre de GitHub es el históricamente correcto: "te pido que hagas pull de mi rama". El de GitLab describe mejor lo que realmente pasa al final: una fusión.

Y una precisión importante sobre el ciclo de vida: la PR es un objeto vivo. No es un envío de una sola vez. Si Diego hace git push de nuevos commits a la misma rama de su fork, la PR se actualiza sola: aparecen los commits nuevos, se recalcula el diff y se vuelven a lanzar las comprobaciones. No hay que crear una PR nueva por cada corrección.

Una PR es, ante todo, una petición de tiempo ajeno. Alguien va a dejar lo que estaba haciendo para leer tu trabajo. Todo lo que sigue va de respetar ese tiempo.

Nombre significativo, siguiendo la convención del proyecto (lección 03-06). En gestor-tareas: funcionalidad/, correccion/, documentacion/, hotfix/. correccion/reordenar-al-completar dice qué hay dentro antes de abrir nada; parche2 o arreglo-diego no dicen nada.

Este es el factor que más impacto tiene en la calidad de la revisión, y lo cuantificaremos con datos en la lección 07-02. De momento, la regla: una PR debe hacer una cosa. Si al escribir la descripción necesitas la palabra "y" tres veces, son tres PRs.

Un caso concreto: Diego encuentra el fallo de reordenación, pero de paso ve que estilos.css tiene indentación inconsistente y que README.md tiene un enlace roto. La tentación de arreglarlo todo en el mismo cambio es enorme. No lo hagas. El revisor tendrá que separar mentalmente el arreglo real de sesenta líneas de reformateo, y el arreglo real es lo único que importa.

Que se puedan leer uno a uno. Aquí es donde se paga el rebase interactivo de la lección 05-02: antes de abrir la PR, mira tu propio historial y limpia.

Eso no se le enseña a nadie. Con un git rebase -i upstream/main y unos cuantos fixup, se convierte en:

Un commit, un cambio, un mensaje que explica el porqué. Las reglas concretas de redacción de esos mensajes son el contenido de la lección 08-01; aquí basta con la idea de que el historial que propones forma parte de la propuesta.

Una buena descripción responde a cuatro preguntas:

1. Qué problema resuelve (y enlace al ticket: GT-214, la convención que ya validan los hooks del módulo 6).
2. Qué has hecho y, si hay varias opciones, por qué esta.
3. Cómo se comprueba: pasos concretos para reproducir el fallo y ver que ya no ocurre.
4. Qué queda fuera, si has decidido conscientemente no abordar algo.

Ejemplo real de la PR de Diego:

Muchos proyectos automatizan esto con una plantilla de pull request: un fichero versionado (por ejemplo .github/pull_request_template.md o .gitlab/merge_request_templates/) cuyo contenido aparece precargado en la caja de descripción. Es un fichero de texto en el repositorio, nada más.

Hay un momento incómodo: quieres enseñar el trabajo antes de terminarlo. Para pedir opinión sobre el enfoque, para que el CI lo pruebe, para que nadie duplique tu esfuerzo. Pero si abres una PR normal, alguien la revisará a fondo y perderá el tiempo, o peor, la integrará.

Para eso están las pull requests en borrador (draft en GitHub, merge request marcada como Draft en GitLab, que históricamente se indicaba con el prefijo WIP: en el título).

Una PR en borrador:

• Es visible y tiene su hilo de conversación y su diff.
• Lanza las comprobaciones automáticas igual que una normal (según configuración).
• No se puede integrar hasta que se marque como lista.
• Normalmente no pide revisores de forma automática.

Es la herramienta correcta para tres situaciones: pedir validación temprana del enfoque antes de invertir tres días, dejar constancia pública de que estás trabajando en algo, y usar el CI del proyecto para probar en entornos que no tienes en local (Carla, en Windows 11, la usa para comprobar que su cambio también funciona en Linux).

Todo junto, en orden. Diego parte de cero.

Paso 1: fork. En la plataforma, sobre equipo/gestor-tareas. Resultado: drueda/gestor-tareas.

Paso 2: clonar el fork y montar el triángulo.

Paso 3: partir del estado más reciente del original. No de lo que había cuando hizo el fork.

Este switch -c ... upstream/main es el gesto clave: crea la rama sobre la punta del proyecto real, no sobre su fork desactualizado.

Paso 4: trabajar. Editar app.js, confirmar, editar, confirmar. Sin preocuparse por la limpieza todavía.

Paso 5: limpiar antes de enseñar.

Aplasta los tanteos, deja los commits que cuentan una historia, y de paso comprueba que sigue funcionando sobre la base actual.

Paso 6: enviar al fork.

Ese mensaje remote: no lo inventa Git: lo emite el servidor mediante un hook post-receive (los que 06-01 dejó pendientes y que retomaremos en 07-06).

Paso 7: abrir la pull request. En la plataforma, con rama origen drueda:correccion/reordenar-al-completar y destino equipo:main, con la descripción del apartado 7.

Paso 8: la revisión. Ana revisa y pide un cambio: que la función no repinte la lista entera si no ha cambiado el orden, por rendimiento con muchas tareas.

Paso 9: responder a la revisión. Diego no abre una PR nueva. Trabaja en la misma rama:

La PR se actualiza sola. Ana ve el commit nuevo y puede revisar solo eso, sin releerlo todo.

Paso 10: integración. Ana aprueba y pulsa el botón. La plataforma ejecuta la fusión en el servidor —con el método que el proyecto haya decidido: fusión normal, squash o rebase, tema de la lección 07-04— y cierra la PR.

Paso 11: limpieza.

Y con git fetch --prune (lección 04-04), las referencias remotas obsoletas desaparecen.

Ana no quiere revisar el cambio de Diego solo leyendo un diff en el navegador. Quiere ejecutarlo. Pero la rama está en el fork de Diego, un repositorio que ella no tiene configurado.

Hay tres formas de traérsela, de menos a más elegante.

Funciona siempre, pero acumula remotos si revisas a mucha gente:

Aquí está el truco bueno. Las plataformas publican cada pull request como una referencia dentro del repositorio original, aunque la rama viva en un fork. En GitHub:

Léelo con lo que sabes de refspecs (lección 04-02): pull/42/head es la referencia en el servidor, revision/pr-42 es el nombre local. Los dos puntos separan origen y destino, exactamente igual que en cualquier otro refspec.

En GitLab, la ruta cambia de nombre pero el mecanismo es idéntico:

Y en Gitea/Forgejo:

GitHub publica además una segunda referencia muy útil:

pull/42/merge es lo que en realidad prueba el CI cuando comprueba una pull request, y es el origen de una sorpresa clásica que desarrollaremos en la lección 07-06: las pruebas no se ejecutan sobre tu rama, sino sobre tu rama fusionada con main.

Si revisas PRs a diario, añade esto a la configuración del remoto para que un simple git fetch traiga todas:

En .git/config queda así:

El + inicial permite actualizaciones no fast-forward, necesario porque el autor de una PR puede haber reescrito su rama con un rebase.

Cuidado en repositorios muy activos. En un proyecto con diez mil pull requests históricas, esa segunda línea hace que cada fetch traiga miles de referencias. Úsala en repositorios de tamaño razonable, o restringe el patrón.

Y un apunte práctico: las herramientas de línea de comandos de las plataformas (gh pr checkout 42 en GitHub, glab mr checkout 42 en GitLab) hacen exactamente esto por ti, incluyendo configurar el seguimiento para que puedas enviar correcciones si tienes permiso. Son cómodas, pero saber qué hay debajo es lo que te salva cuando no funcionan.

Combinado con lo del módulo 6, la revisión sale gratis en tiempo de contexto:

Diego usa un fork porque no tiene otra opción. Ana, Bruno y Carla no están en esa situación: tienen permiso de escritura, y para ellos el fork sería un rodeo innecesario. Trabajan con ramas en el mismo repositorio y abren pull requests de rama a rama.

La comparación completa:

El punto de los secretos en CI merece explicación, porque es una restricción de seguridad importante y sorprende a mucha gente. Si el CI del proyecto tuviera acceso a credenciales de despliegue al ejecutar el código de cualquier PR, cualquier persona de internet podría robarlas simplemente abriendo una PR cuyo código imprima las variables de entorno. Por eso las plataformas ejecutan las PRs procedentes de forks en un modo restringido, sin secretos, y a menudo exigiendo que un miembro del equipo apruebe la ejecución. Lo retomaremos en la lección 07-06.

La regla se reduce a una pregunta: ¿confías en esta persona para escribir en el repositorio?

• Sí → ramas en el mismo repositorio. Menos fricción, más visibilidad.
• No, o todavía no → fork.

Muchos proyectos abiertos aplican la regla escalonada: los colaboradores de fuera usan forks, y cuando alguien demuestra constancia se le da permiso de escritura y pasa a trabajar con ramas. Diego, si sigue contribuyendo a gestor-tareas, acabará en el segundo grupo.

Un matiz sobre los permisos. "Permiso de escritura" no significa "puede romper main". Con las ramas protegidas de la lección 07-06, alguien puede crear ramas y abrir PRs pero seguir teniendo prohibido enviar directamente a main. Los dos mecanismos son independientes y se combinan.

Error 1: clonar el original en lugar del fork. Diego clona equipo/gestor-tareas, trabaja, y al enviar recibe un 403. Se arregla sin perder nada: git remote rename origin upstream y git remote add origin <url-del-fork>.

Error 2: creer que el fork se actualiza solo. Es una foto del momento de creación. Si no ejecutas git fetch upstream periódicamente, trabajas sobre una base antigua y tu PR llegará con conflictos.

Error 3: git pull esperando los cambios del proyecto original. pull habla con origin, que es tu fork, que no se mueve solo. Lo que quieres es git fetch upstream.

Error 4: sincronizar el fork en la web y creer que el local está al día. El botón "Sync fork" actualiza el servidor. Tu portátil sigue igual hasta que hagas git fetch origin.

Error 5: trabajar directamente sobre main en el fork. Convierte cada puesta al día en un conflicto y te impide tener dos propuestas simultáneas. Rama nueva siempre, y creada sobre upstream/main.

Error 6: abrir una PR nueva por cada corrección de la revisión. La PR se actualiza sola al enviar a la misma rama. Cerrar y abrir otra tira a la basura toda la conversación previa.

Error 7: meter reformateos o arreglos ajenos en la misma PR. Convierte un diff de diez líneas revisables en uno de doscientas ilegibles. Una PR aparte, siempre.

Error 8: enviar sin limpiar el historial. Cuatro commits llamados wip, arreglado, ahora si y pruebas son una falta de respeto al revisor. git rebase -i upstream/main antes de enviar.

Error 9: borrar la rama del fork antes de que la PR se integre. La PR se queda sin contenido y la plataforma la cierra sola. Borrar después.

Consejo 1: desactiva el push a upstream. git remote set-url --push upstream NO_ENVIAR. Un error tipográfico menos.

Consejo 2: crea las ramas con git switch -c <rama> upstream/main. Explicitar la base evita el 90% de los conflictos de una PR.

Consejo 3: lee el CONTRIBUTING.md antes de abrir nada. Muchos proyectos documentan ahí el formato de mensajes, la rama destino correcta y si aceptan o no ciertos cambios. Ignorarlo es la vía rápida a que te cierren la PR.

Consejo 4: abre en borrador si aún no está listo. Es más honesto que un título con NO FUSIONAR en mayúsculas.

Consejo 5: aprende git fetch origin pull/<n>/head:<rama> de memoria. Es el comando que convierte la revisión en algo real y no en lectura de diffs en un navegador.

Consejo 6: combina la referencia de PR con git worktree. Revisar sin perder el contexto de tu propio trabajo (lección 06-06).

Sin plataforma ni internet, reproduce la topología completa con repositorios bare (lección 04-01):

1. Crea /tmp/servidor/original.git como repositorio bare y publica en él un main con index.html, app.js y README.md.
2. Simula el fork: crea /tmp/servidor/fork.git como clon bare del original.
3. Clona el fork en /tmp/diego, añade upstream apuntando al original y desactiva su envío.
4. Comprueba con git remote -v que el triángulo está bien montado.
5. Desde otro clon /tmp/ana, añade un commit al original para que el fork quede desactualizado.
6. Desde /tmp/diego, pon el main local al día y actualiza el fork.

Continuando con el escenario anterior:

1. En /tmp/diego, crea correccion/enlace-roto sobre upstream/main y haz tres commits desordenados sobre README.md (uno bueno y dos de tanteo).
2. Límpialos con rebase interactivo hasta dejar un solo commit con un mensaje decente.
3. Envíalo al fork.
4. Desde /tmp/ana, añade el fork como remoto, trae la rama de Diego, revísala con git log y git diff, y fusiónala en main del original.
5. Vuelve a /tmp/diego, actualiza main, actualiza el fork y borra la rama en local y en el fork.

1. En /tmp/servidor/original.git, crea a mano una referencia que imite la de una PR: toma el commit de la rama de Diego y guárdalo como refs/pull/1/head (pista: git update-ref, ejecutado dentro del repositorio bare).
2. Desde /tmp/ana, trae esa referencia a una rama local llamada revision/pr-1 con un solo git fetch.
3. Configura el refspec permanente en .git/config de /tmp/ana para que todas las refs/pull/*/head lleguen como origin/pr/*.
4. Comprueba con git branch -r que aparece origin/pr/1.
5. Crea un worktree en /tmp/revision-1 apuntando a esa referencia, sin abandonar tu rama actual.

Solución 1:

Solución 2:

Solución 3:

Nota: si el commit no existe en original.git porque no llegó a fusionarse, tráelo antes con git --git-dir=/tmp/servidor/original.git fetch /tmp/servidor/fork.git 'refs/heads/*:refs/remotes/fork/*'.

Esta lección ha respondido a la primera pregunta que dejó abierta el módulo 6: cómo propone un cambio quien no puede escribir en el repositorio. Lo esencial:

• Ni el fork ni la pull request son conceptos de Git. Son invenciones de las plataformas construidas sobre operaciones que ya conocías: clonar, enviar y fusionar.
• Un fork es un clon del repositorio hecho en el servidor, bajo tu cuenta, donde sí tienes permiso de escritura. No se actualiza solo.
• El triángulo origin (tu fork) / upstream (el original) / local es la configuración estándar del colaborador externo, y cierra la convención upstream que anunciamos en el módulo 4. Recuerda que la palabra tiene otro sentido —la rama de seguimiento de la lección 04-06— y que no son lo mismo.
• Mantener el fork al día es git fetch upstream + git merge --ff-only upstream/main + git push origin main. Crear las ramas con git switch -c <rama> upstream/main evita la mayoría de los conflictos.
• Una pull request es una petición de integrar una rama en otra, más el hilo de conversación. Es un objeto vivo: enviar más commits a la rama la actualiza, no hace falta abrir otra.
• Una buena PR: rama con nombre significativo, una sola cosa, tamaño acotado, commits legibles tras un rebase interactivo, y una descripción que diga qué problema resuelve y cómo comprobarlo.
• Las PRs en borrador sirven para enseñar trabajo sin terminar sin que nadie pierda el tiempo revisándolo ni lo integre por error.
• Las plataformas publican cada PR como una referencia del repositorio original: git fetch origin pull/<n>/head:<rama> en GitHub y Gitea, merge-requests/<n>/head en GitLab. Es la forma de probar de verdad lo que vas a revisar. GitHub publica además pull/<n>/merge, el resultado precalculado de la fusión, que será importante en la lección 07-06.
• Forks para quien no tiene permiso (proyectos abiertos, colaboradores externos, restricción de secretos en CI); ramas en el mismo repositorio para equipos con confianza mutua. Ana, Bruno y Carla usan ramas; Diego usa fork.

Ya tenemos el canal por el que llega una propuesta. Falta lo que ocurre dentro de ese canal: qué mira exactamente Ana cuando revisa el trabajo de Diego, con qué comandos lo examina sin depender del navegador, cómo comenta sin desmoralizar a nadie y cuándo aprueba. Ese es el contenido de la lección 07-02: Revisiones de Código con Git, donde descubriremos, entre otras cosas, por qué el diff correcto para revisar lleva tres puntos y no dos.