Descubre el poder de Git: Fundamentos - Parte 2

Descubre el poder de Git: Fundamentos - Parte 2

Luego de una introducción acerca de Git, ahora revisaremos los fundamentos de esta herramienta a través de una historia práctica para que comiences a utilizarla desde ya y apreciar su valor. La historia comienza así.

Había una vez un grupo de desarrolladores llamado Equipo Alfa que trabajaba en un ambicioso proyecto de software. A medida que el proyecto crecía, el equipo enfrentó desafíos para mantener el código organizado y coordinar las actualizaciones entre sus miembros.

Un día, uno de los miembros del equipo encontró un antiguo libro que hablaba de un lugar llamado Gitlandia. Según el libro, Gitlandia era un mundo mágico donde los equipos de desarrollo podían gestionar sus proyectos de una manera eficiente y estructurada utilizando una herramienta llamada Git.

Intrigados por la promesa de Gitlandia, el Equipo Alfa decidió aventurarse en este nuevo mundo y aprender a utilizar Git para transformar su proyecto de desarrollo. A lo largo de su viaje, descubrieron numerosos secretos y técnicas de Git, y en este relato, te contaremos su fascinante historia.

1. Comenzando el viaje - Conceptos básicos

Git es un sistema de control de versiones de software que se utiliza para realizar un seguimiento de los cambios en el código fuente y colaborar en proyectos de programación. Aquí hay algunos conceptos básicos para entender Git de manera sencilla:

  • Repository: Un repositorio de Git es un lugar donde se almacena el código fuente y su historial de cambios. Puede estar en una computadora local o en un servidor remoto.
  • Commit: Un commit es una instantánea del código fuente en un punto determinado en el tiempo. Cada commit tiene un mensaje que describe los cambios realizados.
  • Branch: Una rama es una línea de desarrollo independiente que se separa del flujo principal de trabajo. Las ramas se utilizan para desarrollar características nuevas sin afectar la rama principal.
  • Merge: La fusión es el proceso de combinar cambios de una rama a otra. Se utiliza cuando se ha completado una función o corrección de errores en una rama y se quiere integrar con la rama principal.
  • Conflict: Un conflicto se produce cuando dos ramas tienen cambios en el mismo archivo o línea. Git no puede fusionar automáticamente los cambios y necesita que el usuario resuelva manualmente el conflicto.
  • Clone: Clonar es el proceso de crear una copia de un repositorio remoto en la computadora local.
  • Push: Empujar es el proceso de enviar cambios locales a un repositorio remoto.
  • Pull: Tirar es el proceso de obtener los cambios más recientes de un repositorio remoto y fusionarlos con los cambios locales.

Estos son solo algunos de los conceptos básicos de Git, pero te dan una idea de cómo funciona y cómo se utiliza en el desarrollo de software. Puedes ver aún más detalle de los conceptos en la siguiente página.

2. Crear un mapa - Obtener un repositorio en Git

Para comenzar a utilizar Git, el equipo necesitaba crear un repositorio para su proyecto. Descubrieron que un repositorio es un lugar donde se almacenan los archivos y se registra el historial de cambios realizados en ellos. En otras palabras, un repositorio de Git es como un mapa que mantiene un registro detallado de todos los cambios realizados en un proyecto de software.

Primero, instalaron Git en sus computadoras y luego, en la terminal, navegaron hasta la carpeta del proyecto. Allí, ejecutaron el siguiente comando para inicializar un nuevo repositorio:

  • $ git init

Con este comando, crearon un repositorio Git en la carpeta del proyecto. Ahora estaban listos para agregar archivos y mantener un registro de los cambios realizados.

💡
Nota: Un repositorio de Git también puede estar vinculado a un repositorio remoto, como GitHub, Gitlab, etc., que permite compartir y colaborar en el código con otros desarrolladores. Los repositorios de Git son fundamentales para el control de versiones y la gestión eficiente de proyectos de software.


3. Registrar las aventuras - Escribir cambios en el repositorio

