Guía esencial de GitHub: Introducción para principiantes

Si trabajas en proyectos en los que tienes que manejar código junto con otras personas, sabrás lo importante que es llevar una buena organización. Para ayudarte en esta tarea existe Git, que es un sistema de control de versiones que te ayuda a gestionar el código de tus proyectos. Por otro lado está GitHub, que es una plataforma basada en Git a través de la cual tu y tu equipo vais a poder alojar en la nube el código de vuestras aplicaciones y llevar un control del historial de cambios. En este artículo te voy a hablar sobre qué es GitHub y sus características. ¡Empezamos!

¿Qué es GitHub y por qué es importante?

La plataforma GitHub nació en el año 2008 gracias a Chris Wanstrath, P. J. Hyett, Tom Preston-Werner y Scott Chacon. En su primer año de vida, GitHub consiguió almacenar 46.000 repositorios públicos y alcanzar la cifra de 100.000 usuarios. Un año después, en 2010, llegaban al millón de repositorios, cifra que doblarían en 2012 llegando a los dos millones. La popularidad de la plataforma siguió en constante aumento hasta llegar al punto de que en el año 2018 la compañía fue adquirida por Microsoft por 7.000 millones de dólares.

Con estas cifras, ya te estarás haciendo una idea de la relevancia que ha tenido y sigue teniendo GitHub entre los desarrolladores. A día de hoy es la plataforma más popular para alojar proyectos en la nube con un sistema de control de versiones. Tanto es así que muchas empresas y marcas conocidas lo utilizan en su día a día para alojar el código de sus proyectos:

• Microsoft: Visual Studio Code o TypeScript.


• Google: Kubernetes o Angular.


• Facebook: React.


• Netflix: Hystrix.


• Twitter: Bootstrap.

Estas son solo algunas de las compañías que utilizan GitHub para alojar y administrar sus proyectos.

Diferencias entre Git y GitHub

Aunque Git y GitHub están claramente relacionados, son conceptos distintos.

Git es un sistema de control de versiones creado por Linus Torvalds (el creador de Linux). Un software creado para llevar un registro de cambios en los archivos de un proyecto. Git se ejecuta de manera local, de forma que ese registro de cambios permanece en el ordenador en el que se está utilizando la herramienta. Aunque existen interfaces gráficas (GUI), Git fue pensando para utilizarlo con la terminal a través de líneas de comandos.

Por otro lado, GitHub es una plataforma colaborativa en la nube y basada en Git que sirve para gestionar proyectos y llevar un control de las versiones de nuestro código. Gracias a GitHub, puedes colaborar y trabajar con otros desarrolladores en el mismo proyecto, ya que los repositorios de GitHub se alojan remotamente en la nube. La plataforma web de GitHub te proporciona una interfaz gráfica para manejar y administrar tus repositorios. Además, te aporta características adicionales como revisiones de código, "pull request", seguimiento de errores o "issues", "forks", etc.

Características principales de GitHub

• Se basa en Git: GitHub utiliza el sistema de control de versiones Git.


• Se basa en repositorios: Los archivos de los proyectos se almacenan en la nube en unos espacios llamados repositorios, a través de los cuales puedes llevar un seguimiento del historial de cambios de los mismos, invitar a otras personas a colaborar en ellos, etc.


• Fomenta la colaboración: GitHub es una plataforma colaborativa para desarrolladores que permite a varias personas trabajar a la vez sobre el mismo repositorio. Además, existe la posibilidad de que la comunidad pueda participar aportando soluciones a través de "pull request" a posibles problemas, proponiendo nuevas características o simplemente aportando "feedback".


• Permite crear fácilmente la documentación de tus proyectos a través de "wikis".


• Seguimiento y reporte de errores: GitHub cuenta con un sistema de seguimiento de errores o "issues" que sirve para reportar fallos o proponer nuevas funcionalidades.

Cuándo y por qué utilizar GitHub

Si quieres gestionar el desarrollo de un proyecto de manera colaborativa, GitHub es la herramienta que necesitas. El hecho de alojar el código fuente de tu proyecto en esta plataforma te aportará numerosas ventajas a la hora de trabajar en equipo o con otros desarrolladores:

• Sistema de control de versiones


• Seguimiento de problemas y errores


• Solicitudes de cambios


• Integración con otros servicios

En resumen, GitHub es para ti si necesitas trabajar en tu proyecto de manera colaborativa, llevar un control de los cambios y tener un sistema de seguimiento de problemas.

Cómo crear una cuenta en GitHub

