Git y GitHub: Conceptos Principales

En el artículo de Control de versiones, ya vimos qué es un control de versiones y cuáles son los principales actores en el mundo del desarrollo de software. En esta ocasión veremos qué es Git, GitHub, diferencias entre ambos y sus principales conceptos como push, pull, clone, fetch… entre otros.

Este artículo forma parte de nuestra serie donde te contamos todo lo que necesitas saber para adquirir las competencias necesarias para trabajar con Git

¿Qué es Git?

En el ámbito del software Git = Control de Versiones. Se trata de un sistema de control de versiones open-source distribuido creado por Linus Torvalds en 2005 para gestionar el desarrollo del kernel de Linux, pero desde entonces se ha convertido en una herramienta estándar en la industria del desarrollo de software.

A diferencia de los sistemas de control de versiones centralizados, Git es un sistema distribuido, lo que significa que cada usuario tiene una copia completa del repositorio en su máquina local. Esto permite a los desarrolladores trabajar de forma independiente y sin conexión a Internet, además de facilitar la colaboración y la integración de cambios de múltiples fuentes.

Git se ha convertido en una herramienta esencial en el desarrollo de software debido a su flexibilidad, eficiencia y capacidad de manejar proyectos de cualquier tamaño. Su popularidad se debe en parte a la gran comunidad de usuarios y a la amplia gama de herramientas y servicios compatibles con Git.

En este artículo te enseñamos a instalar Git.

¿Qué es GitHub?

Pocos temas tocamos en WeLearnData sin meter a la nube de por medio, y es que gracias a aplicaciones en la nube como GitHub, podemos sacarle mucho más partido a Git.

GitHub es una plataforma en la nube que utiliza el sistema de control de versiones Git para alojar repositorios de código y facilitar la colaboración en proyectos de desarrollo de software. Es ampliamente utilizado por la comunidad de desarrollo de software para compartir, colaborar y contribuir a proyectos de código abierto y privados.

Características principales de GitHub

1. Repositorios: GitHub permite a los desarrolladores almacenar y gestionar sus proyectos en repositorios. Cada repositorio contiene todo el historial de cambios, ramas y archivos de código fuente de un proyecto específico.
2. Control de versiones: GitHub utiliza Git como su sistema de control de versiones, lo que permite a los desarrolladores realizar un seguimiento de los cambios en el código, crear ramas separadas y fusionar los cambios de diferentes fuentes.
3. Colaboración: GitHub fomenta la colaboración y la contribución abierta al permitir a los desarrolladores clonar (hacer una copia local) de los repositorios de otros, proponer cambios a través de “pull requests” (solicitudes de extracción) y revisar y comentar el código de otros.
4. Issues y seguimiento de proyectos: GitHub proporciona herramientas para el seguimiento de issuesy la gestión de proyectos. Los usuarios pueden abrir los issues para informar errores, solicitar nuevas características o plantear cualquier otra cuestión relacionada con el proyecto.
5. Integración continua y despliegue continuo (CI/CD): GitHub permite la integración con servicios de CI/CD, lo que facilita la automatización de pruebas, compilación y despliegue de aplicaciones. Esto mejora la eficiencia del proceso de desarrollo y garantiza la calidad del código.

Conceptos de Git

Repositorio – Local y remoto

Un repositorio en Git es un lugar donde se almacena y administra el código de un proyecto. Es una estructura de datos que registra todos los cambios realizados en los archivos a lo largo del tiempo, lo que permite rastrear y controlar el historial de versiones del proyecto. Contiene todos los archivos del proyecto, así como metadatos adicionales de Git. Esto incluye información como los commits (registros de cambios), las branches (líneas de desarrollo independientes), las tags (marcadores para versiones específicas) y otros datos relacionados con la gestión de versiones.

Un repositorio local en Git se refiere a una copia del repositorio de código que se encuentra en tu máquina local. Es un directorio en tu sistema de archivos. Los repositorios locales en Git son autónomos y te permiten trabajar de manera independiente. Puedes experimentar, probar nuevas características y realizar cambios en tu propio entorno antes de compartirlos con otros colaboradores

Y en cuanto al repositorio remoto, se trata de una versión del repositorio que se encuentra en un servidor. Es un repositorio centralizado al que los desarrolladores pueden acceder, y con el que pueden interactuar para colaborar en un proyecto. Los repositorios remotos son esenciales para la colaboración y la coordinación en equipos de desarrollo. Permiten a los desarrolladores trabajar de forma independiente en sus repositorios locales, realizar cambios y luego compartirlos y sincronizarlos con otros a través del repositorio remoto.

