Git desde cero – parte 2

Siguiendo la serie “Git desde cero”, hoy me toca la parte 2. En esta oportunidad voy a explicar la parte teórica sobre las áreas de trabajo de Git, cómo añadir y confirmar cambios y la publicación de los mismos remotamente.

Teoría: Áreas de trabajo

Antes de empezar a explicar más detalles sobre los diferentes comandos de git disponibles, es vital aprender el concepto de las áreas de trabajo de Git como se muestra a continuación:

1. Directorio de trabajo (Working Directory): Este es el espacio en tu computadora donde trabajas con tus archivos. Aquí haces modificaciones en tus archivos y creas nuevas versiones.
2. Área de preparación (Staging Area o Index): Es una etapa intermedia donde seleccionas y preparas los cambios que deseas incluir en la próxima confirmación. Los archivos en esta área están listos para ser confirmados, pero aún no se han guardado en la base de datos de Git.
3. Repositorio (Repository): También llamado “base de datos” o “historial de versiones”, es donde Git almacena permanentemente todas las versiones confirmadas de tus archivos.

Estos son los conceptos más importantes para poder comprender Git desde cero. Si estos no los dominas, de seguro tendrás problemas en el futuro.

Explicación de la secuencia

Directorio de trabajo (working directory)

En la parte 1 de esta serie de artículos, expliqué cómo clonar un repositorio remoto a nuestro equipo local. Es así que, luego de tener el repositorio clonado en un directorio, podemos empezar a trabajar en él a través de adiciones, eliminaciones o modificaciones a archivos y/o directorios. Y todo esto que hacemos se lleva a cabo en lo que se conoce como “Directorio de trabajo”.

Por ejemplo, si nuestro repositorio es para código Terraform, es en este directorio de trabajo donde empezaremos a crear los archivos *.tf

Área de preparación (staging area)

Ahora que ya tenemos cierto avance de nuestro código Terraform y creemos que ya está listo para probarlo, es momento de realizar dos tareas:

1. Hacer una prueba rápida de funcionalidad de nuestro código (Ejm: terraform plan)
2. Si lo anterior nos convence, entonces agregamos esos archivos *.tf al área de preparación usando el comando git add

Repositorio (Repository)

La fase anterior de agregar archivos al área de preparación puede hacerse en múltiples paso y en diferentes tiempos.

Por ejemplo, primero puedo agregar 2 archivos con git add y seguir editando otros más. Luego, agrego 3 archivos adicionales con el mismo comando, pero también vuelvo a agregar uno de los primeros archivos que ya había agregado, debido a que le hice modificaciones recientes. Esta dinámica la puedo mantener por varios minutos u horas.

Pero, llega un punto en el que considero que mi código Terraform (formado por varios archivos y directorios) ya está “casi listo” para guardarlo en mi repositorio. Es aquí cuando uso el comando git commit, el cual mueve todos los archivos que estaban en mi área de preparación hacia mi repositorio (local).

El uso de git commit crea un snapshot o instantánea de nuestro repositorio. Es como una “foto” en el tiempo del repositorio y su contenido, de modo tal que con otros comandos podamos navegar en el tiempo para ver cómo lucía el repositorio según el snapshot consultado.

Práctica: Comandos git add, status, commit y push

Ahora que ya revisamos la teoría sobre las áreas de trabajo de Git, es momento de enseñarlo con ejemplos prácticos.

Crear código Terraform

Angel ya tiene listo su repositorio “infra-como-codigo”, así que se ubica dentro de él y crea dos archivos:

• main.tf
• outputs.tf

El archivo main.tf tiene un contenido como este:

module "mi_bucket_s3" {
  source  = "terraform-aws-modules/s3-bucket/aws"
  version = "3.15.1"

  # Nombre de bucket que debe ser único globalmente
  bucket = "este-es-un-bucket-cualquiera-00112234455"

  # No forzar la destruccion del bucket si no está vacío.
  force_destroy = false

  # Bloqueo de políticas y ACLs de acceso público, por ende el bucket es totalmente privado
  attach_public_policy    = true
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Mientras que el archivo outputs.tf luce así:

output "s3_bucket_id" {
  description = "Nombre del bucket"
  value       = module.mi_bucket_s3.s3_bucket_id
}

output "s3_bucket_arn" {
  description = "ARN del bucket"
  value       = module.mi_bucket_s3.s3_bucket_arn
}

output "s3_bucket_bucket_domain_name" {
  description = "Nombre DNS del bucket"
  value       = module.mi_bucket_s3.s3_bucket_bucket_domain_name
}

El contenido de los archivos no es lo que nos importa realmente, sino lo que viene en adelante.

Revisar el estado del repositorio

Estando ubicados dentro del repositorio ejecutamos el comando git status para ver cómo luce los cambios hechos:

Información resaltante a rescatar:

• Se usó el comando git status dentro del repositorio “infra-como-codigo”
• Git detectó 2 archivos no rastreados (Untracked files)
• Se muestra de color rojo los dos archivos recién creados y que no están siendo rastreados

Dado que los dos archivos nuevos no están siendo rastreados por Git, hay que agregarlos al área de preparación (staging).

Agregar archivos al área de preparación

Luego que revisamos el estado del repositorio, ahora podemos agregar ambos archivos con el comando git add:

Información resaltante de la imagen:

• Se usó git add con los archivos main.tf y outputs.tf
• Se consultó el estado del repositorio luego de agregar los archivos
• Se observa los mismos dos archivos pero ahora de color verde

Luego de agregar los archivos, ahora Git ya no los reporta como “Untracked files”, sino como “Changed to be commited”. Es decir, ahora ya los tiene rastreados, están en el área de preparación y están listos para ser confirmados (commit) en el repositorio.

Los archivos que ya fueron agregados al área de preparación se muestran de color verde.

Configurar nuestra identidad en Git

Antes de poder confirmar cambios (commits) se requiere que configuremos nuestra identidad como sigue:

git config --global user.name "Mi nombre y apellido"
git config --global user.email "[email protected]"

Confirmar cambios

Ahora es momento de confirmar los cambios en el repositorio a través de un commit con el comando git commit:

Entendamos lo que dice la imagen:

• Se usó el comando git commit con la opción -m para escribir entre comillas el mensaje informativo de la operación de confirmación (commit).
• Se consulta el estado y se nos informa que:
  • Estamos en la rama “main”
  • El estado de nuestra rama es tal que el repositorio local está 1 cambio (commit) por delante del repositorio remoto “origin/main”
  • Se nos sugiere que ejecutemos git push para enviar hacia el repositorio remoto los cambios locales (commits) que están pendientes de sincronizar desde nuestro repositorio local.

Publicar cambios

La parte final consiste en publicar los cambios hechos recientemente en el repositorio local hacia el repositorio remoto en GitHub.

La imagen nos confirma que se subió los cambios hacia github.com, en la cuenta “arengifoc” y el repositorio “infra-como-codigo.git”

Conclusión

En esta oportunidad ahondamos en la teoría de las áreas de trabajo y cómo se interactúa entre ellas con los comandos de Git.

En el siguiente artículo explicaremos la relación entre el repoitorio local y remoto, así comos comandos relacionados.