Si quieres empezar a utilizar GitHub y beneficiarte de todas sus ventajas, lo primero que tienes que hacer es acceder a la web oficial de GitHub y crearte una cuenta de usuario. Para que te resulte más sencillo, te voy a guiar en el proceso.

Cómo registrarse en GitHub

Registrarse en GitHub es un proceso sencillo. Para empezar, tienes que acceder a la web de GitHub y pulsar en el botón "Sign up" de la parte derecha del menú superior.



A continuación, tienes que introducir una serie de datos como un correo electrónico, contraseña y nombre de usuario. Puedes elegir también si quieres recibir novedades acerca de GitHub por email. En cuanto hayas cubierto los datos y resuelto el captcha de seguridad, te aparecerá un campo para que introduzcas un código de confirmación que te enviarán al correo que has elegido anteriormente. Una vez hecho esto, tu cuenta ya estará dada de alta y podrás a empezar a configurar tu perfil de usuario de GitHub. De todas formas, si tienes dudas acerca del proceso de registro puedes profundizar más sobre este tema en la documentación oficial de GitHub: https://docs.github.com/es/get-started/start-your-journey/creating-an-account-on-github

Configurar el perfil de GitHub

Lo primero que te encontrarás, una vez accedas a tu cuenta por primera vez, es una pantalla para que configures tu "feed". En esta pantalla puedes elegir tus temas favoritos de los cuales quieres mantenerte al día dentro de la plataforma (HTML, CSS, React, JavaScript, Laravel, tutoriales, IA, etc.).



Para configurar tu perfil de GitHub, dirígete al icono de tu avatar en la parte derecha del menú superior. Pulsa en él y verás cómo se despliega un menú en el que puedes configurar tu estado en línea con un icono y una frase y en el que, además, tienes accesos a distintos apartados de tu perfil. Vamos a verlos.



Your profile



Esta es la página principal de tu perfil de GitHub. Aquí verás un resumen en forma de gráfica de tus contribuciones a lo largo del tiempo, así como tus principales repositorios. En la parte derecha, debajo de tu foto de perfil verás un botón de "Edit profile"; si lo pulsas, podrás cambiar la información básica de tu perfil: nombre, bio, pronombres, localización, redes sociales, etc. Tu página de perfil de GitHub se puede personalizar creando un repositorio cuyo nombre sea exactamente el mismo que tu nombre de usuario de GitHub.

Your repositories



Aquí verás todos los repositorios que has creado. Puedes filtrar por tipo (públicos, privados, forks...), por idioma y ordenarlos (por nombre, fecha...). Puedes marcarlos como favoritos con el botón "Star" y asignarlos a diferentes listas.

Your projects



En GitHub también puedes crear proyectos para organizar el trabajo de desarrollo. Los proyectos de GitHub te servirán para crear hojas de ruta o crear tarjetas con prioridades para las tareas a realizar. Desde este apartado puedes ver todos los proyectos que tengas creados.

En los proyectos de GitHub puedes configurar diferentes tipos de vista: modo tabla (table), tablero de tarjetas (board) u hoja de ruta (roadmap).

Your stars



Puedes marcar cualquier repositorio (tuyo o de otra persona) con una estrella a modo de "favorito" para así encontrarlo de manera más rápida posteriormente. Al guardar un repositorio como favorito, GitHub podrá mostrarte contenido relacionado. Además, este sistema favorece al creador del repositorio en el sentido de que tener más estrellas aporta cierto reconocimiento dentro de la plataforma. También puedes organizar tus "favoritos" en listas si lo necesitas.

Your gists



A veces se puede dar el caso de que tengas un código que no es lo suficientemente grande como para que merezca la pena crear un repositorio. Para esos casos existen los "gists". Un gist te va a servir para compartir o simplemente almacenar fragmentos de código (snippets). Al igual que un repositorio, un gist se puede clonar, puedes hacer "fork" y se puede comentar. También puedes seleccionar si quieres que sea público o privado. En esta sección tendrás un listado de todos tus gists.

Your sponsors



Para apoyar económicamente a las personas y organizaciones que crean y alojan proyectos de código abierto en GitHub, la plataforma tiene un sistema de patrocinio. Puedes apoyar a aquellas personas y u organizaciones que tengan perfil de desarrollador patrocinado. Para ello, puedes aportar dinero de manera mensual o de manera puntual. Las personas o empresas que estén siendo patrocinadas pueden configurar una serie de beneficios para la gente que les apoye económicamente.

