Git

Resumen

Git es un sistema de control de versiones distribuido (DVCS) creado por Linus Torvalds en 2005 para gestionar el kernel de Linux. A diferencia de sistemas centralizados como SVN, cada copia de un repositorio Git contiene el historial completo del proyecto. Eso significa que podés hacer commits, crear ramas, revisar el historial y deshacer cambios sin conexión a internet.

Importa porque es la herramienta universal de colaboración en software. GitHub, GitLab y Bitbucket existen sobre Git. Casi todo proyecto open source y la mayoría de los equipos profesionales lo usan. Saber Git no es opcional: es tan básico como saber usar un editor de texto o una terminal.

Git no es solo un backup de código. Es una máquina del tiempo que te permite viajar a cualquier punto del historial, experimentar en ramas paralelas sin romper lo que funciona, y entender quién cambió qué, cuándo y por qué. Un buen uso de Git reemplaza carpetas como proyecto_final_v2_corregido_backup con un historial limpio y trazable.

Alcance y supuestos

Este paquete cubre Git a nivel conceptual y práctico: los conceptos fundamentales (repositorio, commit, rama, merge, remote), el flujo de trabajo diario (clone, add, commit, push, pull), ramas y fusiones, y resolución básica de conflictos. También contrasta Git con sistemas centralizados como SVN para explicar por qué el modelo distribuido cambió la industria.

No cubre los internals de Git (objetos, packfiles, refs, reflog), operaciones avanzadas de reescritura de historial (rebase interactivo, squash, filter-branch), hooks de servidor, ni features específicas de plataformas como GitHub Actions o GitLab CI.

Asume que tenés una terminal, sabés ejecutar comandos, y entendés qué son archivos y directorios.

Modelo mental

Pensá en un fotógrafo que trabaja en un estudio con tres zonas: el set de fotografía, una mesa de selección y un álbum definitivo.

• El set es tu directorio de trabajo. Ahí modificás archivos, creás nuevos, borrás los que no sirven. Todo es efímero: si apagás la luz, lo que no guardaste se pierde.
• La mesa de selección es el staging area. Después de una sesión, ponés las fotos que te gustan sobre la mesa. Las que no, las dejás en el set o las tirás. La mesa representa lo que va a entrar en la próxima entrega.
• El álbum es el repositorio. Cuando estás seguro de la selección, pegás las fotos en el álbum con una etiqueta que dice «Sesión del 21 de julio: retratos con luz natural». Eso es un commit. Una vez pegado, queda para siempre en el historial.

Con Git, cada commit es una foto del proyecto entero en un momento dado. No guarda las diferencias entre versiones: guarda el estado completo. Eso hace que cambiar de una versión a otra sea instantáneo y que cualquier copia del álbum sea autosuficiente.

Uso práctico

Git es ubicuo. Lo usás para:

• ✅ Guardar el historial de cada cambio con mensajes que explican el porqué.
• ✅ Trabajar en features en paralelo sin interferir con el código de otros.
• ✅ Volver a una versión anterior cuando algo se rompe.
• ✅ Colaborar con otras personas sincronizando cambios a través de un remote.
• ❌ Almacenar archivos binarios grandes que cambian seguido (usá Git LFS o un almacenamiento externo).
• ❌ Reemplazar un sistema de deployment o un backup automático (Git es control de versiones, no infraestructura).

El flujo diario

El 90% del uso de Git cabe en seis comandos. Entenderlos es entender Git.

# 1. Clonar un repositorio existente (una sola vez)
git clone https://github.com/usuario/proyecto.git

# 2. Ver qué cambió desde el último commit
git status

# 3. Mover cambios al staging (la mesa de selección)
git add archivo.ts        # un archivo específico
git add .                 # todos los cambios del directorio actual

# 4. Guardar los cambios en el historial (pegar en el álbum)
git commit -m "Agrega validación de email en el formulario"

# 5. Bajar cambios que otras personas subieron
git pull

# 6. Subir tus commits al remote
git push

Cada commit tiene un identificador único (un hash SHA-1 como a1b2c3d), un autor, una fecha y un mensaje. El mensaje es la parte más importante: en seis meses, cuando no recuerdes por qué hiciste ese cambio, el mensaje es tu única pista.

Ramas: trabajar en paralelo sin miedo

Una rama es una línea independiente de desarrollo. La rama principal suele llamarse main (o master en proyectos antiguos). Crear una rama es como sacar una fotocopia del proyecto para trabajar sin afectar el original.

# Crear una rama nueva y cambiarse a ella
git checkout -b feature/login-oauth

# Hacer commits en la rama...
git add .
git commit -m "Agrega flujo OAuth con Google"

# Volver a main
git checkout main

# Traer los cambios de la rama a main
git merge feature/login-oauth

