Añadiendo cambios a un repositorio con fork

0
69

Índice de contenidos

  1. Introducción: cuándo hacer un fork de un repositorio
  2. Vamos al lío
  3. Conclusiones

1. Introducción: cuándo hacer un fork de un repositorio

En ocasiones en nuestros proyectos necesitamos abrir líneas de investigación o proponer cambios en repositorios que no son propios. La mejor alternativa en estos casos consiste en hacer un fork del repositorio original. El resultado del fork es un nuevo repositorio que comparte el mismo código y visibilidad que el repositorio original y en el cual podemos incorporar nuevos cambios sin que el origen se vea afectado. Una vez finalizado el trabajo, en el caso de que haya cambios que queramos incluir, es cuando se propone el merge en el repositorio original. En este tutorial veremos cómo realizar este proceso.

2. Vamos al lío

Supongamos que queremos proponer una mejora en la configuración del fichero .gitignore en el repositorio público de GitHub tntconcept-api. Lo primero que debemos hacer es acceder al repositorio y seleccionar la opción de fork:

Antes de hacer el fork, podemos configurar el nombre del repositorio, la descripción y las ramas que se van a copiar (por defecto solo main):

Cuando el proceso finalice, tendremos un nuevo repositorio idéntico al original pero del que somos propietarios.

Este repositorio podemos clonarlo y hacer los cambios oportunos.

En este caso, hemos modificado el fichero .gitignore con una nueva configuración. Hacemos commit y subimos los cambios:

Tras hacer push, en la página del repositorio GitHub se nos indica que hay cambios con respecto al repositorio original y que podemos incluirlos a través de una pull request (opción Contribute). También podemos sincronizar nuestro repositorio con el original en el caso de nuevos cambios en este último (opción Sync fork).

Abrimos la pull request hacia el repositorio original incluyendo los nuevos commits sobre el fichero gitignore:

Tras aceptar la pull request, los commits se mergean en el repositorio original sin haber tenido que trabajar directamente sobre él.

3. Conclusiones

Este proceso es el habitual que se sigue cuando se quiere colaborar en un repositorio del que no somos propietarios o proyectos open source, de modo que no «ensuciamos» el repositorio original con nuevas ramas ni código que no está validado. Es un proceso muy sencillo y guiado a través de los gestores de repositorios remotos como hemos visto con GitHub de modo que hay muy poco margen de error. De todos modos, los propietarios del repositorio original tienen la última palabra y serán los que acepten (o no) nuestros cambios.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad