Jorge Saavedragitprincipiantesherramientas
Una historia que seguro te suena
Hace varios años, mientras trabajaba en mi proyecto de titulación en la universidad, vivía en un caos absoluto de archivos. Tenía carpetas con nombres como
proyecto_final, proyecto_final_v2, proyecto_final_DEFINITIVO y, por supuesto, proyecto_final_DEFINITIVO_ahora_si. Cuando un compañero necesitaba revisar algo, le enviaba el archivo por correo. Cuando ambos editábamos al mismo tiempo, el resultado era un desastre de versiones que nadie podía reconciliar.En algún momento escuché hablar de Git, pero lo descarté pensando que era algo solo para programadores avanzados. Gran error. Cuando finalmente lo aprendí, me di cuenta de que no solo habría evitado todo ese caos, sino que habría trabajado mucho mejor en equipo. Si estás en una situación parecida, este post es para ti.
Qué es Git?
Git es un sistema de control de versiones distribuido. En términos simples, es una herramienta que registra cada cambio que haces en tus archivos, creando un historial completo de tu proyecto. Esto significa que puedes volver a cualquier punto en el tiempo, ver exactamente qué cambió y quién lo cambió, y trabajar en equipo sin pisarse los pies.
A diferencia de simplemente copiar archivos en carpetas, Git te da:
- Un historial completo y detallado de cada modificación
- La capacidad de trabajar en paralelo con otras personas sin conflictos
- La posibilidad de experimentar con ramas sin afectar el código principal
- Un respaldo distribuido, ya que cada copia del repositorio es un respaldo completo
Git no es GitHub
Git es la herramienta de versionamiento. GitHub, GitLab y Bitbucket son plataformas que alojan repositorios Git en la nube y agregan funcionalidades como pull requests, issues y CI/CD. Puedes usar Git perfectamente sin ninguna de estas plataformas.
Comandos básicos
Vamos a recorrer los comandos fundamentales que vas a usar todos los días. No te preocupes si al principio parecen muchos; con la práctica se vuelven automáticos.
Inicializar un repositorio
Todo proyecto con Git empieza con este comando. Lo ejecutas dentro de la carpeta de tu proyecto y Git comenzará a rastrear los cambios:
bash
git initEsto crea una carpeta oculta llamada
.git donde Git guarda toda la información del historial. No la borres ni la modifiques manualmente.Agregar archivos al área de preparación
Antes de guardar un cambio en el historial, necesitas decirle a Git cuáles archivos quieres incluir. Esto se hace con
git add:bash
# Agregar un archivo especifico
git add mi-archivo.txt
# Agregar todos los archivos modificados
git add .El área de preparación (staging area) es como una sala de espera. Los archivos que agregas ahí están listos para ser incluidos en el próximo commit, pero todavía no se han guardado en el historial.
Ver el estado del repositorio
Este comando te muestra qué archivos han cambiado, cuáles están en el área de preparación y cuáles no están siendo rastreados:
bash
git statusVas a usar
git status constantemente. Es tu brújula dentro de Git: te dice exactamente dónde estás y qué falta por hacer.Crear un commit
Un commit es una instantánea de tu proyecto en un momento dado. Cada commit tiene un mensaje que describe qué cambiaste y por qué:
bash
git commit -m "Agregar pagina de inicio con navegacion basica"Después de tu primer commit, tu historial se ve así:
Escribe buenos mensajes de commit
Un buen mensaje de commit explica el por qué del cambio, no solo el qué. En lugar de "cambios varios", escribe algo como "Corregir validación de formulario de registro para aceptar correos con punto". Tu yo del futuro te lo va a agradecer.
También puedes configurar tu nombre y correo para que aparezcan en tus commits:
bash
git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"Ver el historial de commits
A medida que trabajas, tu historial de commits va creciendo. Para verlo, usas:
bash
git logEste comando te muestra cada commit con su hash identificador, el autor, la fecha y el mensaje. Si ya llevas un par de commits, tu historial lucirá algo así:
Cada círculo representa un commit, y puedes navegar por este historial en cualquier momento. Si necesitas una versión más compacta del log, prueba:
bash
git log --onelineRamas (Branches)
Las ramas son una de las funcionalidades más poderosas de Git. Una rama es básicamente una línea independiente de desarrollo. Te permiten trabajar en nuevas funcionalidades, correcciones de errores o experimentos sin afectar el código principal.
Crear una nueva rama
Hay dos formas equivalentes de crear una rama y moverte a ella:
bash
# Forma clasica
git checkout -b mi-nueva-rama
# Forma moderna (Git 2.23+)
git switch -c mi-nueva-ramaCuando creas una rama, Git toma una copia del estado actual y te permite trabajar sobre ella de forma aislada. Visualmente, se ve así:
Aislamiento entre ramas
Lo interesante es que los cambios que hagas en tu rama no afectan a la rama principal, y viceversa. Si alguien hace un commit en
main mientras tú trabajas en tu rama, ambas líneas avanzan de forma independiente:Este aislamiento es fundamental. Significa que puedes experimentar con tranquilidad, sabiendo que si algo sale mal, la rama principal sigue intacta. Para moverte entre ramas existentes:
bash
# Ver todas las ramas
git branch
# Cambiar a otra rama
git checkout main
# o
git switch mainMerge: fusionando cambios
Una vez que terminas de trabajar en tu rama y estás conforme con los cambios, es hora de fusionarlos con la rama principal. Esto se hace con
git merge.Imaginemos un escenario común: estás trabajando en un equipo. Tú estás en la rama
feature/ui-improvements mejorando la interfaz, mientras tu compañero trabaja en feature/search agregando funcionalidad de búsqueda. Ambos partieron de main.Cuando ambos terminan, fusionan sus ramas en
main:bash
# Primero, cambia a la rama principal
git checkout main
# Fusionar la primera rama
git merge feature/ui-improvements
# Fusionar la segunda rama
git merge feature/searchEl resultado es que
main ahora contiene los cambios de ambos:Conflictos de merge
A veces, dos personas modifican las mismas líneas del mismo archivo. Cuando esto pasa, Git no puede decidir automáticamente cuál versión conservar y marca un conflicto. No te asustes. Git te mostrará exactamente dónde están los conflictos y tú decides cómo resolverlos. Con el tiempo, manejar conflictos se vuelve algo rutinario.
Colaboración remota
Hasta ahora todo lo que hemos visto funciona en tu computadora local. Pero la verdadera magia ocurre cuando conectas tu repositorio con un servidor remoto como GitHub, GitLab o Bitbucket.
Subir tus cambios
Para enviar tus commits al repositorio remoto, usas
git push:bash
# La primera vez que subes una rama nueva
git push -u origin mi-rama
# Las siguientes veces, solo necesitas
git pushTraer los cambios del equipo
Para descargar los cambios que otros han subido al repositorio remoto y fusionarlos con tu rama local:
bash
git pullUna buena práctica es hacer
git pull antes de empezar a trabajar cada día. Así te aseguras de tener la versión más reciente del proyecto y reduces la probabilidad de conflictos.git fetch vs git pull
Si quieres ver qué cambios hay en el remoto sin fusionarlos automáticamente, usa
git fetch. Esto descarga la información pero no modifica tu código. Después puedes revisar los cambios y decidir cuándo fusionar con git merge.Estrategias de branching
Ya sabes crear ramas y fusionarlas, pero en un equipo real surge una pregunta importante: cómo organizamos las ramas? No es lo mismo trabajar en un proyecto personal que en un equipo de veinte personas con releases planificados. Veamos las dos estrategias más populares.
Trunk-Based Development
La idea es simple: todos trabajan sobre la rama principal (trunk), o en ramas de vida muy corta que se fusionan rápidamente, idealmente en menos de un día. No hay ramas de larga duración, no hay ramas
develop, no hay complejidad innecesaria.El flujo se ve más o menos así:
- Creas una rama pequeña para tu cambio (
fix/login-bug) - Haces uno o dos commits
- Abres un pull request
- Lo revisan, lo aprueban, lo fusionas en
main - Borras la rama
Esta estrategia funciona muy bien cuando:
- El equipo es pequeño o mediano
- Tienes un pipeline de CI/CD que ejecuta pruebas automáticamente
- Haces despliegues frecuentes (varias veces al día o por semana)
- Trabajas con microservicios o proyectos que cambian rápido
Feature flags
Si necesitas trabajar en una funcionalidad que toma varios días pero quieres seguir fusionando a main, puedes usar feature flags. Así el código está en main pero desactivado hasta que esté listo. Esto es común en equipos que practican Trunk-Based Development.
GitFlow
GitFlow es una estrategia más estructurada, diseñada por Vincent Driessen en 2010. Define un conjunto de ramas con roles específicos:
main: siempre refleja el código en produccióndevelop: rama de integración donde se acumulan los cambios para el próximo releasefeature/*: ramas para nuevas funcionalidades, nacen dedeveloprelease/*: ramas de preparación para un release, se crean desdedevelophotfix/*: correcciones urgentes en producción, nacen demain
GitFlow es una buena opción cuando:
- El equipo es grande y trabaja en muchas funcionalidades en paralelo
- Los releases son planificados y tienen fechas definidas
- Necesitas mantener varias versiones en producción simultáneamente
- Trabajas en proyectos empresariales con procesos de QA formales
Cuál elegir?
Mi recomendación: si estás empezando o trabajas en un equipo pequeño, empieza con Trunk-Based Development. Es más simple, fomenta la integración continua y te obliga a mantener tus cambios pequeños y manejables. La complejidad de GitFlow solo se justifica cuando realmente la necesitas.
Muchos equipos que empiezan con GitFlow eventualmente migran a Trunk-Based Development cuando adoptan CI/CD maduro. No hay una respuesta universal; lo importante es que todo el equipo entienda y siga la misma estrategia.
Reflexión final
Cuando miro atrás y recuerdo esos días de archivos con nombres ridículos y correos con adjuntos llamados "version_final_v3_revisada.docx", me resulta casi increíble lo mucho que cambió mi forma de trabajar al adoptar Git. No es exageración decir que es una de las herramientas más importantes que he aprendido en mi carrera.
Git no es perfecto. Tiene una curva de aprendizaje y hay momentos en los que te vas a sentir perdido. Pero una vez que internalizas los conceptos básicos que vimos aquí (commits, ramas, merges), todo lo demás se construye sobre esa base.
Si todavía no usas Git, hoy es un excelente día para empezar. Crea un repositorio, haz tu primer commit, experimenta con ramas. Rompe cosas. Para eso está Git: para que puedas romper cosas con la confianza de que siempre puedes volver atrás.