En esta sección podrás ver tanto las cuentas a las que estas patrocinando como las que te patrocinan a ti (si tu perfil es apto para ello).

Upgrade y Try enterprise

GitHub es gratuito y puedes utilizarlo sin tener que pagar nada, pero puedes aumentar las características que te ofrece si contratas un plan de pago. Los precios van desde 4 dólares por usuario al mes del plan Pro a los 21 dólares del plan Enterprise.

Si quieres ver en detalle las mejoras que te ofrece, puedes consultar los precios de los planes de GitHub.

Feature preview



Si pulsas en esta sección, verás una ventana emergente en la que se muestran características de GitHub que están disponibles en la versión beta. Desde aquí puedes habilitar o deshabilitar cada una de ellas.

Help



Una de las cosas que más me gustan es lo completa y detallada que es la documentación oficial de GitHub. Desde este menú tendrás acceso a ella para consultar cualquier detalle acerca de la plataforma.

Settings

Dentro de los ajustes puedes personalizar diferentes aspectos de tu cuenta de GitHub.

Por un lado, puedes cambiar tus datos públicos (nombre, bio, redes sociales, etc.), ajustes de tu cuenta, apariencia de la interfaz, ajustes de accesibilidad o notificaciones.

En el apartado "Access" puedes cambiar el tipo de cuenta a una de pago, configurar tu email y contraseña de acceso, administrar las sesiones abiertas o configurar tus claves SSH.

En "Code, planning, and automation" puedes ver tus repositorios, codespaces, etc. Además, desde esta sección puedes probar GitHub Copilot, un asistente basado en una IA que te ayudará a escribir tu código.

En "Security" podrás configurar los ajustes de seguridad para que tus repositorios estén seguros y en "Integrations" podrás integrar GitHub con aplicaciones externas.

Finalmente, en "Archives" tienes un registro de acciones o "log" que has realizado dentro de la plataforma.

Conceptos básicos en GitHub

Si conoces Git, ya estarás familiarizado con conceptos como repositorio, rama o "commit". Pero, si eres nuevo en el mundo de los sistemas de control de versiones, te recomiendo que sigas leyendo para saber más acerca de estos conceptos básicos.

Qué es un repositorio y cómo crearlo

Un repositorio es el almacén virtual donde organizar los archivos de un proyecto. En GitHub, los repositorios utilizan el sistema de control de versiones de Git por lo que es posible mantener un historial de cambios a lo largo del desarrollo. En un repositorio puedes almacenar diferentes tipos de archivos: archivos de código en diferentes lenguajes, imágenes, documentos, etc. En GitHub puedes colaborar con otros desarrolladores ya que puedes invitar a otros usuarios a participar en tu repositorio.

Puedes crear un repositorio en GitHub de varias formas:

• Desde el botón "New" del sidebar de la parte izquierda de la página principal.
  


• Desde el icono "+" del menú superior.
  


• Desde el botón "New" dentro del menú "Repositories".
  

En cualquier caso, al crear un repositorio en GitHub debes configurar una serie de campos.



Propietario (owner): Cuando creas un repositorio, tú serás por defecto el propietario del mismo, por lo que tendrás control absoluto sobre sus configuraciones y permisos. Sin embargo, también puedes asignar a otro usuario u organización la propiedad del repositorio si así lo deseas.

Nombre del repositorio (repository name): Elige un nombre para tu repositorio. Mi consejo es que sea corto. fácil de recordar y que sea representativo de tu repositorio.

Descripción (description): De forma opcional, puedes añadir una descripción para añadir más información acerca de tu repositorio.

Público o privado (public/private): Puedes elegir la visibilidad de tu repositorio y restringir el acceso a él si lo deseas. El modo público hace que el repositorio sea accesible a cualquier usuario y con el modo privado puedes elegir los usuarios con los que compartirlo.

Añadir archivo README: El archivo README es la carta de presentación de tu repositorio. Es lo primero que verá un visitante al entrar a tu repositorio y en él puedes describir para qué sirve tu código, cómo utilizarlo, etc.

Añadir .gitignore: Al crear un repositorio, puedes indicar una serie de archivos o carpetas para que sean excluidas e ignoradas por GitHub.

Licencia (license): En GitHub se comparten muchos repositorios de código abierto, pero para que realmente sea de código abierto necesitas asignarle una licencia. No es obligatorio que lo hagas, pero debes tenerlo en cuenta al crear tu repositorio. Puedes elegir varios tipos de licencia: GNU, MIT, Creative Commons, etc. Para ayudarte a elegir la licencia adecuada para tu proyecto, la gente de GitHub ha creado un sitio web que te ayudará a elegir la licencia correcta según tus necesidades.