El siguiente paso en su viaje era registrar los cambios en el repositorio. El equipo aprendió que Git rastrea los cambios en los archivos mediante commits, que son instantáneas del proyecto en un momento específico. Cada uno de los commits es como una página en el diario de su proyecto, registrando cada cambio realizado.

Para registrar un cambio, primero debían agregar los archivos modificados al área de preparación staging area utilizando el comando:

  • $ git add <archivo>


Una vez que todos los archivos estaban en el área de preparación, el equipo utilizó el siguiente comando para crear un nuevo commit con un mensaje descriptivo de los cambios realizados:

  • $ git commit -m "Mensaje descriptivo"
💡
Nota: No olvides que, al crear tus commits, estos deben ser atómicos, lo que significa que cada commit debe representar un cambio coherente y completo en el código. Esto ayuda a mantener la historia de cambios del proyecto clara y fácil de entender, al tiempo que facilita el seguimiento de los errores en el código. Un buen criterio para realizar commits atómicos es que cada uno contenga los cambios necesarios para resolver una tarea específica.

4. Leer las crónicas - Ver el historial de commits

El equipo Alfa quería revisar su historial de commits para tener una visión general de los cambios realizados en el proyecto. Utilizaron el comando:

  • $ git log

Este comando les mostró una lista de todos los commits realizados hasta el momento, incluyendo información como el autor, la fecha y el mensaje del commit. A medida que revisaban el historial de commits, el Equipo Alfa pudo ver cómo su proyecto había evolucionado con el tiempo y cómo cada miembro del equipo había contribuido con su desarrollo.

💡
Nota: Existen herramientas visuales que pueden ayudarte a leer los commits en Git de manera más fácil y eficiente, como GitKraken, SourceTree o GitHub Desktop. Estas herramientas proporcionan una interfaz visual para los commits, lo que puede facilitar su lectura y comprensión.

5. Retroceder en el tiempo - Deshacer cambios

En cierto momento de su aventura, una de las integrantes del equipo, Ana, cometió un error en su código y quería deshacer su último commit. Buscando en el libro de Gitlandia, descubrió que podían utilizar el comando git revert para deshacer los cambios realizados en el último commit y crear uno nuevo que deshiciera esos cambios:

  • $ git revert HEAD


Además, si quería modificar el último commit, el Equipo Alfa aprendió que podía usar el comando git commit --amend. Esto le permitía agregar nuevos cambios al último commit o cambiar su mensaje, permitiendo corregir errores sin crear un historial confuso.

💡
Nota: Es importante comprender el efecto de revertir un commit. Al hacerlo, se crea un nuevo commit que revierte los cambios realizados al anterior. Este nuevo commit no elimina el anterior, sino que lo mantiene en el historial del proyecto y crea una bifurcación en la línea de tiempo. Es importante tener en cuenta que, si se ha compartido el commit original con otros miembros del equipo, revertirlo puede afectar su trabajo y posiblemente genere conflictos.

6. Trabajar en equipo - Repositorios Remotos

El Equipo Alfa necesitaba colaborar y compartir su trabajo en un repositorio remoto, como si fuera un centro de reunión en Gitlandia. Decidieron utilizar Gitlab, una popular plataforma para alojar repositorios Git. Crearon un nuevo repositorio en Gitlab y luego lo vincularon a su repositorio local utilizando el siguiente comando:

  • $ git remote add origin <URL del repositorio remoto>

Para enviar sus cambios al repositorio remoto, utilizaron el comando git push:

  • $ git push origin master

Esto subió los cambios al repositorio remoto en Gitlab, permitiendo que todo el equipo viera y colaborara en el código desde cualquier lugar. Si otro miembro del equipo había realizado cambios y los había subido al repositorio remoto, podían obtener esos cambios usando git pull:

  • $ git pull origin master

💡
Nota: Recuerda mantener tu repositorio local actualizado con el remoto para evitar conflictos y asegurarse de que todos los miembros del equipo trabajen con la última versión del código. Esto se puede hacer utilizando el comando git fetch para traer los cambios del repositorio remoto a tu repositorio local, y luego utilizar git merge para fusionar los cambios en tu rama local.

