Git

¿Qué es Git?

Git es un sistema de control de versiones distribuido que rastrea los cambios en los archivos a lo largo del tiempo. Te permite guardar instantáneas de tu proyecto en cualquier momento, comparar versiones, revertir errores y colaborar con otras personas sin sobrescribir el trabajo de los demás.

Creado por Linus Torvalds en 2005 para gestionar el kernel de Linux, Git se ha convertido en el sistema de control de versiones más utilizado en el mundo. Ya sea que estés construyendo un proyecto personal en solitario o contribuyendo a una base de código con miles de desarrolladores, Git es la herramienta que lo hace posible.

La idea central es sencilla: en lugar de guardar una única copia de tu proyecto, Git guarda una serie de commits, que son instantáneas de cada archivo rastreado en un momento específico. Puedes viajar al pasado, comparar versiones, crear ramas para probar nuevas ideas y fusionar tu trabajo cuando esté listo. Este modelo escala desde una sola persona hasta miles.

Por qué es importante el control de versiones

Sin control de versiones, la colaboración es un caos. Si dos personas editan el mismo archivo, el trabajo de alguien terminará siendo sobrescrito. Un bug introducido la semana pasada obligaría a deshacer manualmente horas de cambios. Un experimento con una funcionalidad que sale mal significaría empezar desde cero.

Git resuelve todos estos problemas:

• Rastrea cada cambio — quién cambió qué, cuándo y por qué. El historial completo siempre está disponible.
• Revierte de forma segura — vuelve a cualquier estado anterior sin perder el trabajo actual.
• Trabaja en paralelo — las ramas permiten que varias personas trabajen en diferentes funcionalidades simultáneamente.
• Colabora sin miedo — Git fusiona los cambios de manera inteligente y marca los conflictos para que los resuelvas.
• Trabaja offline — todo es local hasta que decidas hacer push a un servidor remoto.

El control de versiones no es opcional para el desarrollo profesional. Es una habilidad fundamental que todo desarrollador necesita, independientemente del lenguaje, framework o plataforma.

Cómo funciona Git

Git opera en tres áreas principales: el working directory, el staging area y el repository.

Tu working directory es donde editas los archivos. Cuando ejecutas git add, los cambios se mueven al staging area, una zona de preparación para el próximo commit. Cuando ejecutas git commit, los cambios en el staging area se guardan como una nueva instantánea (snapshot) en el repository.

# Edit a file in your working directory
echo "Hello, Git!" > hello.txt

# Stage the change
git add hello.txt

# Commit the staged change
git commit -m "Add hello.txt"

Este flujo de tres pasos —editar, preparar (stage) y confirmar (commit)— te brinda un control preciso sobre lo que se incluye en cada instantánea. Puedes añadir partes de un archivo al staging area, agrupar varios archivos y crear commits que representen cada uno un único cambio lógico.

Internamente, Git almacena los datos como un grafo acíclico dirigido (DAG) de objetos de commit. Cada commit apunta a su padre, formando una cadena de historial. Las ramas (branches) son simplemente punteros ligeros a commits específicos, y HEAD es un puntero al commit en el que te encuentras actualmente.

Instalando Git

Git está disponible para todos los principales sistemas operativos:

macOS:

# Using Homebrew
brew install git

# Or install Xcode Command Line Tools
xcode-select --install

Windows:

# Download from git-scm.com or use winget
winget install Git.Git

Linux:

# Debian/Ubuntu
sudo apt install git

# Fedora
sudo dnf install git

# Arch
sudo pacman -S git

Verifica la instalación:

git --version
# git version 2.45.0

Después de instalarlo, configura tu identidad; esta información se incluye en cada commit que realices:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Comandos básicos de Git

Crear un repositorio

# Start a new repository in the current directory
git init

# Clone an existing repository
git clone https://github.com/user/repo.git

git init crea una carpeta oculta .git/ que contiene todos los datos de seguimiento de Git. git clone copia un repositorio existente —incluyendo todo su historial— a tu máquina.

Seguimiento de cambios

# See which files are modified, staged or untracked
git status

# Stage a specific file
git add filename.js

