Presentación
Modificas varios archivos.
Algo deja de funcionar.
Y llega esa pregunta ligeramente desagradable:
¿qué ha cambiado desde el momento en que todo iba aún bien?
Git existe precisamente para que esa pregunta tenga una respuesta.
Una carpeta clásica muestra el estado actual de un proyecto.
Git añade su historial.
Cada etapa importante puede registrarse en un commit.
Los commits forman progresivamente una sucesión de estados que se pueden comparar, recorrer, compartir o usar para recuperar una versión antigua.
Git transforma un conjunto de archivos en historial navegable.
Esta idea se vuelve aún más potente con las branches.
El proyecto puede explorar varias direcciones sin sobrescribir inmediatamente su línea principal.
Una funcionalidad, una corrección o una experimentación pueden vivir por separado hasta el momento en que se decide reunirlas.
Git es también distribuido.
Cuando se clona un repositorio, no se recuperan solo los archivos visibles.
Una gran parte del historial existe también localmente.
Commits, branches, comparación y creación de nuevas versiones pueden por tanto continuar sin conexión permanente a un servidor central.
El repositorio remoto se vuelve sobre todo un punto de intercambio.
Esta propiedad explica la diferencia con GitHub.
Git sabe versionar.
GitHub, GitLab, Codeberg u otra forja pueden alojar y organizar la colaboración alrededor del repositorio.
Git puede funcionar con ellos, con un servidor personal o simplemente en local.
Creado inicialmente para el desarrollo del núcleo Linux, Git sigue siendo gratuito y open source.
Su potencia va acompañada de un modelo mental a veces desconcertante.
Working tree, staging, commits, branches, remotes y reescritura del historial no siempre corresponden a las intuiciones construidas con un simple sistema de archivos.
Pero no es necesario conocer todos los comandos de Git para comprender lo que lo hace valioso.
Su lógica fundamental se resume en unos pocos verbos:
guardar → comparar → aislar → reunir → compartir.
Funcionalidades
Commits: construir la memoria del proyecto
El commit registra un estado identificable acompañado de un mensaje.
Permite después recuperar cuándo apareció una modificación, qué archivos cambiaron o cómo era el proyecto anteriormente.
Un buen historial no conserva por tanto solo archivos.
Conserva una parte del razonamiento del desarrollo.
Esta diferencia se vuelve particularmente visible varios meses después.
Un commit claro puede explicar por qué existe todavía una condición extraña en el código o por qué se modificó una arquitectura.
El control de versiones se convierte entonces en una forma de memoria técnica.
Staging: elegir qué pertenece al próximo commit
Git coloca una etapa entre los archivos modificados y el commit.
Esta zona de staging permite seleccionar los cambios que deben guardarse juntos.
La función parece a veces inútil al principio.
Se vuelve preciosa cuando varias tareas se han mezclado durante una misma sesión.
Una corrección de bug, una documentación y una experimentación no necesariamente necesitan convertirse en el mismo commit.
El staging permite reconstruir unidades más coherentes.
Transforma una sesión desordenada en un historial más legible.
Branches: explorar varios futuros
Una branch permite proseguir una línea de trabajo separada.
Funcionalidad, corrección o experiencia pueden evolucionar sin perturbar inmediatamente la branch principal.
Esta ligereza fomenta la experimentación.
Una arquitectura puede probarse y después abandonarse sin destruir el estado estable del proyecto.
Las branches hacen posible una idea bastante importante:
el proyecto puede tener varios futuros antes de elegir uno.
Merge y rebase
Cuando varias branches divergen, sus cambios a veces deben reunirse.
El merge conserva explícitamente el encuentro entre varias líneas de trabajo.
El rebase puede reposicionar una serie de commits sobre una nueva base para obtener un historial más lineal.
Ningún enfoque es universalmente superior.
Lo importante es comprender que Git puede representar o remodelar el historial.
Esta potencia exige más prudencia cuando un commit ya se ha compartido.
Reescribir una branch personal es una cosa.
Reescribir el historial utilizado por varios colaboradores es otra.
Remotes: intercambiar entre varios repositorios
Los remotes permiten intercambiar commits con otros repositorios.
Esta mecánica no impone ninguna plataforma particular.
GitHub, GitLab, Codeberg, Gitea o un simple servidor SSH pueden todos desempeñar ese papel.
El remote no es por tanto «el verdadero repositorio».
Constituye otra copia con la que el proyecto puede comunicarse.
Esta arquitectura explica por qué Git sigue funcionando sin conexión y por qué varios servidores pueden coexistir alrededor del mismo proyecto.
Explorar y comprender el historial
Git permite comparar versiones, recorrer los commits y recuperar el origen de una modificación.
Diff, log, show o blame responden a diferentes preguntas:
- ¿qué ha cambiado?
- ¿cuándo?
- ¿en qué commit?
- ¿por qué existe esta línea?
El verdadero interés no es encontrar un culpable.
Es recuperar la intención detrás de un cambio que ha sobrevivido más tiempo que su explicación.
Herramientas más especializadas como bisect pueden también ayudar a identificar el momento en que apareció una regresión.
Poner el trabajo temporalmente a un lado
Mecanismos como stash o worktree responden a una realidad muy ordinaria: el desarrollo no respeta siempre el orden previsto.
Una tarea puede ser interrumpida por una corrección urgente.
Un proyecto puede necesitar varias branches abiertas simultáneamente.
Estas herramientas no son necesarias para comprender Git.
Muestran sobre todo que el sistema fue diseñado para manipular varios estados de trabajo sin tener que copiar manualmente carpetas.
Tags, hooks y extensiones del workflow
Los tags sirven notamment para identificar commits importantes o versiones.
Los hooks permiten disparar scripts en diferentes etapas.
Git puede también integrarse con herramientas de CI, IDE, agentes y numerosas automatizaciones.
Estas funciones amplían su papel.
No cambian su identidad fundamental:
Git conserva y hace circular el historial del proyecto.
Casos de uso
Experimentar sin miedo
Una branch permite intentar una refundición importante conservando un camino estable hacia el estado anterior.
Recuperar el origen de un bug
El historial ayuda a identificar cuándo apareció un comportamiento y qué modificaciones lo acompañaban.
Trabajar solo de forma ordenada
Git sigue siendo útil incluso sin equipo.
Da una memoria al proyecto y evita la multiplicación de carpetas final, final2 y final_definitivo.
Colaborar
Varias personas pueden trabajar en branches diferentes y después intercambiar y reunir sus modificaciones.
Versionar documentación o configuración
Git no está reservado al código.
Todo conjunto de archivos textuales cuya evolución deba seguirse puede beneficiarse de su historial.
Preparar releases
Tags e historial permiten identificar claramente los estados correspondientes a versiones distribuidas.
Trabajar en varias branches simultáneamente
Los worktrees pueden aislar varios espacios de trabajo sin duplicar enteramente el repositorio.
Opinión PANACHES
Su verdadera fuerza no es GitHub
Git se descubre a menudo a través de GitHub.
Su idea más importante sigue siendo independiente de cualquier plataforma.
Esta independencia da al proyecto una memoria que puede cambiar de servidor sin cambiar de sistema de versionado.
En un mundo lleno de servicios cloud y suscripciones, esta separación sigue siendo extremadamente preciosa.
Git transforma la experimentación
La posibilidad de volver a un estado conocido reduce el coste psicológico de una modificación importante.
Se puede intentar más porque el pasado ya no se destruye en cada guardado.
Git se vuelve así una red de seguridad para la creación técnica.
No decide el workflow
Git proporciona commits, branches y mecanismos de fusión.
No impone una sola manera de utilizarlos.
Un equipo puede preferir branches largas, cortas, trunk-based development u otras convenciones.
La técnica sigue siendo la misma.
La organización pertenece al proyecto.
La curva de aprendizaje viene sobre todo del modelo mental
Git distingue lo que se encuentra en el directorio de trabajo, lo que está preparado para el próximo commit, lo que ya pertenece al historial local y lo que existe en un remote.
Estos estados explican gran parte de los mensajes que parecen misteriosos al principio.
Las dificultades no vienen por tanto solo de los comandos.
Vienen del hecho de que Git posee varias capas de realidad al mismo tiempo.
Una vez comprendidos commits, staging, branches y remotes, muchas operaciones dejan de parecer arbitrarias.
La línea de comandos no es una religión.
Las interfaces gráficas vuelven las branches, los diffs y los commits mucho más visibles.
Pueden ser mejores para ciertas tareas.
Comprender algunos conceptos fundamentales sigue siendo sin embargo útil cuando algo sale del workflow previsto.
El objetivo no es memorizar doscientos comandos.
Es saber qué está realmente modificando la herramienta.
El texto sigue siendo su terreno natural
Git es extremadamente eficaz para comparar archivos textuales.
Los archivos binarios grandes, medios pesados o assets 3D necesitan más estrategia.
Git LFS puede ayudar en ciertos casos.
Sistemas especializados pueden ser más adecuados para producciones artísticas muy pesadas.
Puntos de atención
- Git no es una copia de seguridad completa por sí solo: un repositorio local único puede desaparecer con su disco.
- Los archivos no seguidos no forman parte del historial.
- Los secrets nunca deben commitearse, incluso en un repositorio privado.
- Reescribir el historial compartido puede perturbar a los otros colaboradores.
- Los conflictos no son errores de Git: señalan que es necesaria una decisión humana.
- Los archivos binarios grandes están mal adaptados al almacenamiento Git clásico.
- Git LFS añade su propia infraestructura y debe pensarse desde el principio para los grandes assets.
- Las convenciones de branches y commits deben permanecer proporcionadas al proyecto.
- Un historial útil depende también de mensajes de commit comprensibles.
- Las interfaces gráficas facilitan Git sin eliminar el interés de comprender sus conceptos.
- Git es open source, pero eso no determina la licencia de los proyectos versionados con él.