Git — qué es, principios de funcionamiento y comandos

¿Qué es Git?

Git es un sistema de control de versiones distribuido (VCS) que rastrea los cambios en los archivos y permite que varios desarrolladores trabajen en el mismo proyecto simultáneamente. A diferencia de los sistemas centralizados, en Git cada desarrollador tiene una copia completa del repositorio, incluyendo todo el historial de cambios, lo que hace que el sistema sea resistente a la pérdida de datos y no requiera una conexión constante a un servidor central.

La historia de Git comenzó en 2005, cuando Linus Torvalds creó un nuevo VCS después de que BitKeeper revocara su licencia gratuita para los desarrolladores del núcleo Linux. Los objetivos eran: velocidad, simplicidad de arquitectura, soporte para desarrollo no lineal mediante ramificaciones y distribución completa. En 3 meses Torvalds escribió el núcleo de Git, y en menos de un año el proyecto pasó a autogestionarse bajo el liderazgo de Junio Hamano.

Según la encuesta de Stack Overflow (2024), Git es utilizado por el 93,9% de los desarrolladores profesionales, lo que lo convierte en el sistema de control de versiones dominante en la industria. El competidor más cercano — Subversion (SVN) — se utiliza solo en el 5,2% de los proyectos, principalmente en grandes entornos corporativos con procesos centralizados.

Cómo funciona Git: repositorio y commits

Repositorio Git es un directorio donde Git rastrea los cambios de todos los archivos. Dentro del directorio hay una carpeta oculta .git que almacena todos los objetos del sistema: commits, árboles, blobs y referencias. Cuando un desarrollador crea un commit, Git no copia los archivos por completo — crea una instantánea y guarda una referencia a ella.

Cada commit contiene: un hash SHA-1 único (40 caracteres), una referencia al commit anterior (parent), autor, fecha, mensaje del commit y una referencia a un árbol que describe el estado de los archivos en el momento del commit. La cadena de commits forma un grafo acíclico dirigido donde cada commit apunta a uno o más padres.

# Inicialización del repositorio
git init my-project
cd my-project

# Creación de un commit
echo "Hola, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Ver el historial
git log --oneline --graph --all

Git utiliza tres áreas principales: working directory (archivos en disco), staging area (índice donde van los archivos preparados) y repository (historial de commits). El comando git add mueve los cambios del directorio de trabajo al staging, y git commit registra el contenido del staging en el repositorio. Esta separación permite al desarrollador ensamblar un commit significativo a partir de un conjunto de cambios sin confirmar cada edición por separado.

Comandos básicos de Git

Los comandos básicos de Git cubren el 90% de las operaciones diarias de un desarrollador. El comando git clone crea una copia local de un repositorio remoto, git pull obtiene los cambios del servidor y los fusiona con la rama actual, y git push envía los commits locales al servidor. Estos tres comandos forman el ciclo principal del flujo de trabajo con Git.

Para ver el estado se usa git status — muestra qué archivos están modificados, cuáles están en staging y cuáles no están rastreados. git diff muestra los cambios específicos en los archivos antes de agregarlos al staging. A continuación se muestra una tabla con los comandos más utilizados:

Para deshacer cambios, Git ofrece varias opciones. git reset mueve el puntero de la rama a un commit específico y puede restablecer el staging o el directorio de trabajo. git revert crea un nuevo commit que revierte los cambios del commit especificado — esta es una forma segura de revertir para ramas compartidas porque el historial no se reescribe.

Ramas en Git: main, feature y release

Las ramas en Git son punteros móviles ligeros a un commit específico. Crear una nueva rama no copia archivos, sino que simplemente crea un nuevo puntero, lo que hace que la ramificación sea prácticamente instantánea. La rama main (anteriormente master) es la rama principal del proyecto que contiene el código estable listo para su lanzamiento.

