Git series I – Estructura y conceptos mínimos

Git introduce una serie de conceptos que realmente son heredados de otros software de control de versiones. No obstante, abarcaremos todos ellos desde una perspectiva de Git en lugar de generalizarlos totalmente.

Estructura general de un repositorio

Podemos comparar toda la estructura de archivos y cambios de Git como si fuera el siguiente diagrama de conjuntos:

Realmente, la relación entre elementos es más complejo como para representarlo a través de conjuntos. Igualmente, es posible decir que un repositorio puede representar la historia de un proyecto, donde cada commit es un cambio en el proyecto.

Commit

Es la unidad de cambio mínima y se puede describir como un punto en la historia. Es importante destacar que un commit resume los cambios como si fueran parches a un archivo y no contiene los archivos en sí. Esta técnica permite reducir el tamaño de los repos y optimizar la sincronización.

Puedes consultar más información en este link.

Existen diversos conceptos alrededor de commit, como por ejemplo:

• HEAD: es la referencia al último commit de un branch.
• BASE: es la referencia al puntero que da origen al branch.

Branches

Los branches o ramas son conjuntos secuenciales de commits. Igualmente, puede que un branch de origen a otros, como si fuera un árbol de cambios o un grafo específicamente.

Los branches pueden contener cambios importantes en el proyecto, tales como nuevas funcionalidades, corrección de bugs o contienen las versiones de evaluación y de producción de una applicación. Usualmente, dividimos los branches por su naturaleza:

• master: contiene la versión en producción de la aplicación. El código de este branch debe compilar siempre.
• development: contiene la versión de pruebas o pre-producción. El código de este branch debe compilar siempre.
• feature/<cambio>: contiene una nueva funcionalidad para la aplicación. Lo ideal es que el código siempre compile o funcione.
• hotfix/<cambio>: contiene un fix ante un bug en producción. No debe romper el código.

Remote

Resume la conexión o el enlace hacia un repositorio local o remoto. Usualmente, el local es el repositorio en la computadora (in-site) y un remoto es un repositorio alojado en otra computadora. También, es posible escuchar sobre upstream que es un repositorio de referencia.

Fork

Es una réplica del repositorio que aún se encuentra comunicada al repositorio principal. Sirve para trabajar en distintos proyectos derivados de una base en común (repositorio principal).

Usualmente, en Microsoft, se tomaba una base para Windows y se trabajaba en la versión corporativa y la versión comercial en forks.

Visualizar el grafo de Git

La visualización del grafo de nuestro repositorio nos permite ver de una forma intuitiva y amigable la composición de este. La idea es determinar que el flujo de desarrollo esté ordenado y se conozcan los branches, sus bases y sus heads. También, nos permite conocer los commits de un branch.

Esta herramienta es súper útil para nosotros, ya que seguimos un Gitflow (que más tarde explicaremos con detalle) y ocupamos garantizar que se respete.

Desde Gitlab

Para visualizar el grafo desde Gitlab, podemos ir en algún repositorio a:

Sidebar izquierdo -> Repository -> Graph.

Esto va a desplegar el grafo de nuestro repositorio, que luce algo como:

Puedes visualizar este ejemplo en mi NSC Image Converter.

Las líneas verticales denotan branches, mientras que los puntos son commits. Existen también las etiquetas (en gris) que apuntan a ciertos commits, que denotan el nombre del branch. Se renderiza de esta manera ya que apuntan al HEAD del branch.

Para efectos ilustrativos:

• El rojo (o derecho): denota el branch de master.
• El verde (o el del medio): denota el branch de development. Note que el development se une al master cuando ya la versión de pruebas se ha estabilizado.
• Los fucsia (o izquierdos): denotan feature branches. Cuando un feature se ha terminado, se integra dentro de development. En este caso, hay dos feature banches.

También, note que no hay commits directos en el master o en development, solo commits que unen branches (estos commits también se conocen como merge commits). Esto es una característica del Gitflow que usamos y detallaremos adelante.

Desde la consola

Los comandos de consola de Git ofrecen una gama aún más amplia comparado a muchas GUI existentes. Se pueden hacer una serie compleja de acciones desde consola que, desde un GUI, puede ser muy complicado. Algunas de estas acciones son:

• Rebasing
• Visualización del grafo
• Cherry picking
• Resetting

Para visualizar el grafo, podemos usar el siguiente comando:

git log --graph

El resultado de nuestra consola es:

El cual es bastante similar al grafo ofrecido por Gitlab, aunque menos amigable. Sin embargo, tener la capacidad de desplegar el grafo en nuestra consola nos permite efectuar reparaciones en el repo local previo a subir los cambios al remoto y ocasionar desastres.

Conclusión

En este post se abordaron conceptos mínimos y la visualización de la estructura de un repositorio. Detallaremos cómo se crean los branches y commits en nuestra próxima entrada.

Si tienes comentarios o preguntas, consúltanos escribiendo en la caja de comentarios.