GitHub, GitLab y Bitbucket son ejemplos populares de plataformas que ofrecen servicios de alojamiento de repositorios remotos.

git commit

Vamos con el concepto más importante de Git. Un commit representa una instantánea de los cambios de los archivos del repositorio en un momento concreto. Cuando realizas un commit en Git, estás guardando un conjunto de modificaciones en uno o varios archivos en tu repositorio. Los commits se crean voluntariamente, es decir, guardar archivos no va a generar commits automáticamente, sino que nosotros especificamos qué cambios queremos en el nuevo commit.

Cada commit tiene un identificador único que lo diferencia de los demás. Este identificador se denomina “hash” o “SHA-1”, y es una cadena alfanumérica que identifica de manera única el commit en el historial.

Los commits en Git forman un historial de versiones que registra todos los cambios realizados en el repositorio a lo largo del tiempo. Esto permite a los desarrolladores rastrear y revertir cambios anteriores, colaborar de manera efectiva en equipo y mantener un registro claro de los avances en el desarrollo del proyecto.

Working Directory vs Staging Area vs Repository

Se trata de tres espacios empleados para manejar los cambios en el repositorio.

Working Directory (Directorio de trabajo) es el directorio en tu sistema de archivos local donde tienes todos los archivos de tu proyecto. El directorio en el que trabajas y realizas modificaciones en tus archivos. Estos cambios aún no se han registrado en el repositorio de Git. El Working Directory contiene la versión más reciente de los archivos, ya sean modificados, nuevos o eliminados.

Staging Area (Área de preparación): es un área intermedia entre el Working Directory y el Repository. Se trata del lugar donde irás añadiendo los cambios que deseas incluir en el próximo commit. Antes de hacer un commit, debes agregar explícitamente los archivos modificados a la Staging Area mediante el comando git add.

Repository (Repositorio). Representa la base de datos centralizada que registra todos los commits realizados. El Repository es la versión “oficial” del proyecto. Todos los archivos del Staging Area se convertirán en un commit mediante el comando git commit.

Branches

Una branch (rama) es una línea de desarrollo independiente que se crea a partir de un commit específico en un repositorio. Representa una serie de commits que siguen una secuencia de cambios separada de la rama principal (generalmente llamada “master” o “main”). Las branches permiten a los desarrolladores trabajar en diferentes características o solucionar problemas sin afectar directamente la rama principal del proyecto.

Al crear una branch, se crea una copia exacta del commit desde el cual se creó la rama. A partir de ese punto, puedes realizar nuevos commits en la branch sin afectar la rama principal o las otras ramas existentes. Esto te permite experimentar, desarrollar nuevas funcionalidades, solucionar problemas o realizar cambios en tu propio entorno sin interferir con el trabajo de otros colaboradores.

Las branches en Git son útiles para organizar el trabajo en paralelo, desarrollar características de forma aislada y permitir una colaboración efectiva en equipos.

Tenemos un artículo donde te enseñamos a trabajar con las ramas de Git.

git merge

Merge (fusión) es una operación que combina los cambios de una rama con otra rama existente en el repositorio. La fusión de ramas permite combinar diferentes líneas de desarrollo y unir los cambios realizados en cada una de ellas en un nuevo commit de fusión.

Cuando se realiza un merge, Git busca los cambios realizados en la rama de origen y los aplica a la rama de destino, creando un nuevo commit que representa la combinación de ambas ramas.

El merge se utiliza principalmente para incorporar los cambios realizados en una rama secundaria (por ejemplo, una branch de desarrollo de una nueva funcionalidad) en la rama principal (generalmente la rama master o main). De esta manera, se integran las nuevas características o soluciones de problemas en la rama principal del proyecto.

Es posible que aparezcan conflictos en la fusión de ramas si en ambas se ha modificado el mismo archivo. En ese caso, Git solicitará al usuario que resuelva manualmente el conflicto antes de completar el merge.

Main/Master

Main es el nombre de una rama predeterminada que se utiliza comúnmente como rama principal en un proyecto de git.

La rama main (o cualquier otra rama principal que se utilice en un proyecto) suele ser la rama base donde se encuentran los commits principales y estables del proyecto. Es común que la rama main contenga el código de producción y refleje el estado actual del proyecto que se considera listo y estable.

git push ↗️ – git pull ↙️