Una vez tengas los campos necesarios cubiertos tan solo tienes que pulsar en el botón de "Create repository" para crear tu repositorio.

Qué es una rama: creación y uso

Una rama o "branch" es una línea paralela con la que trabajar en el desarrollo del código sin afectar a la rama principal. Las ramas se utilizan para desarrollar nuevas características o corregir errores sin que ello afecte al código original. De esta manera, si en tu aplicación tienes pensado añadir una nueva funcionalidad, deberás crear una rama para desarrollarla. Una vez tengas el código de esta nueva funcionalidad terminado y testeado, tendrás que fusionar ("merge") dicha rama con la rama principal que, por normal general, en GitHub se llama "main".



La captura anterior es un gráfico de ejemplo en el que, a partir de la rama principal "main", se ha creado una rama paralela llamada "dev". En esa rama "dev" se han hecho una serie de cambios y, finalmente, se ha vuelto a fusionar ("merge") con la rama "main".

Si entras en un repositorio, puedes ver el número de ramas que tienes creadas en él y administrarlas.



Como te decía, en todos los repositorios que crees en GitHub existirá por defecto la rama "main" como rama principal. Para crear más ramas en tu repositorio, pulsa en "1 branch" (en mi caso es así porque solo tengo una rama). En la siguiente pantalla verás todas las ramas que tengas creadas. Para crear una nueva, pulsa en el botón "New branch".



En la ventana emergente que se te abrirá, introduce un nombre para tu rama y selecciona cuál será su rama origen o "branch source". Finalmente, pulsa "Create branch" para crear la rama. Para elegir un nombre para tu rama, recuerda utilizar un nombre que describa el propósito que tiene dicha rama.

Qué es un commit

Cuando modificas código en tu repositorio y tienes listos los cambios, tienes que confirmarlos haciendo un "commit". Dicho de otra manera, es la forma de "guardar" los cambios en el repositorio de GitHub. Un "commit" no tiene por qué ser únicamente la confirmación de los cambios en un único archivo o en una misma línea de código, sino que se refiere más bien a un conjunto de cambios. Cada "commit" que hagas es una captura de tu código en un momento concreto del tiempo, algo así como un punto de guardado. Gracias al uso de los "commit" podrás ir generando un historial de cambios estructurado y organizado.

Al editar un archivo o archivos en GitHub tendrás que hacer "commit" pulsando el botón "Commit changes".



Se te abrirá una ventana emergente para que cubras los campos necesarios para realizar el "commit".



Commit message: Todos los "commit" que hagas llevarán un mensaje que debe describir para qué es el "commit". Normalmente se suelen utilizar un prefijo seguido de dos puntos y una pequeña frase que describa el propósito de los cambios realizados. Por ejemplo:

• add para añadir archivos (add: create style.css)


• feat para añadir una nueva funcionalidad (feat: add search field in header)


• fix para corregir errores (fix: bug in contact form)

Extended description: Si necesitas añadir comentarios adicionales para explicar en qué consiste el "commit", puedes escribirlos en este campo.

Elección de la rama en la que hacer el "commit": Puedes hacerlo directamente en la rama "main" o crear una nueva rama para ello y hacer un "pull request" (petición para incorporar los cambios del "commit").

Una vez tengas todo listo, pulsa en "Commit changes" (si has elegido hacerlo sobre la rama "main") o "Propose changes" (si has elegido crear una nueva rama).

Uso de GitHub para colaborar o contribuir en proyectos

Como te decía al principio, GitHub es una plataforma pensada para que los desarrolladores colaboren entre sí en proyectos. Existen determinadas acciones para ello que deberías conocer.

Clonar un repositorio de GitHub en local

Los repositorios de GitHub son repositorios que se encuentran en la nube. Pero, ¿qué pasa si quiero trabajar con un repositorio de GitHub de manera local en mi ordenador o en un codespace (entorno de desarrollo alojado en la nube)? En ese caso, necesitas clonar el repositorio y sincronizar esa copia con GitHub para que los cambios que hagas de manera local se reflejen el repositorio remoto.

A continuación, te voy a explicar cómo clonar un repositorio de GitHub de manera local en tu ordenador y sincronizarlo. Lo haré con la terminal a través de comandos, pero también es posible hacerlo con una de las muchas interfaces gráficas (GUI) que existen, como GitHub Desktok, GitKraken o GitAhead.

