Gestión de Versionados con Git y GitHub

Reseña Histórica

Los primeros pasos en el desarrollo de control de versionados Git estuvo en manos del ingeniero y arquitecto finés **Linus Benedict Torvalds, más conocido como Linus Torvalds. En abril de 2005 la licencia libre BitKeeper, una vieja herramienta de control de versionados creada por la empresa Bit Mover Inc., con sede en Los Gatos, California en los EEUU, propietario de la gestión de control de fuenstes SCM utilizado para el kernel del Sistema Operativo Linux desde el año 2002 fuera revocado para el Sistema Operativo Linux. El titular de estos derechos, [Larry McVoy](https://en.wikipedia.org/wiki/Larry_McVoy) dijo en su momento y lo afirmó categóricamente que [Andrew Tridgell](https://en.wikipedia.org/wiki/Andrew_Tridgell)** era el artífice de la creación de SourcePuller mediante el uso de la ingeniería inversa de los protocolos de BitKeeper. Lo cual y como era de imaginarse, esto creó un tremendo cisma en la comunidad de desarrollo del código abierto. No solo Linux se vió afectado sino también otras comunidades lo cual, en muchos casos, terminaron por decantarse por desarrollos propietarios, tal es el caso de Mercurial, que es otro sistema de control de versionados.

¿Cuál era la intención de Linus Torvalds?

Linus Torvalds perseguía el ambicioso proyecto de poder contar con un sistema distribuido que hiciese uso de la herramienta BitKeeper puesto que el resto de los tipos de sistemas distribuidos de la época no eran demasiados fiables. Es más, Linus Torvalds afirmó que en 30 segundos un sistema de gestión de controles podría necesitar para poder aplicar eficazmente tanto parches como actualizaciones, todos los metadatos necesarios asociados. Si bien, remarcó que esto no se adaptaría a las necesidades del desarrollo del kernel del Sistema Operativo Linux, donde la sincronización con otros sistemas de mantenimiento podrían requerir de al menos unas 250 acciones de esta naturaleza a la vez. Por tanto, creyó conveniente crear un diseño crítico, especificando que dicha aplicación de parches y actualizaciones no debieran tardar más de 3 segundos. Estos se centrarían en los siguientes puntos de interés.

• En los CVS (Control Version Systems) o Sistemas de Control de Versiones, por ejemplo, lo que no se debería hacer por ejemplo en caso de que surja una duda o se tome la decisión opuesta.
• Admitir un flujo de trabajo totalmente distribuido parecido a lo que BitKeeper hacía.
• Incluir las salvaguardas apropiadas contra los potenciales problemas de corrupción de datos u otros casos de errores e incluso, aquellas acciones que puedan jugar maliciosamente en el sistema o, por supuesto, en caso de que se produzcan diversos tipos de accidentes.

Lanzamiento Oficial de Git

El desarrollo de Git se puede ubicar exactamente el 3 de abril de 2005. El 6 de abril es anunciado por el mismo Linus Torvalds y de inmediato se convirtió en un mecanismo de autohospedado la día siguiente. El día 18 de ese mes se logró producir la primera fusión múltiple de las ramas. Pasados los días, para el 29 del corriente mes, el naciente Git fue evaluado, se le añadieron algunos parches de corrección en el árbol del kernel de Linux. El día 16 de juinio, Git procede hacer el lanzamiento del kernel 2.6.12. Finalmente, el 26 de junio de 2005, Torvalds entrega el mantenimiento a **Junio Hamano**, un reconocido colaborador del proyecto.

Estructuras de Datos

Partiendo desde el inicio, Git ha desarrollado un conjunto completo de características esperadas para una tradicional gestión de SCM (Source Code Management) o Gestión de Código de Origen, particularmente sobre las características específicas que se crean, según sean estas necesarias y luego, terminan siendo perfeccionadas a través del tiempo.

Básicamente, Git tiene dos estructuras de datos; un índice mutable, que suele ser una caché, también llamado como stage, encargada de almacenar la información sobre el directorio o carpeta de trabajo y, en la próxima revisión de confirmación, una base de datos de objetos cuya función es la de almacenar dichos objetos.

Por otra parte, el banco de datos contienen los siguientes elementos activos:

• blob — Los blobs no tienen un tipo de nombre propio, marcas de tiempo ni cualquier otro tipo de metadatos, puesto que internamente un blob se basa en un tipo de Hash interno. Para Git un blob se trata de una versión de archivo que contiene los típicos datos del archivo.
• tree (árbol) — El árbol básicamente es homólogo a una carpeta o directorio. Puede contener una lista de nombres de archivos, con sus bit de tipo y una referencia a un blob u objeto de árbol que representa dicho contenido del archivo, el tipo de enlace simbólico o directorio. Con el uso de un único Hash para el árbol raíz es suficiente. Se los utiliza para las confirmaciones con el objeto de precisar el estado exacto de las estructuras del árbol completas de cualquier número de subdirectorios y archivos.
• commit (Confirmación) — Tiene como objeto vincular los objetos árbol en el historial. Este contiene el nombre de un objeto de árbol, una marca de tiempo, un mensaje de registro y por supuesto, los nombres de ninguno o más objetos de confirmación (commit) principales.
• tag (Etiqueta) — Se trata básicamente de una especie de contenedor que contiene una referencia hacia otro objeto y, a su vez, puede contener metadatos adicionales relacionados con ese objeto. Se lo utiliza para el almacenamiento de la firma digital de un objeto de confirmación (commit) correspondiente por sobre un tipo de versionado específico de los datos que es rastreado en Git.
• packfile — Este se encarga de recopilar varios otros objetos en un paquete comprimido cuyo mediante la librería **zlib** con el objeto de lograr mayor espaciado para su capacidad y, por su puesto, facilitar el transporte a través de los protocoles de la red.

En consecuencia, Git identifica cada objeto con un hash SHA-1 de su contenido y lo almacena en un directorio basado en los primeros caracteres del Hash. Cada revisión de un archivo se guarda como un blob único y las relaciones entre blobs se determinan mediante árboles y confirmaciones. Para optimizar el espacio, Git usa la compresión zlib y combina objetos en paquetes con compresión delta. Además, almacena referencias como ramas, etiquetas y HEAD, donde dichas ramas, avanzan con cada confirmación, HEAD señala la referencia actual y las etiquetas marcan hitos en el historial.

• Heads branches (Cabezas de las Ramas) — Son las referencias con nombres que van avanzando de modo automático hacia la nueva confirmación (commit) cuando se procede a realizar una confirmación sobre ellas.
• HEAD (Cabeza) — Se trata de una cabecera reservada que se comparará con el árbol de trabajo para crear una confirmación (commit).
• Tags (Etiquetas) — Tiene un aspecto parecido a las referencia de rama. Sin embargo, estas están asociadas a una confirmación (commit) específica. Su finalidad de uso es para etiquetar (tags) los puntos más importantes del historial.

Estrategia para las Ramas (Branching)

El uso de una estrategia de branching organizada permite gestionar el código de manera eficiente y evitar conflictos innecesarios. Existen varias estrategias reconocidas para manejar ramas en Git. Por tanto, la elección de una u otra dependerá del flujo de trabajo y del tamaño del equipo.

Git Flow (Flujo de Git)

Git Flow se trata de una estrategia recomendada para empresas cuyos ciclos de desarrollo suelen ser mucho más largos y también, en casos donde los proyectos requieren una mayor estabilidad en producción. La estrategia consiste básicamente en el uso de diferentes ramas con diversos propósitos para fines determinados.

A continuación, paso a describir dichas estrategias. Estas suelen ser las más normalizadas aunque en otras ocasiones podrían haber variantes. En este caso enumero las más estandarizadas.

• main es la rama donde siempre reside la versión estable del código en producción. No se realizan cambios directos en esta rama.
• develop es la rama principal de desarrollo, donde se integran las nuevas funcionalidades antes de que pasen a producción.
• *feature/ son ramas derivadas de develop y se utilizan para desarrollar nuevas funcionalidades. Cuando una funcionalidad está terminada, la rama se fusiona nuevamente en develop.
• *release/** son ramas creadas a partir de develop cuando se prepara una nueva versión para producción. Aquí se realizan pruebas y correcciones menores antes de ser fusionada en main.
• *hotfix/** son ramas que se crean directamente desde main para corregir errores críticos en producción. Una vez corregido el problema, se fusiona tanto en main como en develop.

git checkout develop
git checkout -b feature/nueva-funcionalidad
# Se desarrollan los cambios
git commit -m "feat: agregar nueva funcionalidad"
git checkout develop
git merge feature/nueva-funcionalidad
git branch -d feature/nueva-funcionalidad
git push origin develop 

--- Script 1 ---

En el siguiente script 1 podemos observar todos los comandos utilizados para establecer un proceso automatizado de control de versionados mediante la estrategia Git Flow. Dicho de otro modo, se trata del flujo o rutina diaria de trabajo de Git Flow.

Estándar Utilizado por ASI (Argentina)

El instituto argentino de normalización de sistemas informáticos, más conocido como **ASI (Agencia de Sistemas de Información), para el uso de los repositorios, recurren al uso de un estándar propio para la gestión de los ambientes de los versionados en los repositorios. El manual está disponible en el espacio del sitio Web de la agencia y donde se específican las normalizaciones para el correcto versionado de los productos de software. [Ver aquí](https://buenosaires.gob.ar/sites/default/files/2025-03/ES0901%20-%20Estandar%20de%20Desarrollo%20ASI%20V4.9.docx.pdf)**.

En el documento Paper lanzando recientemente por la agencia en la fecha marzo de 2025, hace énfasis en el manejo del flujo de sus ramas como se especifica a continuación. Nota: Téngase en cuenta que este paper se actualiza regularmente. En caso de no poder acceder a dicho documento, visite directamente el sitio Web de la agencia oficial ASI **aquí**.

Proceso de Gestión de Cambios de Software — ASI

El principal objetivo en relación a las aplicaciones de software es la sustentabilidad. Atento a ello, definimos sustentabilidad en términos de:

Calidad — La calidad de las aplicaciones de software es un factor directamente asociado a los costos de mantenimiento, disrupción de servicio, exposición negativa hacia el Ciudadano, etc. El proceso de gestión de cambios es permanentemente ajustado para incorporar todos los controles que sean necesarios a fin de garantizar la calidad total de las aplicaciones instaladas.

Desempeño — El Gobierno de la Ciudad considera la tecnología y el software como pilares para su gestión efectiva. Es por ello que, las aplicaciones de software deben estar a la altura de tales exigencias en términos de tiempos de respuesta, escalabilidad, performance, y rendimiento general. El proceso de gestión de cambios incluye los pasos necesarios para certificar el adecuado desempeño de las aplicaciones.

Seguridad — En un contexto donde los ataques y la búsqueda de vulnerabilidades para explotar son parte de la rutina, las aplicaciones deben implementar mecanismos cada vez mejores y más inteligentes con el objeto de prevenir y mitigar los daños que todo tipo de intrusión externa y/o interna pudieran ocasionar.

El proceso de gestión de cambios refleja la importancia de la sustentabilidad de las aplicaciones, incluyendo actividades específicas para controlar y asegurar cada uno de los aspectos mencionados.

Figura 1 — Procesos de Gestión de Cambios.

Descripción de los Ambientes (Ramas)

DEV — Toda iniciativa de software –proyecto, evolución, etc.- debe contar con un ambiente de desarrollo controlado por GCABA como punto inicial del proceso, permitiendo al equipo de Desarrollo implementar la solución con los controles/Verificaciones correspondientes. El ambiente DEV posee la misma infraestructura que el ambiente productivo, con los recursos acorde a un ambiente de Test.

Independientemente de la plataforma utilizada por el Desarrollador para generar su producto, todas las aplicaciones deben desempeñarse correctamente en el entorno DEV provisto a tal efecto.

Integración Continua

La actualización en el repositorio inicia el proceso de integración continua coordinado con GCABA, el mismo se compone de:

• Análisis de calidad de Código
• Análisis de detección de vulnerabilidades de seguridad en el código.
• Ejecución de Test unitarios, los cuales deberán cumplir con la premisa de ser totalmente independientes
• Generación del paquete a implementar
• Implementación en Ambiente DEV
• Ejecución de detección de vulnerabilidades de seguridad en la aplicación implementada.
• Ejecución de “smoke tests”
• Ejecución de tests de integraciones básicas.

Los resultados de todos los pasos mencionados deberán reflejarse en la herramienta de Gestión seleccionada para tal fin.

QA — Cuando en DEV se encuentre una versión que haya superado los controles exitosamente, es candidata a implementar en producción y el proceso permite avanzar al ambiente de QA administrado/controlado por recursos del GCABA, donde se verifican automáticamente los mismos controles que en DEV y se suman nuevos como:

• Pruebas exploratorias
• Pruebas de requisitos No Funcionales(Performance, Stress, Escalabilidad, Disponibilidad)
• Pruebas de integración y servicios exhaustivas.
• Assessment de Seguridad Complementario verificando las buenas prácticas(Ver Estándar de Seguridad)

HML — En los casos que los controles en Calidad y Seguridad sean satisfactorios la versión, estará en condiciones de avanzar al ambiente de Homologación/UAT donde los usuarios podrán realizar las tareas de control y verificación respecto de los cambios para aprobar o rechazar. Con la conformidad del usuario responsable, nos encontramos en condiciones para elevar el cambio a Producción.

PRD — Las aplicaciones productivas contarán con un monitoreo de Infraestructura y chequeos adicionales del comportamiento on-line, contando con controles proactivos y alarmas del funcionamiento.

Estrategia Git Flow Aplicada a GitHub

En el caso de disponer del uso de GitHub, que suele ser el caso más común y utilizado en el mundo del desarrollo del software, este flujo resulta ser más simple y adecuado para ciclos de desarrollo más rápidos, tipos de proyectos con integración y despliegue continuo CI/CD. Los siguientes pasos describen las rutinas aplicadas a este tipo de estrategias.

1. main es la única rama permanente y refleja el estado de producción.
2. Cada nueva funcionalidad o corrección se realiza en una nueva rama (feature/nueva-funcionalidad o fix/error-crítico).
3. Se crean Pull Requests para fusionar los cambios en main, asegurando que sean revisados por otros desarrolladores antes de ser aceptados.
4. Una vez aprobada la Pull Request, los cambios se integran en main y se despliegan automáticamente.

git checkout -b fix/error-en-login
# Se corrige el error
git commit -m "fix(auth): corregir error en autenticación"
git push origin fix/error-en-login
# Se abre un Pull Request en GitHub 

--- Script 2 ---

En el script 2 podemos observar el despliegue que se suele realizar en las estrategias enfocadas para el uso de GitHub.

Convenciones para las Confirmaciones (commit)

Para mantener un historial de cambios claro y útil, es importante seguir convenciones en los mensajes de las confirmaciones commits. El estándar de CC (Conventional Commits) o Convenciones de Confirmaciones, define una estructura para los mensajes. Ver script 3.

<tipo>(<área opcional>): <mensaje breve>

[Descripción detallada opcional] 

--- Script 3 ---

A continuación, presento una serie de tipos de confirmaciones commits más utilizados para la estretegia de confirmaciones.

• feat (logro): Indica la introducción de una nueva funcionalidad.

git commit -m "feat(api): agregar endpoint para obtener datos del usuario"

• fix (Correción): Se usa para correcciones de errores.

git commit -m "fix(ui): corregir problema con el tamaño del modal"

• docs (documentaciones): Se utiliza para cambios en documentación.

git commit -m "docs(readme): actualizar instrucciones de instalación"

• chore (trabajo): Se usa para cambios menores que no afectan la funcionalidad.

git commit -m "chore: actualizar dependencias"

• test (prueba): Se usa para agregar o modificar pruebas.

git commit -m "test(auth): agregar pruebas unitarias para autenticación"

Versionado Semático

A medida que el desarrollo de un software va sufriendo cambios que parten, desde el nivel de correcciones hasta de nuevos lanzamientos, además de la debida estrategia de uso de los repositorios mediante Git, también resulta necesario gestionar los versionados de los lanzamientos o publicaciones de nuestro software.

El **versionado semántico** se trata de una estrategia organizativa de versionados del software. Este versionado es representado normalmente mediante tres guarismos aunque otras empresas pueden utilizar hasta cuatro guarismos para la gestión de sus propios versionados. En efecto, este uso exclusivo suele aplicarse en productos de software que generan lanzamientos y actualizaciones muy regularmente. Podemos ver como ejemplo, en la gran mayoría de los lanzamientos de actualizaciones, las compañias que desarrollan software como los antivirus, que requieren de una actualización permanente de su software, debido a la dinámica progresiva de la delincuencia informática.

El modelo representativo para los versionados del software se muestran a continuación en el siguiente esquema.

Figura 2 — Gestión de versionados haciendo uso de tres guarismos.

El versionado semántico, también conocido como (SemVer), entre otras cosas, permite definir las versiones del software de manera estructurada. El formato estándar es el que podemos observar en la figura 2. Cada guarismo tiene una finalidad y estas se describen a continuación:

• MAJOR (Mayor) se incrementa cuando hay cambios incompatibles.
• MINOR (Menor) se incrementa cuando se agregan funcionalidades de forma compatible.
• PATCH (Fixes o parches) se incrementa cuando se hacen correcciones de errores o cambios internos sin afectar la API.

Estrategia de Versionado Semántico en GitHub

git tag -a v2.1.0 -m "Lanzamiento de la versión 2.1.0"
git push origin v2.1.0 

--- Script 4 ---

En el siguiente script 4 podemos observar un simple y sencillo ejemplo de uso de versionados semánticos en GitHub. Puedes observa cómo se van añadiendo los acumulativos del software en nuestro repositorio.

Revisión y Seguimiento del Código

Resulta fundamental mantener la calidad del código y reducir errores. Por tanto, resulta importante la implementación de revisiones antes de fusionar los cambios en la rama main. GitHub permite hacer esto mediante Pull Requests.

Normalmente, cuando un desarrollador termina de realizar un cambio en el código fuente del software, este pasa a crear un Pull Request en GitHub, describiendo así todos los cambios realizados y, por otro lado, solicitando las revisiones de otros miembros del equipo. Durante la revisió se suelen frecuentar los siguientes controles:

• Se analizan los cambios para verificar que se cumplen con las normas de codificación.
• Se ejecutan pruebas automatizadas para evitar introducir errores.
• Se hacen comentarios o sugerencias antes de aprobar la fusión.

git checkout -b feature/nueva-funcionalidad
git push origin feature/nueva-funcionalidad
# Luego, abrir Pull Request en GitHub para revisión

--- Script 5 ---

En el script 5 podemos ver todas las actividades que un desarrollador suele hacer para hacer los Pull Requests.

Conclusión

Implementar un flujo de trabajo estructurado con Git y GitHub mejora la organización del código, facilita la colaboración en equipo y permite garantizar la estabilidad del software. Usar estrategias de branching como Git Flow o GitHub Flow, mantener convenciones en los commits, aplicar versionado semántico, realizar revisiones de código y automatizar pruebas con CI/CD son prácticas esenciales para el desarrollo eficiente y profesional de software en empresas.

¡Hasta pronto!

Ariel.