Push y Pull son dos operaciones que se utilizan para sincronizar cambios entre un repositorio local y un repositorio remoto.

git push

La operación push se utiliza para enviar los commits realizados de un repositorio local al repositorio remoto y actualiza el historial de versiones compartido.

git pull

La operación pull se utiliza para obtener y fusionar los cambios realizados en el repositorio remoto en tu repositorio local. Cuando otros colaboradores han realizado cambios en el repositorio remoto y deseas tener esos cambios actualizados en tu entorno de trabajo local, puedes usar el comando git pull. Esto recupera los nuevos commits del repositorio remoto y realiza automáticamente una fusión (merge).

En nuestro artículo de primeros pasos con Git, te enseñamos a trabajar con estos comandos.

URL

La URL es la dirección única que identifica la ubicación de un repositorio remoto en un servidor. La URL se utiliza para establecer una conexión entre el repositorio local y el repositorio remoto, lo que permite realizar operaciones como clone, push o pull.

La URL de un repositorio Git puede tener diferentes formatos, dependiendo del protocolo de comunicación utilizado y del proveedor de servicios de alojamiento de repositorios: HTTPS o SSH. Es importante destacar que la URL del repositorio remoto se utiliza para establecer la conexión inicial, y una vez que el repositorio local y remoto están vinculados, Git guarda esa información en su configuración interna, sin necesidad de volver a introducirla en cada commit.

HEAD

Git te permite ir navegando entre sus commits para ver las diferentes versiones que tiene el repositorio. Por tanto, HEAD es el puntero que indica la referencia al commit actual en una rama determinada, es decir, HEAD es el estado actual en el que se encuentra tu repositorio.

Normalmente HEAD apunta al commit más reciente en la rama actual. Cuando creas nuevos commits, la rama se mueve hacia adelante y HEAD se actualiza para apuntar al nuevo commit. En el caso de un merge, HEAD apuntaría al commit de fusión de ambas ramas. Si apuntamos a un commit concreto es lo que se conoce como “detached HEAD”.

Tags

Los tags son referencias estáticas y significativas a puntos específicos en el historial de commits. Se utilizan para marcar versiones importantes, hitos o lanzamientos en tu proyecto. Los tags se mantienen fijos en un commit específico y se utilizan principalmente para marcar versiones estables.

Conceptos de GitHub

Clone – Download – Fetch – Fork

clone, download, fetch y fork son tres conceptos que tienen cierta similitud, pero con diferentes usos. Veamos las diferencias.

git clone

El comando “clone” (clonar) se utiliza para crear una copia completa de un repositorio remoto en tu máquina local. Al clonar un repositorio, obtienes una copia de todos los commits, ramas, tags y archivos en el repositorio remoto. Además, también se configura la conexión entre tu repositorio local y el repositorio remoto, lo que te permite realizar operaciones como push y pull para sincronizar cambios.

Download

(Descargar): es la acción de obtener archivos específicos de un repositorio remoto sin clonar todo el repositorio. Al descargar archivos, solo obtienes esos archivos, y no tienes acceso al historial de commits.

git fetch

El comando “fetch” (recuperar) se utiliza para recuperar los cambios más recientes de un repositorio remoto en tu repositorio local, sin fusionarlos automáticamente. La operación de fetch obtiene los nuevos commits, ramas y tags del repositorio remoto y los almacena en tu repositorio local, pero no realiza ninguna fusión con tu rama actual. Esto te permite ver los cambios realizados por otros colaboradores y decidir cómo quieres incorporarlos en tu rama local.

Fork

“Fork” (Bifurcar) es una operación que permite crear una copia independiente de un repositorio remoto en tu cuenta de GitHub. El repositorio original del cual se realiza el fork permanece intacto y no se ve afectado por los cambios que realices en tu fork. Es común utilizar el fork para contribuir a proyectos de código abierto mediante pull-request.

En resumen, clone se refiere a crear una copia completa de un repositorio remoto en tu máquina local, download se refiere a obtener archivos específicos de un repositorio, fetch se utiliza para obtener los cambios más recientes del repositorio remoto en tu repositorio local sin fusionar automáticamente los cambios, y fork se utiliza para crear una copia independiente de un repositorio remoto en tu cuenta personal para contribuir y proponer cambios al repositorio original.

Pull Request

Un pull request es una función que permite a los desarrolladores proponer cambios en un repositorio y solicitar que esos cambios se fusionen con una rama específica, generalmente la rama principal del repositorio.