Antes de nada, voy a partir de la base de que tienes instalado Git en tu ordenador y una terminal como Git Bash. Si todavía no lo tienes, puedes descargar Git en el siguiente enlace: https://git-scm.com/downloads. Elige el sistema operativo que te interese y sigue los pasos del proceso de instalación. Instalarás Git, la terminal Git Bash y una pequeña interfaz gráfica (Git GUI).

Clonar un repositorio de GitHub es bastante sencillo, tan solo tienes que seguir los siguientes pasos:

• Ve al repositorio de GitHub que quieras clonar y pulsa el botón "< > Code".
  


• Copia la URL del repositorio que se muestra en el desplegable.
  


• Abre Git Bash y sitúate en la carpeta en la que quieres clonar el repositorio. Puedes hacerlo con comandos a través de la terminal o haciendo clic derecho > Git Bash Here dentro de la carpeta en cuestión.
  


• Escribe "git clone" seguido de la URL que has copiado anteriormente; por ejemplo:
  git clone https://github.com/DavidRaiola/test.git
  A continuación, pulsa "Enter".
  

Si todo ha ido bien, verás algo como la captura anterior en tu terminal. Git descargará todos los archivos del repositorio a tu ordenador y ya lo tendrás clonado en la carpeta que hayas elegido.

Sincronizar un repositorio local con GitHub

En este punto tienes clonado el repositorio de GitHub de manera local en tu ordenador. Ahora mismo ya podrías trabajar de manera local y hacer cambios en el código de los archivos del repositorio. Ahora lo interesante sería conectar de alguna manera el repositorio que tienes en local con el de GitHub para que puedas subir los cambios a la plataforma. Veamos cómo hacerlo.

Lo primero que debes hacer es establecer un nombre de usuario y correo electrónico en Git. Esto es necesario ya que los "commits" que hagas utilizan esta información para identificar quién está realizando el "commit" en cuestión. En este caso, tienes que introducir tu nombre de usuario y email de GitHub. Para ello, abre la terminal de Git Bash y escribe lo siguiente:

$ git config --global user.name "[tu_usuario_de_github]"

$ git config --global user.email [tu_email_de_github]

Yo ya los he configurado y he hecho algunos cambios con un editor de código en el archivo index.html de mi repositorio. Voy a ejecutar el comando "git status" para ver el estado de los archivos del repositorio.



En la captura anterior puedes ver que hay cambios en el archivo "index.html", pero todavía no se encuentran en el área de "staging". Esta área es un espacio virtual donde se sitúan los archivos listos para ser enviados al repositorio haciendo un "commit". Por lo tanto, el siguiente paso es añadir el archivo index.html al área de "staging" con el siguiente comando:

git add index.html

Y finalmente hacer un "commit" con el siguiente comando:

$ git commit -m "[Mensaje del commit]"

Sustituye [Mensaje del commit] por un mensaje descriptivo que indique de manera concisa qué cambios estás realizando.



Ahora mismo los cambios están subidos al repositorio, pero de manera local. Es decir, tu repositorio local conoce los cambios que acabas de hacer, pero el repositorio remoto de GitHub todavía no. Para enviar estos cambios a GitHub tienes que utilizar el comando "git push".

git push origin [nombre_de_la_rama]

Sustituye [nombre_de_la_rama] por la rama a la que quieres enviar los cambios. En mi caso, los voy a enviar directamente a la rama "main".

Para que tu ordenador pueda enviar los cambios al repositorio remoto de GitHub, debe existir una conexión entre ambos. En mi caso, al instalar Git se ha instalado Git GUI (una pequeña interfaz gráfica), por lo que al hacer "git push" y no haber todavía ninguna conexión, se me abre la siguiente ventana para loguearme en GitHub:



Puedes loguearte desde el navegador o a través de un código de acceso. Elige el método que prefieras y, si todo ha ido bien, el "git push" se habrá realizado correctamente.



Si ahora entras al repositorio de GitHub, deberías ver subidos los cambios que acabas de realizar en local.



Así como el comando "git push" sirve para enviar los cambios al repositorio remoto de GitHub, existe otro comando para "traer" el contenido del repositorio remoto a nuestro repositorio local. Este comando es "git pull".

git pull

Esto es algo que deberías hacer siempre antes de empezar a hacer cambios en local. Imagina que estás trabajando en un proyecto con más desarrolladores. En el momento en el que vayas a trabajar sobre el código, es posible que alguien antes que tú haya hecho algún cambio en el mismo, por lo que lo lógico es que antes de nada traigas todos esos posibles cambios a tu repositorio local.

