Tabla de contenido
Una vez más aquí. En esta ocasión vamos ya por el volumen 6 de la serie de artículos sobre el sistema de gestión de código fuente descentralizado llamado git. Al final del último artículo, lo dejamos en git clone, clonando el repositorio remoto y algunas cosas más. En las líneas que nos ocupan, vamos a empezar por los Forks, y ya vemos hasta dónde nos lleva …
Forks en git
Los repositorios públicos o aquellos que nos dan acceso permiten crear un fork o copia de este. En el momento de hacer un fork, GitHub va a crear una copia exacta del repositorio. Desde ese momento, los cambios que se hagan en el repositorio clonado y en el principal, seguirán caminos distintos. Vamos, que ya no tendrán nada que ver unos con los otros.
Para hacer un fork de cualquier repositorio basta con hacer clic en botón fork que vamos a encontrar en cada repositorio, como se muestra en la anterior captura de pantalla.
Una vez creada la copia, podemos solicitar al repositorio original integrar los cambios que se han creado. Esto no se puede hacer de forma directa, se hace mediante una solicitud pull request.
El pull request en git
Esta es una característica para gestionar los cambios en proyectos. Se trata de una petición con la que poder hacer merge de una rama a otra rama del repositorio, generalmente la master. El pull request también se permite utilizar desde distintos repositorios.
Probando un pull request
En el siguiente ejemplo vamos a utilizar pull request en GitHub para un supuesto proyecto. Supondremos que el repositorio remoto están en GitHub y es el repositorio de referencia.
En primer lugar vamos a actualizar el repositorio local, para tenerlo todo al día antes de introducir cambios.
Como se puede ver en la anterior captura, en este repositorio todo estaba actualizado. Una vez que la rama master local esté actualizada, procedemos a abrir una rama para introducir los cambios que queramos:
Nos hemos cambiado ya a la nueva rama. El siguiente paso será crear un nuevo archivo (la forma de crearlo, ya queda al gusto de cada uno) llamado nuevo.php:
Continuamos añadiendo y confirmando los cambios con:
git add . git commit -m "Un nuevo archivo añadido"
El siguiente paso será hacer un push a remoto, que si has seguido los anteriores volúmenes de esta serie de artículos, debería apuntar hacia el repositorio creado en GitHub.
git push --set-upstream origin feat/nueva-funcionalidad
Si vamos ahora a la web del repositorio en GitHub veremos lo siguiente:
Esta advertencia detecta que el usuario ha subido una nueva rama sobre el repositorio. Por esto nos va a ofrecer la posibilidad de generar el pull request.
En él podremos incluir una descripción de los cambios y veremos en detalle qué se ha modificado, y la comparación con el código anterior. Además GitHub va a detectar si existe algún conflicto con la rama a la que se le quiere hacer merge.
Una vez creado el pull request, ya podemos mergearla en master. Este mecanismo resulta especialmente útil cuando para trabajar en equipo, y que otro usuario haga una revisión del código. Nos podrá dejar comentarios. Hay que aclarar que podremos hacer un pull request de cualquier rama en cualquier momento.
Actualizando un Pull Request
Cuando más de un usuario trabajan en un mismo repositorio, es bastante habitual que mientras un pull request espera a ser mergeado, otro lo sea. Esto puede que no afecte en nada, o que provoque conflictos y no se pueda mergear el pull request que está a la espera.
Vamos a provocar esta situación creando una nueva rama y creando un fichero con el mismo nombre:
Si ahora nos dirigimos a GitHub, veremos que nos va a sugerir un nuevo pull request. Si en este caso mergeamos veremos el conflicto que se presenta con la otra rama.
Lo habitual suele ser confirmar y eliminar la rama. En cualquier momento se pueden utilizar los botones para revertir el commit.
Rolviendo conflictos
Siguiendo con el apartado anterior, veremos que al hacer merge de otro pull request va a afectar a los mismos archivos, en el pull request abierto, veremos aparecer conflictos.
Esto se puede intentar corregir en GitHub, cosa que en un ejemplo como el que tenemos entre manos sería sencillo. Pero lo conveniente es corregir los conflictos en local.
Los pasos a seguir en la terminal de nuestro equipo sería; cambiar a master, hacer una actualización git pull origin master. Con esto vamos a actualizar nuestro master local, y tener los cambios que se han mergeado en el otro pull request.
Después nos vamos a pasar a la rama que tiene el conflicto en el pull request:
Y seguimos haciendo un rebase de master, para que esté a la última. Este rebase va a tomar la rama actual y le aplicará todos los cambios que se han hecho, dejando la rama actual para el final:
git rebase master
Esto nos va a provocar el mismo conflicto que hay en GitHub. Una vez resuelto el problema utilizaremos los comandos:
git add nuevo.php git rebase --continue
En este punto tendremos que hacer push a remoto, y la pull request no tendrá conflicto. Como nuestros cambios locales estarán por delante de lo que hay en el repositorio, lo mejor que podemos hacer es utilizar la opción -f. Esta va a machacar la rama remota y será igual que la que tenemos en la rama local. En este caso es lo deseable, ya que la rama local es la que tenemos actualizada y sin conflictos.
git push origin -f feat/nueva-funcionalidad
Esto va a hacer una actualización a la fuerza. El resultado también lo deberemos en GitHub.
Llegados hasta aquí, ya no tendremos conflictos y podremos hacer un merge sin problemas.
Por regla general, si tenemos un pull request abierto y hubo nuevos cambios enmaster, resulta conveniente hacer un rebase. Esto hara que nuestra rama esté lo más actualizada posible. En caso de conflictos, podremos corregirlos de forma sencilla y progresiva utilizando git.
Y con esto vamos a dejar el volumen 6 de esta serie de artículo sobre git. En otro momento más y mejor, aun que no prometo nada.