Por otro lado, tampoco olvides utilizar ramas remotas para colaborar, una práctica recomendada para trabajar de manera eficiente y colaborativa en un proyecto. Las ramas remotas permiten a los miembros del equipo trabajar en diferentes aspectos del proyecto de forma paralela, sin interferir con el trabajo de los demás. Al crear una rama remota, puedes trabajar en ella y luego subir tus cambios al repositorio remoto. Los demás miembros del equipo pueden entonces fusionar tus cambios en su propia rama remota, y viceversa.

7. Marcar hitos - Etiquetas

En su viaje por Gitlandia, el Equipo Alfa quería celebrar y mantener un registro de las versiones importantes de su proyecto, como las versiones de lanzamiento. Para hacer esto, utilizaron etiquetas (tags) en Git. Crearon una etiqueta en un commit específico usando el siguiente comando:

  • $ git tag -a v1.0 -m "Versión 1.0"

Las etiquetas les permitieron marcar hitos importantes en el historial de su proyecto, facilitando el acceso a puntos clave en cualquier momento y mostrando el progreso de su aventura en Gitlandia.

💡
Nota: La forma más común de etiquetar en Git es para marcar versiones de lanzamiento de un proyecto. En este caso, se recomienda utilizar el siguiente formato para el tag: vX.Y.Z, donde X, Y y Z representan la versión mayor, menor y de parche, respectivamente. Por ejemplo, si la versión de lanzamiento es la 1.2.3, el tag sería "v1.2.3".

8. Crear atajos mágicos - Alias

A medida que el equipo se familiarizaba con Git, se dio cuenta de que algunos comandos eran bastante largos y difíciles de recordar. Sus miembros decidieron utilizar alias para crear atajos a los comandos que utilizaban con frecuencia, como si fueran hechizos mágicos que facilitaban su trabajo en Gitlandia.

Por ejemplo, crearon un alias llamado co para el comando git checkout mediante el siguiente comando:

  • $ git config --global alias.co checkout

Ahora, en lugar de escribir git checkout, simplemente podían escribir git co. Esto les permitió aumentar su eficiencia y trabajar de manera más fluida en Gitlandia.

💡
Nota: Algunos de los aspectos a considerar cuando utilices alias son:

- Elije un nombre claro y fácil de recordar. Es importante elegir un nombre con estas características, ya que te facilitará su uso en el futuro y reducirá la posibilidad de errores tipográficos.

- El nombre del alias debe ser significativo y representar el comando que estás abreviando. Además, debes mantener una coherencia en la forma en que creas tus alias.

- Utiliza una convención de nomenclatura consistente, como un prefijo común para todos tus alias, para que sea más fácil identificarlos en el futuro.

- Verifica la disponibilidad, es decir, que el nombre de tu alias no esté ya en uso por otro comando en Git. Si el nombre que has elegido ya está siendo utilizado por otro comando, podría causar errores o confusiones.

9. El final de un gran viaje - Resumen

Después de muchas aventuras y desafíos superados en Gitlandia, el Equipo Alfa dominó el arte de utilizar Git para gestionar su proyecto de desarrollo, convirtiéndose en un referente en su campo. Su éxito fue atribuido en gran parte a su adopción de Git como herramienta clave en su flujo de trabajo y sus habilidades les permitieron mantener su código organizado, colaborar de manera eficiente y llevar su proyecto al éxito.

A través de esta narración, aprendimos junto al Equipo Alfa sobre los fundamentos de Git, cómo obtener un repositorio, registrar cambios, ver el historial de commits, deshacer acciones, trabajar con repositorios remotos, etiquetar versiones importantes y crear alias para facilitar el uso de Git.

Espero que te haya gustado esta historia. Nos vemos en el blog…o en Gitlandia, si gustas.

💡
Las opiniones y comentarios emitidos en este artículo son propiedad única de su autor y no necesariamente representan el punto de vista de Listopro.

Listopro Community da la bienvenida a todas las razas, etnias, nacionalidades, credos, géneros, orientaciones, puntos de vista e ideologías, siempre y cuando promuevan la diversidad, la equidad, la inclusión y el crecimiento profesional de los profesionales en tecnología.