Forks y pull requests

Si en GitHub encuentras un repositorio en el que te interesa colaborar lo correcto es hacer un "fork". Hacer un "fork" de un repositorio es hacer una copia exacta e independiente del mismo en tu cuenta personal para trabajar en él. Todos los cambios que hagas afectarán a esa copia y no al repositiorio original. Finalmente, puedes hacer una "pull request" al repositorio original para proponer tus cambios. Una "pull request" no es más que una petición o solicitud de cambios que realizas al propietario del repositorio para que revise y fusione los cambios que le has propuesto. Para que entiendas mejor este proceso colaborativo, te muestro un ejemplo por pasos:

Fork de un repositorio

He encontrado un repositorio de otro usuario en el que quiero colaborar, así que dentro del mismo hago clic en "Fork" en la parte superior.



Al hacer la copia, puedo cambiar el nombre al repositorio y elegir qué ramas quiero clonar.



Una vez creado el "fork", tendré en mi cuenta una copia exacta del repositorio original, con todos sus archivos, historial de "commits", etc.

Sincronizar el fork con el repositorio original

Aunque este repositorio que acabo de clonar es una copia independiente del original, GitHub sabe que es un "fork" de otro. Si el propietario hace cambios en el repositorio original, lo ideal es que el "fork" que acabo de hacer pueda recibir e incorporar esos cambios. Para hacer esto existe la opción "Sync fork".



Si en el repositorio original no hay ninguna novedad, verás algo como la captura anterior. Por otro lado, si ha habido algún cambio verás algo como esto:



En la captura puedes ver que en el repositorio original hay un nuevo "commit". Si pulsas en "Update branch" te traerás esos cambios a tu "fork".

Cambios en fork del repositorio

Ya tengo el "fork" creado y sincronizado; es el momento de hacer algunos cambios. Para hacerlo recuerda el apartado en el que te hablé de cómo clonar un repositorio en local, hacer cambios y subirlos a GitHub (si son cambios pequeños, también podrías editar los archivos directamente en GitHub).

En mi caso, voy a editar el archivo "listado.md" para añadir algunos elementos al listado. Ahora mismo, esos cambios están en el "fork" que he creado, pero no están en el repositorio original.



Envío de pull request

Si quieres que los cambios que has hecho se incorporen al repositorio original, tienes que enviar una "pull request". De esta manera, le estás diciendo al propietario que has modificado algo en su repositorio, que lo revise y si así lo considera que los incorpore. Para hacerlo, vete a la página principal del repositorio y pulsa en "Contribute". Si has hecho cambios con respecto al repositorio original, verás un botón de "Open pull request".



En la siguiente pantalla, verás desde dónde y hacia dónde estás haciendo la "pull request". Es decir, desde qué repositorio y rama y hacia qué repositorio y rama. También puedes incluir comentarios si necesitas dar algún tipo de indicación al propietario del repositorio original.



Pulsa en "Create pull request" para hacer la solicitud y verás una pantalla como esta:



En este momento, tu "pull request" se encuentra a la espera de revisión y aprobación por parte del propietario del repositorio original.

Revisión de la "pull request" por parte del propietario del repositorio

Como propietario del repositorio, cuando recibas una "pull request" como la del ejemplo anterior verás algo como esto en tu repositorio:



Si pulsas en "Pull requests", verás un listado con todas las solicitudes que tengas.



Entra en la "pull request" para poder revisarla. En la pestaña "Files changed" podrás ver qué archivos han sido modificados y con qué código. Si consideras que todo está bien y quieres aceptar los cambios, pulsa en "Merge pull request".

Fusión de ramas o "merge"

Más arriba, cuando te hablaba de qué son las ramas, te mencioné que las ramas se pueden fusionar. Por ejemplo, si vas a añadir una nueva funcionalidad a tu proyecto crearás una rama para ello. Una vez tengas la nueva funcionalidad lista y testeada, la rama que has creado para ello estará lista para ser fusionada ("merge") con la rama principal. Al fusionar una rama con otra rama principal, se combinarán los cambios realizados en la nueva rama con la principal.

En GitHub, para fusionar dos ramas tienes que hacer una "pull request". Pero mejor te lo explico con un ejemplo:

