Arquitectura del Flujo de Trabajo

Git opera bajo una estructura de estados que permite gestionar cambios de forma aislada antes de integrarlos al historial definitivo. Comprender la transición entre el directorio de trabajo, el área de preparación (staging) y el repositorio es fundamental para cualquier desarrollador.

Ciclo de Vida de un Cambio

• Directorio de Trabajo: Archivos modificados localmente.
• Área de Preparación (Index): Instantánea de los cambios listos para el siguiente commit.
• Repositorio Local: Historial de versiones confirmadas en la máquina del usuario.
• Repositorio Remoto: Servidor central (GitHub, GitLab) donde se sincroniza el equipo.

# Secuencia típica de sincronización
Trabajo -> git add -> Staging -> git commit -> Local -> git push -> Remoto
Remoto -> git fetch -> Local -> git merge -> Trabajo (o git pull para ambos)

Configuración y Preparación del Entorno

Antes de iniciar cualquier proyecto, es imperativo establecer la identidad del autor para asegurar la trazabilidad de los cambios.

# Identidad global para todos los proyectos
git config --global user.name "Usuario Profesional"
git config --global user.email "dev@ejemplo.com"

# Verificación de parámetros establecidos
git config --list

Autenticación Mediante Llaves SSH

Para evitar el ingreso constante de credenciales, se recomienda el uso de llaves RSA o Ed25519.

# Generación de par de llaves criptográficas
ssh-keygen -t ed25519 -C "comentario_personal"

# Visualización de la llave pública para vincular en GitHub
cat ~/.ssh/id_ed25519.pub

Operaciones Fundamentales

La gestión de un repositorio comienza con su inicialización o la réplica de uno existente.

Inicialización y Clonación

# Crear un repositorio nuevo en la carpeta actual
git init 

# Clonar un proyecto específico en un directorio personalizado
git clone https://github.com/empresa/proyecto-core.git mi-directorio-local

Gestión de Cambios

El comando git add no solo añade archivos, sino que permite seleccionar granos finos de cambios.

# Añadir archivos por extensión
git add *.ts

# Añadir todos los cambios detectados
git add -A

# Confirmar cambios con un mensaje descriptivo siguiendo convenciones (Conventional Commits)
git commit -m "feat: implementar validación de esquemas en el formulario"

Estrategias de Ramificación (Bracnhing)

Las ramas permiten el desarrollo paralelo de funcionalidades sin afectar la estabilidad de la línea principal (main/master).

# Creación y salto inmediato a una nueva rama de funcionalidad
git checkout -b feature/autenticacion-oauth

# Listar ramas locales y remotas
git branch -a

# Eliminar una rama integrada de forma segura
git branch -d feature/rama-obsoleta

Integración: Merge vs. Rebase

Existen dos filosofías principales para integrar cambios de una rama a otra:

• Merge: Crea un nuevo commit de unión, preservando el historial real de ambas ramas.
• Rebase: Reescribe el historial moviendo los commits propios al final de la rama base, creando un historial lineal.

# Integración clásica (Merge)
git checkout main
git merge feature/nueva-api

# Rebase para mantener un historial limpio
git checkout feature/refactor-db
git rebase main

Herramientas de Recuperación y Almacenamiento Temporal

Uso de Stash para Cambios Pendientes

Cuando es necesario cambiar de contexto abruptamente sin hacer un commit de un trabajo incompleto.

# Guardar temporalmente el estado actual
git stash save "Trabajo en progreso: refactorización de controladores"

# Recuperar y eliminar el último elemento del stash
git stash pop

# Listar todos los estados guardados
git stash list

Selección de Commits Específicos (Cherry-pick)

Útil para aplicar un parche o funcionalidad específica de una rama a otra sin realizar un merge completo.

# Aplicar un commit identificado por su hash
git cherry-pick a1b2c3d4

Gestión de Versiones y Etiquetas (Tagging)

Los tags identifican puntos específicos en el historial como hitos importantes (v1.0, v2.1-beta).

# Crear una etiqueta anotada
git tag -a v1.0.0 -m "Versión estable inicial para despliegue"

# Sincronizar etiquetas con el servidor
git push origin --tags

Administración de Submódulos

Git permite incluir otros repositorios como dependencias dentro de un proyecto principal.

# Añadir un repositorio externo como dependencia
git submodule add https://github.com/lib/librería-util.git libs/util

# Inicializar submódulos tras una clonación
git submodule update --init --recursive

Optimización del Flujo de Trabajo con .gitignore

Es vital excluir archivos temporales, binarios y secretos para mantener la integridad del repositorio. Un archivo .gitignore estándar debería contemplar:

# Dependencias
node_modules/
vendor/

# Variables de entorno y secretos
.env
*.pem

# Archivos de sistema y logs
.DS_Store
npm-debug.log*
logs/*.log

# Directorios de compilación
dist/
build/

Resolución de Conflictos

Los conflictos ocurren cuando dos personas modifican la misma línea en el mismo archivo. El proceso de resolución técnica es:

1. Identificar los archivos en conflicto mediante git status.
2. Abrir el archivo y elegir entre el cambio local (HEAD) y el cambio entrante.
3. Eliminar los marcadores de conflicto (<<<<, ====, >>>>).
4. Ejecutar git add sobre el archivo resuelto y finalizar con git commit.

Configuraciones Avanzadas de Repositorios Múltiples

Un repositorio local puede estar vinculado a múltiples servidores remotos para redundancia o diferentes entornos.

# Vincular a un servidor de respaldo
git remote add backup https://gitlab.com/mi-org/mirror.git

# Empujar cambios a todos los remotos
git push origin main
git push backup main