Git: mantener un fork de un repositorio actualizado

Tutorial de git en el que veremos cómo mantener un fork de un repositorio actualizado con los cambios que se hagan en el original.

Esta es la situación:

1. Queremos colaborar con código en un repositorio que se encuentra en un servicio de hospedaje (como por ejemplo GitLab o GitHub).
2. Como en el repositorio oficial no tenemos permisos para hacer modificaciones, hacemos un «fork» del repositorio original en nuestro espacio, clonamos este «fork» trabajamos sobre él.
3. Después de subir nuestros commits hacemos un «pull request» para que el desarrollador del repositorio original lo revise y acepte o no dicho «pull request».
4. Pero ¿cómo mantenemos nuestro «fork» actualizado con las modificaciones que el desarrollador vaya incorporando en el proyecto original? Esa pregunta es la que quiere responder este artículo.
5. Imaginemos que tanto el repositorio original como el «fork» están en GitHub.

¿He explicado bien cual es el meollo de la cuestión?

La cosa es saber cómo mantener nuestro fork actualizado, para si en un futuro queremos volver a participar en otra cuestión, este este actualizado y no sea un dolor de cabeza enorme para el desarrollador tratar de incorporar nuestras actualizaciones con partes de código obsoletas.

Una vez clonado nuestro fork en nuestro equipo podemos ejecutar un
git remote -v
que nos mostrará los repositorios remotos a los que apunta nuestro «fork».

Deberemos añadir un nuevo repositorio remoto «upstream» que será sincronizado con el fork, para ello ejecutamos lo siguiente (mutatis mutandis):

git remote add upstream https://github.com/usuario_original/repositorio_original.git

Si volvemos a ejecutar un
git remote -v
veremos que ahora aparece el repositorio «upstream».

Ahora hay que enlazar nuestro repositorio local con el «upstream» para ello ejecutamos:

git fetch upstream

Hecho esto ahora deberemos «traer» los commits del repositorio original a nuestra copia. Dichos commits del repositorio se almacenarán en una rama separada llamada «upstream/master».

Es decir que en nuestro repositorio «forkeado» y clonado habrá una rama aparte en la que se irán acumulando las actualizaciones que se hagan en el repositorio original, y deberemos ir uniendo («merge») a la rama master de nuestro repositorio clonado, y hecho eso podremos ir modificándolo para hacer nuestros aportes.

Pero por partes ¿Cómo se hace todo eso?

Vayamos a nuestra rama master de nuestro repositorio «forkeado» mediante:
git checkout master
y nos dirá que hemos cambiado a la rama master.

Desde nuestra rama ahora lo que queremos es «unir» las actualizaciones de repositorio original. Para eso deberemos utilizar el comando merge de git. Esto lo hacemos mediante:
git merge upstream/master

Por cierto, esto actualiza nuestra copia local del repositorio. Deberemos hacer un commit y push a nuestro fork para que estén de manera remota esos cambios actualizados.

No soy un experto de git, lo utilizo sólo como «aficionado», y voy aprendiendo sobre la marcha aquello que voy necesitando. Git es una gran herramienta con un montón de posibilidades y opciones. Espero que esta explicación te sirva…

He tratado de explicar de manera sencilla lo que he aprendido hoy sobre git ¿Lo has entendido? Si mi explicación no ha sido muy clara, te dejo los enlaces de donde he sacado toda esta información para ver si así aclaramos conceptos… 😉

• https://help.github.com/articles/configuring-a-remote-for-a-fork/
• https://help.github.com/articles/syncing-a-fork/

Un par de enlaces adicionales para aprender algo más sobre las ramas o «branch» con las que podemos trabajar y utilizar en nuestros proyectos git:

• Ramificaciones en Git – Procedimientos básicos para ramificar y fusionar
• Ramificaciones en Git – Ramas Remotas

——————————————————————-