En mi repositorio he creado una rama "feature/nueva-funcionalidad". Dentro de ella, he editado un archivo "style.css" y he hecho el "commit" correspondiente. Para fusionar la rama "feature/nueva-funcionalidad" con la rama "main", voy a crear una "pull request" desde la sección de "Pull requests". Lo verás más claro en la siguiente captura:



Pulsa en "New pull request" y en la siguiente pantalla elige las ramas que quieres fusionar. En "base" elige la rama origen y en "compare" la rama que quieres que sea fusionada. Luego pulsa en "Create pull request".



En la siguiente pantalla puedes dejar un comentario. Ten en cuenta que una "pull request" (solicitud de extracción) está pensada para solicitar cambios en un repositorio y que estos sean revisados y aprobados, por lo que a veces es interesante poder dejar comentarios al respecto de esa solicitud. Una vez tengas todo listo, pulsa en "Create pull request".



Ahora pueden pasar dos cosas:

Si todo va bien y GitHub no encuentra ningún conflicto entre las ramas, podrás hacer un "merge" y fusionarlas.



Como ves, hay 3 opciones:

• Create a merge commit: Se crea un "commit" para la fusión de las ramas y se conservan todos los "commits" individuales de cada rama.


• Squash and merge: Los "commits" se combinan en uno solo antes de fusionarse con la nueva rama.


• Rebase and merge: Los "commits" de la rama origen se insertan en la de destino reescribiendo la "línea de tiempo" de la rama de destino. No se crea un "commit" para la fusión de las ramas.

En mi caso, voy a usar la opción por defecto y pulsar en "Merge pull request". En la siguiente pantalla, se te pedirá confirmar la fusión de ramas.



Después de hacer clic en "Confirm merge", verás un mensaje que confirma que las dos ramas se han fusionado correctamente. A mayores, tienes la opción de borrar la rama que habías creado con el botón "Delete branch".

Resolver conflictos al fusionar ramas

Por otro lado, puede darse el caso de que al fusionar dos ramas GitHub encuentre algún conflicto. Para poder explicártelo, voy a provocar a propósito un conflicto entre dos ramas para que veas cómo proceder.

En mi repositorio tengo dos archivos (index.html y style.css) y dos ramas creadas (main y dev). Voy a modificar el archivo style.css de ambas ramas.

En la rama "main" le voy a añadir el siguiente código:

p{

  color: black;

}

Y en la rama "dev" le añadiré este otro código:

p{

  font-size: 1em;

}

Ahora voy a hacer una "pull request" para fusionar la rama "dev" con la "main". Al crear la "pull request" me sale el aviso de "Can't automatically merge", que quiere decir que la fusión de las dos ramas no se podrá hacer automáticamente, pero puedo crear la "pull request" igualmente.



Al crear la "pull request" me sale el aviso de que existen conflictos que necesitan ser resueltos para poder fusionar las ramas. En este caso, como he modificado la misma línea del mismo archivo tanto en "main" como en "dev", GitHub no sabe qué debe hacer. No sabe si el código con el que debe quedarse es uno u otro, por lo que hay que resolver este problema manualmente.



Al pulsar en "Resolve conflicts" se abrirá el editor de código. En mi caso, se puede ver lo siguiente:



GitHub me indica que en la rama "dev" he puesto una cosa ("font-size: 1em;") y en la rama "main" he puesto otra ("color: black;"), por lo que tengo que corregirlo. En este caso, como quiero conservar ambas propiedades CSS, hago el siguiente cambio, pulso en "Mark as resolved" y posteriormente en "Commit merge":



Como ya he resuelto los conflictos que había, ya puedo proceder a fusionar las ramas.

Consejos y mejores prácticas para GitHub

Al trabajar con GitHub, existen una serie de prácticas que te aconsejo llevar a cabo para aprovechar al máximo todo el potencial de la plataforma.

• Utiliza nombres descriptivos para los repositorios, commits y ramas: Esto te ayudará a ti y al resto de personas que participen en tus proyectos a identificar y entender el flujo de trabajo.


• Crea archivos README en tus repositorios: Utilízalos para aportar información relevante acerca del repositorio y documentarlo.


• Usa ramas para funcionalidades o corregir errores: Si creas una rama para cada nueva funcionalidad o cada vez que tengas que corregir un "bug", estarás contribuyendo a que el historial de cambios sea más fácil de seguir para el resto de desarrolladores.


• Usa las "issues": Son una excelente herramienta para avisar de posibles fallos o proponer ciertas tareas.


• Usa las "pull request": Cuando colaboras en un repositorio y propones código, debes hacer un "pull request" de tus cambios para que sean revisados y sean fusionados con la rama principal.