# Stage all changes
git add .

# Commit with a message
git commit -m "Add user authentication"

git status es el comando que ejecutarás con más frecuencia. Te indica qué ha cambiado, qué está en el área de preparación (staged) y qué no está siguiendo Git. Revisa siempre el estado antes de hacer un commit.

Ver el historial

# Show commit history
git log

# Compact one-line format
git log --oneline

# Show changes in each commit
git log -p

# Show a visual branch graph
git log --oneline --graph --all

El historial de commits es la línea de tiempo de tu proyecto. Úsalo para entender cómo evolucionó el código, quién realizó los cambios y por qué se tomaron ciertas decisiones.

Comparar cambios

# Diff between working directory and staging area
git diff

# Diff between staging area and last commit
git diff --staged

# Diff between two commits
git diff abc1234 def5678

git diff te muestra exactamente qué cambió, línea por línea. Es fundamental para revisar tu propio trabajo antes de hacer el commit y para entender qué cambió otra persona en un pull request.

Deshacer cambios

# Discard changes in working directory
git checkout -- filename.js

# Unstage a file
git reset HEAD filename.js

# Amend the last commit
git commit --amend -m "Updated commit message"

# Revert a commit (creates a new commit that undoes it)
git revert abc1234

Git hace que experimentar sea seguro porque siempre puedes volver atrás. La clave es entender la diferencia entre descartar cambios, quitarlos del área de preparación (unstaging) y crear nuevos commits que reviertan los anteriores.

Trabajar con ramas

# List branches
git branch

# Create a new branch
git branch feature-login

# Switch to a branch
git checkout feature-login

# Create and switch in one command
git checkout -b feature-signup

# Delete a branch
git branch -d feature-login

Las ramas son el superpoder de Git. Te permiten trabajar en nuevas funcionalidades, corregir errores o experimentar sin afectar la base de código principal. Cuando tu trabajo esté listo, fusionas la rama.

Fusionar y rebasar (Merging and rebasing)

Cuando una rama está lista, la integras de nuevo en la línea principal. git merge crea un commit de fusión (merge commit) que une los dos historiales, mientras que git rebase reproduce tus commits encima de otra rama para obtener un historial lineal:

# Merge a feature branch into main
git checkout main
git merge feature-login

# Rebase a feature branch onto the latest main
git checkout feature-login
git rebase main

Si las mismas líneas cambiaron en ambas ramas, Git se detiene y marca los archivos como conflictivos. Edita los archivos para mantener el contenido correcto, elimina los marcadores de conflicto (<<<<<<<, =======, >>>>>>>), luego añádelos al área de preparación y continúa:

git add .
git merge --continue   # or: git rebase --continue

Para mantener el historial ordenado, un squash merge colapsa cada commit de una rama de funcionalidad en un único commit en la rama de destino:

git checkout main
git merge --squash feature-dark-mode
git commit -m "Add dark mode feature"

Usa merge cuando quieras preservar el historial completo de la rama; usa rebase o squash cuando quieras una rama principal limpia y lineal. Nunca hagas rebase ni squash de commits que ya hayan sido enviados (pushed) a una rama compartida.

Sincronización con remotos

# Add a remote server
git remote add origin https://github.com/user/repo.git

# Push commits to remote
git push origin main

# Pull latest changes
git pull origin main

# Fetch without merging
git fetch origin

Los remotos son copias de tu repositorio alojadas en servidores. El remoto por defecto suele llamarse origin. Push envía tus commits al remoto, y pull descarga y fusiona los cambios remotos en tu rama.

El archivo .gitignore

No todo debe estar bajo seguimiento. Las dependencias, los resultados de compilación, los archivos de entorno y la configuración del IDE suelen ignorarse:

# Dependencies
node_modules/
vendor/

# Build output
dist/
build/

# Environment variables
.env
.env.local

# IDE settings
.vscode/
.idea/

# OS files
.DS_Store
Thumbs.db

Coloca un archivo .gitignore en la raíz de tu repositorio. Git omitirá cualquier archivo o directorio que coincida con estos patrones. Si ya has hecho commit de archivos que deseas ignorar, elimínalos primero del seguimiento:

git rm -r --cached node_modules/
git commit -m "Remove node_modules from tracking"

Entendiendo los commits

Un commit es la unidad fundamental de Git. Cada commit contiene:

• Un hash único — un identificador SHA-1 de 40 caracteres como a1b2c3d4e5f6...
• Un mensaje — una descripción de qué cambió y por qué
• Un autor — quién realizó el cambio
• Una marca de tiempo — cuándo se realizó el cambio
• Un padre — el commit sobre el cual se construye (excepto el primer commit)
• Un snapshot — el estado de todos los archivos rastreados en ese momento

Los buenos mensajes de commit siguen una convención. La primera línea es un resumen corto en modo imperativo (de menos de 72 caracteres). Un cuerpo opcional explica el contexto:

git commit -m "Fix null pointer in user authentication

The login endpoint was throwing a 500 error when the email
field was missing from the request body. Added a null check
before accessing user properties."

Cada commit debe representar un único cambio lógico. Esto facilita la comprensión, revisión y reversión de cambios individuales sin afectar el trabajo no relacionado.

Flujos de trabajo comunes de Git

Flujo de trabajo centralizado

Todo el mundo trabaja en la rama main. Es sencillo, pero arriesgado para los equipos:

git pull origin main
# make changes
git add .
git commit -m "Update feature"
git push origin main

Flujo de trabajo de ramas por funcionalidad (Feature branch workflow)

Cada funcionalidad o corrección tiene su propia rama. Las integraciones se realizan a través de pull requests:

git checkout -b feature-user-profile
# make changes
git push origin feature-user-profile
# open a pull request on GitHub

Flujo de trabajo Gitflow

Un modelo estructurado con ramas main, develop, feature, release y hotfix. Es la mejor opción para proyectos con lanzamientos programados:

git checkout -b develop
git checkout -b feature-new-login
# work on feature
git checkout develop
git merge feature-new-login
git checkout -b release-v1.0
# finalize release
git checkout main
git merge release-v1.0
git tag v1.0.0

Desarrollo basado en el tronco (Trunk-based development)

Todos realizan commits en main (el tronco) con frecuencia, utilizando feature flags de corta duración. Es muy popular en empresas como Google y Meta:

git checkout main
# make small, frequent changes
git add .
git commit -m "Add feature flag for new dashboard"
git push origin main

Mejores prácticas

• Haz commits pronto y a menudo — los commits pequeños son más fáciles de entender y revertir.
• Escribe mensajes de commit claros — usa el modo imperativo y explica el porqué, no solo el qué.
• Crea una rama para cada funcionalidad — mantén la rama main limpia y lista para desplegar.
• Haz pull antes de hacer push — integra siempre los cambios remotos antes de compartir tu trabajo.
• Revisa tu propio diff — ejecuta git diff --staged antes de hacer el commit para detectar errores.
• Nunca hagas commit de secretos — utiliza variables de entorno y .gitignore.
• Etiqueta los lanzamientos — usa etiquetas de versionado semántico como v1.0.0 para facilitar el rollback.
• Mantén el historial limpio — haz rebase de las ramas de funcionalidades antes de fusionarlas para evitar merge commits desordenados.

Errores comunes

• Hacer commits con demasiados cambios no relacionados en uno solo.
• Usar mensajes vagos como “fix” o “update” que no explican nada.
• Hacer force-push en ramas compartidas y sobrescribir el trabajo de otros.
• No configurar el .gitignore, lo que provoca que se suban node_modules o archivos .env.
• Trabajar directamente en main en lugar de crear una feature branch.
• Olvidar hacer pull antes de hacer push, lo que provoca conflictos de merge.
• No hacer copias de seguridad de los repositorios remotos; tenerlo solo en local no es suficiente.

Qué aprender a continuación

Ya dominas los fundamentos de Git: repositorios, commits, branches, merging y remotes. A partir de aquí, el siguiente paso natural es GitHub para la colaboración en la nube, issues, pull requests y Actions. Elige un proyecto, construye algo real y deja que la práctica se acumule.