Diferencias

Muestra las diferencias entre dos versiones de la página.

--- informatica:programacion:cursos:control_version_git_avanzado:pull_requests [2023/06/16 16:05] – [Introducción] tempwin
+++ informatica:programacion:cursos:control_version_git_avanzado:pull_requests [2023/06/16 16:56] (actual) – [Conclusión] tempwin
@@ Línea 8: / Línea 8: @@
 Se basa en que, como desarrollador, yo no voy a poder hacer un //merge// a develop sino que abriremos una solicitud al equipo de revisión para que mire el código de mi rama y, si todo va bien, la vuelquen a develop.
-===== Creación de PR y discusión del código =====
+===== Creación de pull request y discusión del código =====
+En equipos pequeños, la metodología es, como desarrollador, vamos contribuyendo al proyecto a través de la rama //develop//.
+Sin embargo, en equipos más grandes o proyectos //open source//, se suele utilizar el método de las //pull requests//. El código no se sube directamente a //develop// sino que alguien tiene que revisarlo y luego hacer //merge// a //develop//.
+El repositorio remoto se configura de manera que los desarrolladores pueden descargarse la rama //develop//, pero no subirla (hacer el //merge//), es decir, tiene permiso de solo lectura.
+Las //pull requests// existen en el servidor, no en nuestros equipos locales.
+Hay un encargado (o varios) de revisar las peticiones PR (//pull request//) y de realizar el merge de las ramas a develop.
+Cuando abrimos una //pull request//, subimos nuestra rama de //feature// e indicamos que esa rama la queremos fusionar con develop.
+Puede abrirse un espacio de discusión sobre el código.
+Cuando se haya aceptado y fusionado nuestra //pull requests//, se nos notificará y nosotros, en nuestro repositorio local tendremos que actualizar:
+<code>
+git pull develop
+</code>
+Entonces, podremos borrar nuestra rama local //feature//.
 ===== Pull Requests: caso práctico =====
+Creamos un repositorio remoto.
+Si somos nosotros los encargados de los //pull request//, vamos a nuestro repositorio local, iniciamos un repositorio git y añadimos el repositorio remoto:
+<code>
+git init
+git remote add origin <URL_REPOSITORIO_REMOTO>
+</code>
+Creamos una rama y la subimos:
+<code>
+git checkout master
+git push -u origin master
+</code>
+Ahora creamos y vamos a la rama //develop//:
+<code>
+git checkout develop
+</code>
+La subimos y pedimos que la //trackee//:
+<code>
+git push -u origin develop
+</code>
+Ahora que en el repositorio remoto hay ramas, hay que irse a las opciones y buscar los permisos de las ramas. Entonces, estableceremos que la rama //develop// tendrá permisos de escritura para el administrador y que los usuarios que seleccionemos tendrán permiso para fusionar a través de //pull requests//.
+La rama //master// debería quedar configurada para que no permita //pull requests// y que solo un administrador pueda hacer cambios en ella.
+En nuestro repositorio local, trabajamos sobre una rama, por ejemplo ''feature/titulo'' y la subo al repositorio remoto:
+<code>
+git push -u origin feature/titulo
+</code>
+En el repositorio remoto abriremos una pull request. Lo primero es indicar la rama origen (''feature/titulo'') y la rama destino (''develop'') y luego completar información como el commit y quién la va a revisar.
+Al revisor le llegará la //pull request// y podrá revisar los cambios. Si está todo correcto, puede aprobarla y finalmente hacer la fusión.
+Se avisará al desarrollador que pidió la //pull request//, así que podrá actualizar en local:
+<code>
+git checkout develop
+git pull
+</code>
+Y podremos borrar la rama local:
+<code>
+git branch -d feature/titulo
+</code>
 ===== Pull Requests con conflictos =====
+Cuando una //pull request// pueda generar algún conflicto, este no se puede solucionar en el repositorio remoto. No será posible hacer el //merge// en remoto.
+Hay que resolver en local. El desarrollador se descargará la rama que crea el conflicto y hará un //rebase// de su rama a //develop//. Este //rebase// encontrará el conflicto, el desarrollador lo resolvería y luego subiría la rama.
 ===== Conclusión =====
+En un equipo que trabaje con //pull request// debemos tener claro el flujo de trabajo: creamos una rama local temporal, la subimos, creamos la pull request en el servidor indicando de qué rama a qué rama queremos la fusión. Al cerrarse la pull request, podremos descargarnos la rama develop y borrar mi rama temporal.
 ===== Recursos =====