Cuando trabajas en un proyecto colaborativo en GitHub y deseas contribuir con tus propias modificaciones, en lugar de realizar directamente los cambios en la rama principal, puedes crear una rama separada en tu repositorio (una “rama de características” o “branch feature”) y hacer los cambios en esa rama. Luego, puedes enviar un pull request al repositorio original para que los propietarios o colaboradores del proyecto revisen tus cambios y los consideren para su incorporación. Esta es la metodología de trabajo más habitual y se conoce como Git Flow.

El pull request proporciona una forma de iniciar una discusión y revisión sobre los cambios propuestos. En el pull request puedes describir los cambios realizados, agregar comentarios o preguntas, y resaltar los aspectos importantes del código modificado.

Release

Una “release” se trata de una versión específica de un proyecto de software que se ha etiquetado y publicado en el repositorio. Una release representa un hito o una versión importante del proyecto que se considera estable y lista para su distribución.

Cuando se crea una release en GitHub, se selecciona un punto específico en la historia del repositorio, generalmente mediante la etiquetación de un commit, para marcar el estado del código en ese punto como una versión estable.

Al crear una release en GitHub, puedes proporcionar información adicional, como notas de lanzamiento, cambios destacados, enlaces a la documentación y activos descargables.

Contributor vs Collaborator

Contributor (contribuidor) es cualquier persona que ha realizado contribuciones al proyecto en forma de pull requests, comentarios en issues o participación en discusiones. Los contribuidores pueden ser usuarios externos al repositorio o incluso personas que solo han realizado una única contribución. Los contribuidores no tienen acceso directo al repositorio, lo que significa que no pueden realizar cambios directamente en el mismo ni realizar acciones administrativas.

Collaborator (colaborador) es un usuario que ha sido agregado como colaborador al repositorio por el propietario o los administradores del mismo. Los colaboradores tienen permisos más amplios y pueden realizar cambios directamente en el repositorio, como crear branches, realizar push de cambios, fusionar pull requests y administrar configuraciones del repositorio. Los colaboradores tienen un nivel más alto de autoridad y responsabilidad en comparación con los contribuidores

Es importante cuando creemos un repositorio en GitHub definir su estado de privacidad (público o privado) y los permisos de sus usuarios. Ten en cuenta que no todas las combinaciones forman parte de la capa gratuita de GitHub.

Issue

Una “issue” es un elemento de seguimiento utilizado para informar sobre problemas, sugerir mejoras, realizar preguntas o iniciar discusiones relacionadas con un proyecto en particular. Las issues son una forma de colaboración y comunicación dentro de un repositorio de GitHub. Al abrir una issue en GitHub, se crea un registro que contiene información relevante sobre el problema o la sugerencia.

Permiten a los contribuidores y a los usuarios del proyecto comunicarse de manera estructurada y mantener un historial de las discusiones y decisiones tomadas. También pueden estar vinculadas a pull requests, lo que facilita la asociación de cambios específicos con problemas o solicitudes de mejora.

Las issues se componen de un título, una descripción, etiquetas, asignación de la issue y comentarios.

FAQ

¿Git es aplicable únicamente en el desarrollo de software?

No, se puede aplicar para otro tipo de archivos que no sean dedicados para software.

¿Git es gratis? ¿Y GitHub?

Si, Git es open source y gratuito. En cuanto a GitHub, tienes una versión de usuario gratuita muy completa, y otra de pago para empresas. Aquí tienes los precios de GitHub.

¿Git vs GitHub? ¿Qué diferencia hay?

Git es el software de control de versiones, mientras que GitHub es la plataforma cloud con repositorios donde alojamos aplicaciones con control de versiones Git.

¿Es GitHub la única plataforma cloud compatible con Git?

No, pero si la más conocida. Bitbucket de Attlasian o GitLab son otras plataformas muy conocidas.

En definitiva, Git y GitHub son dos herramientas imprescindibles si desarrollas software. Te vas a topar con ellos en prácticamente cualquier equipo de desarrollo, por lo que te van a exigir tener las competencias básicas. Git no es sencillo de aprender, pero merece mucho la pena formarse en esta herramienta, ya que te va a salvar de grandes problemas, al disponer de una trazabilidad detallada del trabajo diario.

SIGUIENTE EPISODIO – Te recomendamos que continúes tu travesía por Git y GitHub con nuestro artículo de instalación y herramientas imprescindibles para utilizar Git y GitHub.