La práctica estándar es usar Git Flow o GitHub Flow. Git Flow utiliza ramas: main (código de lanzamiento), develop (rama de integración), feature/* (nuevas funciones), release/* (preparación de lanzamientos) y hotfix/* (correcciones urgentes). GitHub Flow es más simple: solo main y ramas feature, y todos los cambios se entregan mediante Pull Request.

# Crear y cambiar de rama
git branch feature-auth
git checkout feature-auth
# o con un solo comando:
git checkout -b feature-auth

# Lista de ramas
git branch --list
git branch -a  # todas las ramas, incluidas las remotas

# Eliminar una rama
git branch -d feature-auth

Una característica importante de la ramificación en Git es cherry-pick: mover un commit individual de una rama a otra usando el comando git cherry-pick <hash>. Esto es útil cuando necesitas transferir una corrección de error de una rama feature a una release sin fusionar toda la rama. Git también soporta rebase y rebase interactivo (git rebase -i) para comprimir, reordenar y editar commits.

Merge y Rebase

Merge (fusión) crea un commit de merge especial que tiene dos padres. Este commit registra el hecho de la fusión de dos ramas y conserva el historial completo — se puede ver dónde y cuándo ocurrió la fusión. Merge conserva el historial tal como fue creado, lo que simplifica la auditoría pero hace que el grafo de commits sea más complejo.

Rebase (rebase) en lugar de crear un commit de merge, mueve los commits de la rama actual a la punta de la rama objetivo. El historial se vuelve lineal — creando la impresión de que el desarrollo fue secuencial. Sin embargo, rebase reescribe el historial, cambiando los hashes SHA-1 de los commits, lo que lo hace peligroso para ramas compartidas a las que tienen acceso otros desarrolladores.

Recomendación: usa merge para ramas públicas donde el historial es visible para otros desarrolladores (feature → develop), y rebase para trabajo local cuando necesites aplicar cambios recientes de main a tu rama feature antes de crear un Pull Request. La regla es simple: si un commit ya se ha enviado al servidor — no lo rebases.

Resolución de conflictos

Conflicto de fusión ocurre cuando Git no puede fusionar automáticamente los cambios en un solo archivo. Git marca las secciones conflictivas en el archivo con marcadores especiales: <<<<<<< (nuestros cambios), ======= (separador), >>>>>>> (sus cambios). El desarrollador edita manualmente el archivo, eligiendo la opción deseada o combinando ambas, y completa la fusión con un commit.

Trabajo con repositorios remotos

Repositorio remoto (remote) es una copia de un repositorio Git ubicada en un servidor. GitHub, GitLab y Bitbucket son las plataformas más populares para alojar repositorios remotos. Proporcionan una interfaz web para ver código, gestionar accesos, hacer revisiones de código e integrar con sistemas CI/CD.

En Git, puedes configurar múltiples repositorios remotos para un proyecto. Por defecto, el remoto principal se llama origin. El comando git remote add añade un nuevo remoto, git fetch obtiene cambios sin fusionar, y git pull es una abreviatura de git fetch + git merge. Para trabajar con código mediante Pull Request, un desarrollador crea un fork del repositorio, lo clona, trabaja en una rama feature y envía una solicitud de fusión al repositorio original.

# Agregar un repositorio remoto
git remote add origin https://github.com/user/repo.git

# Ver repositorios remotos
git remote -v

# Enviar una rama al servidor
git push -u origin feature-auth

# Obtener cambios de una rama remota
git pull origin main

Los repositorios remotos soportan etiquetado para marcar versiones de lanzamiento. Las etiquetas pueden ser ligeras (solo un puntero a un commit) o anotadas (contienen metadatos: autor, fecha, mensaje). Se recomiendan etiquetas anotadas para versiones de lanzamiento porque llevan información completa de la versión y pueden firmarse con una clave GPG para la verificación de autoría.

Git Worktree para trabajo paralelo

Git Worktree permite trabajar con múltiples ramas simultáneamente en diferentes directorios sin cambiar entre ellas. El comando git worktree add ../feature-auth feature-auth crea un nuevo directorio de trabajo feature-auth donde puedes escribir código sin cambiar de rama en el directorio principal. Worktree es útil para correcciones rápidas en una rama release cuando el directorio principal está ocupado con un desarrollo a largo plazo.

Git Submodules para dependencias

Git Submodules es un mecanismo para incluir un repositorio Git dentro de otro. Un submódulo almacena una referencia a un commit fijo de un repositorio externo, lo que garantiza la reproducibilidad de la compilación. El comando git submodule add https://github.com/example/lib.git añade una biblioteca externa como submódulo. Al clonar un proyecto con submódulos, hay que ejecutar git submodule update --init --recursive para descargar todas las dependencias.