# Eliminar la rama (ya no se necesita)
git branch -d feature/login-oauth

Mientras trabajás en feature/login-oauth, otras personas pueden estar trabajando en feature/payment y fix/typo-header. Ninguno interfiere con los demás. Cuando cada rama está lista, se integra a main con un merge.

Este modelo —feature branches— es el más común en equipos profesionales. Cada feature, bug fix o experimento tiene su propia rama. main solo recibe código que ya fue revisado y probado. Eso mantiene main siempre desplegable.

Merges y conflictos

Un merge combina dos líneas de desarrollo. Git es bueno haciendo merges automáticos: si dos personas modificaron archivos distintos, Git los une sin problemas. Si dos personas modificaron las mismas líneas del mismo archivo, hay un conflicto.

git merge feature/login-oauth
# Auto-merging src/auth.ts
# CONFLICT (content): Merge conflict in src/auth.ts
# Automatic merge failed; fix conflicts and then commit the result.

Git marca las zonas conflictivas dentro del archivo con <<<<<<<, ======= y >>>>>>>. Tu trabajo es elegir qué versión queda —la de main, la de la rama, una combinación de ambas—, eliminar las marcas, y hacer commit del resultado.

<<<<<<< HEAD
function login(email: string, password: string) {
=======
function loginWithOAuth(provider: string) {
>>>>>>> feature/login-oauth

El conflicto no es un error de Git: es Git diciendo «dos personas tomaron decisiones distintas sobre las mismas líneas; necesito que un humano decida». Resolver conflictos es una skill que se aprende con la práctica.

Centralizado vs distribuido

Antes de Git, el estándar era SVN (Subversion), un sistema centralizado. La diferencia fundamental cambia todo:

| Aspecto | SVN (centralizado) | Git (distribuido) | |---|---|---| | Historial | Solo en el servidor | Cada copia tiene el historial completo | | Commits sin red | Imposible | Funcionan offline | | Ramas | Caras y lentas (copian todo) | Baratas y rápidas (apuntador) | | Workflow típico | Commit directo al servidor | Commit local → push al remote | | Experimentar | Riesgoso (afecta a otros) | Seguro (en rama local) |

La diferencia más importante es psicológica: en SVN, un commit es un acto público que otros ven inmediatamente. En Git, un commit es privado hasta que hacés push. Eso fomenta commits más chicos, más frecuentes y mejor documentados, porque no hay presión de «esto tiene que estar perfecto antes de compartirlo».

Ejemplo trabajado: feature branch completo

Un equipo está construyendo una app de tareas. Te asignan agregar búsqueda por texto. El flujo completo:

# 1. Actualizá main antes de empezar
git checkout main
git pull

# 2. Creá una rama para la feature
git checkout -b feature/search

# 3. Trabajá en la feature, haciendo commits chicos y frecuentes
echo "funcion buscar" > search.ts
git add search.ts
git commit -m "Agrega estructura inicial de búsqueda"

echo "filtro por texto" >> search.ts
git add search.ts
git commit -m "Implementa filtro por coincidencia de texto"

echo "tests" > search.test.ts
git add search.test.ts
git commit -m "Agrega tests para búsqueda por texto"

# 4. Mientras tanto, alguien actualizó main. Traé esos cambios a tu rama
git checkout main
git pull
git checkout feature/search
git merge main
# Sin conflictos: tu feature y los cambios en main no se tocaron

# 5. La feature está lista. Volvé a main e integrá
git checkout main
git merge feature/search

# 6. Subí a GitHub y limpiá
git push
git branch -d feature/search

Cada commit cuenta una historia: primero la estructura, después la implementación, después los tests. Si dentro de tres meses alguien se pregunta por qué search.ts tiene esa forma, el historial lo explica paso a paso.

Buenas prácticas que el ejemplo muestra y que aplican siempre:

• Actualizá main antes de crear una rama. Empezar desde una versión vieja produce conflictos evitables.
• Hacé commits chicos y con mensajes claros. «WIP», «fixes» y «cambios» no le sirven a nadie. «Agrega validación de email en el formulario» sí.
• Integrá main en tu rama seguido. Si esperás tres semanas para hacer merge, los conflictos se acumulan.
• Borrá las ramas después de mergearlas. Una rama mergeada que sigue existiendo genera confusión sobre si todavía se usa.

Evidencia

• Pro Git, 2nd Edition — Scott Chacon and Ben Straub es el libro canónico sobre Git. Cubre desde los fundamentos hasta los internals, con ejemplos claros y diagramas.
• Git Reference Manual documenta cada comando, opción y flag. Es la fuente de verdad cuando necesitás saber exactamente qué hace git reset --soft.
• GitHub, Git Guides ofrece tutoriales prácticos para el flujo de trabajo diario: clone, branch, commit, merge, y pull request.