• Utiliza las etiquetas o "tags" para versionar tus proyectos.


• No subas claves ni contraseñas a tu repositorio.

Uso de etiquetas o tags en GitHub

En GitHub, las etiquetas o "tags" son referencias que puedes ir añadiendo a tu repositorio para "marcar" puntos concretos en la historia del mismo. Normalmente se usan para crear versiones dentro del repositorio.

Estas "tags" estás asociadas a un "commit" y puedes asignarles un nombre identificativo como, por ejemplo, el número de la versión.

Una versión es un punto concreto de un proyecto que se considera estable y terminado. Normalmente, las versiones se nombran con números; por ejemplo v1.2.7, v2.0.4, etc.

En GitHub, existen las "releases", que sirven para "lanzar" una versión. Al publicar una "release", puedes adjuntar archivos y documentación al respecto (para, por ejemplo, crear un "changelog").

Para crear una "release" dentro de un repositorio, ve a la página principal del mismo y pulsa en "Create a new release" en el panel lateral derecho.



Para publicar la "release" tienes que configurar una serie de campos.



Por un lado, tienes que elegir el "tag" o etiqueta. Puedes crear una nueva desde el propio desplegable. También puedes elegir la rama sobre la que vas a lanzar la "release". Escoge un título y añade una descripción si lo necesitas. Recuerda que es recomendable que escribas cuáles son las novedades y correcciones que vienen con cada versión que lanzas. También puedes adjuntar archivos en el campo que está justo debajo de la descripción.

Finalmente, puedes marcar el campo "Set as pre-release" si la versión que vas a publicar es una versión que todavía no está lista para producción.

Cuando tengas todo listo, pulsa en "Publish release" para publicarla.

Git Flow y GitHub Flow

Para mantener un orden y un flujo de trabajo adecuado dentro de un equipo de desarrollo, existen modelos de ramificación predefinidos. Estos sistemas establecen una serie de normas para estructurar de manera eficiente las ramas de un repositorio. Te voy a hablar de dos de los más utilizados.

Git Flow



En Git Flow existe una rama principal o "main" que contiene el código que está en producción y que solamente se utiliza para lanzar nuevas versiones del proyecto. Estas versiones se identifican en la rama mediante "tags" o etiquetas.

Por debajo de la rama "main" está la rama "develop", que es la rama de desarrollo donde se trabajarán nuevas funcionalidades y correcciones de errores. El código de esta rama es código que está testeado y revisado, por lo que es susceptible de ser fusionado con la rama "main" en cualquier momento.

Esas funcionalidades o correcciones de errores se trabajan en ramas "feature", que nacen de la rama "develop" y que se fusionan de nuevo a ella cuando la funcionalidad está terminada o el error corregido.

Cuando en la rama "develop" hay cambios listos para ser lanzados a producción, a partir de ella se crea la rama "release" que servirá para desplegar los cambios sobre la rama "main". Al cerrar una rama "release", automáticamente se creará un "tag" en la rama "main" con el nombre de la versión.

Existe un último tipo de rama que se utiliza en Git Flow: la rama "hotfix". Cuando hay un error en producción y es urgente repararlo, se crea una rama "hotfix" directamente desde la rama "main". Al cerrar una rama "hotfix", los cambios se vuelcan tanto sobre la rama "main" como sobre la rama "develop".

GitHub flow



GitHub Flow es una alternativa que propone el equipo de GitHub y que es más simple que Git Flow.

En este caso, sigue existiendo una rama principal "main" y de ella irán naciendo ramas para añadir nuevas funcionalidades o corregir errores. Cuando se tienen listos los cambios, se envía una "pull request" para que estos sean aprobados y se fusionen con la rama "main". En caso contrario, otros colaboradores pueden solicitar modificaciones o hacer comentarios sobre esa "pull request".

Conclusión

No hay duda de que GitHub se ha convertido en la plataforma colaborativa para desarrolladores más popular del mercado. Gracias a GitHub, puedes aprovechar las ventajas de un sistema de control de versiones basado en la nube para administrar tus proyectos.

Además, te aporta funcionalidades concretas para la revisión del código, seguimiento de errores o lanzamiento de versiones, entre otras. Gracias a esto, tú y tu equipo podréis trabajar en el código de vuestros proyectos de manera eficiente y efectiva.

Si este post te ha resultado útil o si tienes alguna duda con alguna funcionalidad de GitHub, no te lo pienses y deja un comentario 😄