Git

Presentación

Modificas un archivo.

Funciona.

Modificas otros tres.

Ya no funciona.

Y de repente aparece esa pregunta maravillosamente desagradable:

«¿Qué he cambiado desde el momento en que todo seguía funcionando?»

Git existe precisamente para que esa pregunta tenga respuesta.

Un proyecto ya no es solamente su estado actual

Una carpeta clásica muestra lo que existe ahora.

Git añade otra dimensión: lo que existía antes.

En cada etapa importante, se puede registrar un estado del proyecto en un commit. Estos commits forman progresivamente un historial que se puede consultar, comparar, recorrer o utilizar para recuperar una versión anterior.

El proyecto deja así de ser simplemente un conjunto de archivos.

Se convierte en una sucesión de estados conectados entre sí.

Esta idea es la que convierte a Git en un sistema de control de versiones.

Pero todavía explica solo una parte de su interés.

Creado para un proyecto que realmente no podía permitirse ser simple

Git nació en 2005 alrededor del desarrollo del núcleo Linux.

Tras la ruptura entre la comunidad Linux y BitKeeper, la herramienta propietaria utilizada hasta entonces para gestionar las versiones del núcleo, Linus Torvalds comenzó a desarrollar un nuevo sistema.

Los objetivos iniciales marcan bastante bien el tono:

velocidad, diseño relativamente simple, gestión masiva de ramas paralelas, funcionamiento completamente distribuido y capacidad para seguir un proyecto tan inmenso como el núcleo Linux.

Git está actualmente mantenido por Junio C Hamano, con las contribuciones de numerosos desarrolladores.

El contexto histórico explica muchas de sus decisiones.

Git no fue concebido como una pequeña función de «historial» añadida a un editor.

Fue pensado para permitir que enormes cantidades de cambios diferentes circularan entre muchas personas sin exigir que un servidor central poseyera la única versión del proyecto.

Distribuido significa realmente distribuido

Probablemente sea la noción más importante para comprender Git.

Cuando se clona un repositorio Git, no se recuperan únicamente los archivos visibles del proyecto.

También se recupera su historial.

Los commits.

Las ramas accesibles.

Los objetos necesarios para el repositorio.

La máquina local posee, por tanto, una verdadera copia del repository.

Se pueden crear commits.

Explorar el historial.

Crear ramas.

Comparar versiones.

Volver atrás sobre determinados cambios.

Y realizar gran parte de este trabajo sin conexión a Internet.

El servidor remoto interviene cuando queremos intercambiar esos cambios.

Esta distinción parece sutil hasta el día en que comprendemos que es precisamente lo que separa Git de GitHub.

Git sabe versionar tu proyecto. GitHub sabe alojar un repositorio Git y rodearlo de servicios. No son lo mismo.

Git puede funcionar con GitHub.

Con GitLab.

Con Codeberg.

Con Gitea.

Con un servidor personal.

Con otro ordenador accesible mediante SSH.

O simplemente sin ningún servidor remoto.

Gratuito, open source y todavía muy vivo

Git se publica bajo la GNU General Public License version 2.0.

Es gratuito y open source.

El proyecto continúa evolucionando activamente: en el momento de esta verificación, 7 de agosto de 2026, la última versión fuente estable publicada es Git 2.55.0, lanzada el 29 de junio de 2026.

Y alrededor de su núcleo en línea de comandos se ha construido un ecosistema inmenso.

Git está directamente integrado en numerosos IDE y editores.

Alimenta interfaces gráficas.

Sirve de base a forges de software.

Se integra en pipelines CI/CD.

Es utilizado por herramientas de desarrollo, agentes de IA y sistemas de automatización.

Sin embargo, el programa central sigue siendo notablemente discreto.

A menudo utilizamos Git durante todo el día sin mirar Git directamente.

Funcionalidades

Commit: dar un nombre a un momento del proyecto

El commit es uno de los componentes esenciales de Git.

Se modifican archivos.

Se seleccionan los cambios que queremos registrar.

Después se crea un commit acompañado de un mensaje.

Ese commit se convierte en un punto identificable dentro de la historia del proyecto.

Esto permite responder después a preguntas muy concretas:

¿Cuándo apareció esta modificación?

¿Quién la introdujo?

¿Qué archivos cambiaron?

¿Cómo era el proyecto antes?

¿Qué diferencia existe entre dos versiones?

Un buen historial Git no conserva únicamente código.

Conserva una parte de la memoria del desarrollo.

El staging: elegir qué historia contamos

Git introduce entre los archivos modificados y el commit una zona llamada index o staging area.

Al principio, esta etapa suele provocar una sensación bastante familiar:

«¿Por qué tengo que ejecutar todavía git add si Git ve perfectamente que el archivo ha cambiado?»

Porque Git permite elegir qué modificaciones deben formar parte del siguiente commit.

Puedes haber corregido un bug, modificado una documentación y empezado un experimento durante la misma sesión.

Nada te obliga a convertir todo eso en un único commit llamado:

cambios varios

El staging permite reconstruir unidades más coherentes.

Es una pequeña fricción.

Pero también es uno de los lugares donde Git empieza a transformar una sucesión de gestos desordenados en un historial legible.

Ramas: experimentar sin borrar el camino principal

Una rama permite continuar una línea de desarrollo separada.

Se puede crear una rama para:

• desarrollar una funcionalidad;
• corregir un bug;
• experimentar con una arquitectura;
• preparar una release;
• trabajar sin alterar la rama principal.

Las ramas de Git son ligeras porque se basan esencialmente en referencias hacia los commits.

Esto favorece un workflow en el que crear una rama no es una operación excepcional.

Es un gesto cotidiano.

Puedes partir de main, crear feature/export-pdf, trabajar en ella y después fusionar los cambios cuando la funcionalidad esté lista.

El proyecto puede explorar así varios futuros antes de decidir cuáles merecen incorporarse a su historia principal.

Merge y rebase: dos maneras de reunir los caminos

Dos ramas han divergido.

Ahora hay que reunirlas.

Git ofrece varias estrategias, entre ellas dos especialmente conocidas.

Ninguna es universalmente «mejor».

El merge suele hacer más visible la manera en que varias líneas de trabajo se encontraron.

El rebase puede producir una historia más limpia y fácil de leer.

Pero reescribe los commits afectados.

Ese detalle importa mucho cuando ya han sido compartidos.

Git ofrece potencia.

Y eso significa que, en ocasiones, hay que saber exactamente qué parte del pasado estamos remodelando.

Remotes: conectar historias separadas

Un repositorio local puede conocer uno o varios repositorios remotos llamados remotes.

El más habitual se llama origin.

Con ellos aparecen algunos comandos fundamentales:

fetch recupera nuevas referencias y datos remotos sin integrarlos directamente en el trabajo actual.

pull recupera e integra después los cambios según la configuración utilizada.

push envía los commits locales hacia un repositorio remoto.

Este mecanismo explica por qué Git no necesita ninguna plataforma concreta.

El remote puede apuntar a distintos servidores o servicios compatibles.

GitHub es una opción.

GitLab es otra.

Un servidor SSH casero también.

El protocolo de colaboración y la plataforma que lo aloja siguen siendo dos capas distintas.

Diff, log y blame: interrogar al pasado

Git dispone de varias herramientas para explorar el historial.

git diff muestra las diferencias entre distintos estados.

git log permite recorrer los commits.

git show inspecciona un objeto o un commit.

git blame indica de qué commits proceden las distintas líneas de un archivo.

El nombre «blame» — literalmente culpar — posee una elegancia social bastante particular.

En la práctica, la herramienta sirve sobre todo para remontarse hasta el contexto de una modificación.

¿Por qué existe esta condición tan extraña?

¿Quién la añadió?

¿En qué commit?

¿Qué problema se intentaba resolver en ese momento?

El verdadero interés no es encontrar un culpable.

Es recuperar la intención detrás de una línea que ha sobrevivido más tiempo que su explicación.

Stash: guardar el caos en una caja durante cinco minutos

Estás trabajando en una funcionalidad.

No está terminada.

Pero tienes que cambiar de rama inmediatamente.

git stash permite apartar temporalmente el estado actual de los archivos seguidos y recuperar un espacio de trabajo limpio.

Después se puede volver a la tarea anterior y restaurar las modificaciones.

Es una función relativamente sencilla.

Pero responde a una realidad muy humana del desarrollo:

el mundo no respeta absolutamente el orden en el que habíamos previsto terminar las cosas.

Worktree: trabajar sobre varias ramas al mismo tiempo

Los worktrees permiten asociar varios directorios de trabajo al mismo repositorio.

Se puede mantener la rama principal abierta en una carpeta y trabajar simultáneamente sobre otra rama en otro lugar.

Es especialmente práctico cuando un desarrollo largo debe permanecer intacto mientras aparece una corrección urgente.

Esta función también adquiere una nueva importancia con las herramientas de desarrollo agentic.

Varios agentes pueden trabajar en worktrees diferentes en lugar de pelearse por modificar el mismo espacio de trabajo.

Una vieja función de Git se vuelve de repente muy moderna.

Tags, firmas, hooks y herramientas avanzadas

Git puede ir mucho más lejos.

Los tags permiten identificar determinados commits importantes, a menudo versiones.

Las firmas pueden ayudar a verificar el origen de ciertos commits o tags.

Los hooks ejecutan scripts en distintas etapas del workflow.

Los submódulos permiten referenciar otro repositorio dentro de un proyecto.

bisect puede buscar automáticamente el commit que introdujo una regresión mediante una búsqueda binaria.

reflog conserva referencias útiles para recuperar determinadas operaciones locales incluso después de manipulaciones que parecían irreversibles.

Git tiene esta cualidad extraña:

puedes utilizarlo durante años con una decena de comandos.

Y descubrir después que todavía escondía otro sótano entero.

Casos de uso

Dejar de tener miedo a probar

Quieres reorganizar una parte importante de una aplicación.

La idea parece buena.

Lo que, en programación, a veces es precisamente el momento en el que conviene empezar a preocuparse.

Crear una rama permite probar.

Si el enfoque funciona, podrá integrarse.

Si se convierte en un pantano arquitectónico, la rama simplemente puede abandonarse.

Git transforma así el historial en una red de seguridad para la experimentación.

Nos atrevemos más cuando volver atrás no significa reconstruir manualmente lo que teníamos ayer por la mañana.

Encontrar cuándo apareció un bug

Una funcionalidad funciona en una versión antigua.

Ahora ya no.

Entre ambas: cincuenta commits.

Por supuesto, podemos empezar a leer los cincuenta.

O utilizar Git para comparar el historial y, en algunos casos, git bisect para reducir progresivamente el intervalo hasta localizar el commit problemático.

El control de versiones deja entonces de ser una simple copia de seguridad.

Se convierte en una herramienta de investigación.

Trabajar solo sin considerar Git «una cosa para equipos»

Un proyecto personal quizá no tenga ningún colaborador.

Git sigue siendo extremadamente útil.

Registrar el historial de cambios.

Probar una idea en una rama.

Crear versiones.

Recuperar una implementación antigua.

Comparar dos enfoques.

Sincronizar el proyecto entre varias máquinas.

Publicar más tarde el repository en una forge.

El primer colaborador de Git suele ser tú mismo dentro de tres meses, cuando hayas olvidado completamente por qué escribiste ese código tan extraño.

Esa persona merece un mínimo de documentación.

Colaborar sin compartir la misma carpeta

Alice clona un repositorio.

Bob clona el mismo repositorio.

Cada uno posee su propio historial local y puede crear sus propios commits.

Los cambios pueden intercambiarse después mediante un repositorio remoto.

Git no exige que todo el mundo modifique una única copia central en todo momento.

Esta arquitectura distribuida permite workflows muy diferentes: equipo centralizado alrededor de un servidor, forks públicos, intercambio de patches, varios remotes o infraestructuras completamente privadas.

Git proporciona la mecánica.

La comunidad o la empresa decide la organización.

Versionar algo más que código

Git está principalmente asociado al desarrollo de software.

Pero técnicamente sigue archivos.

Por tanto, también puede utilizarse para:

documentación Markdown, archivos de configuración, scripts, notas técnicas, sitios estáticos, documentos de texto o datos estructurados.

Resulta mucho menos agradable con archivos binarios grandes que cambian con frecuencia — imágenes pesadas, vídeos, escenas 3D, archivos creativos voluminosos.

Existen extensiones y estrategias como Git LFS para algunos de estos casos.

Pero Git revela aquí su naturaleza profunda:

sobresale cuando los cambios pueden compararse y representarse eficazmente como una evolución de archivos.

Opinión de PANACHES

Git forma parte de esas herramientas cuya interfaz puede parecer más complicada que la idea que llevan dentro.

Y su idea es extraordinariamente simple:

no dejes que el estado actual de un proyecto borre su historia.

Todo lo demás deriva de ello.

Los commits dividen esa historia.

Las ramas permiten darle varias direcciones.

Los merges las reúnen.

Los remotes permiten que varias copias se comuniquen.

El diff muestra qué ha cambiado.

El log cuenta cómo hemos llegado hasta aquí.

Su verdadera fuerza no es GitHub

Probablemente sea el punto más importante después de nuestra ficha sobre GitHub.

Git mantiene hoy una relación casi inseparable con las grandes forges.

A menudo aprendemos ambos al mismo tiempo.

Creamos una cuenta de GitHub.

Clonamos.

Hacemos commit.

Hacemos push.

Y las fronteras empiezan a difuminarse.

Sin embargo, una de las cualidades más poderosas de Git es precisamente que no pertenece a GitHub.

Tu historial existe localmente.

Puedes cambiar de remote.

Añadir un segundo servidor.

Migrar a GitLab.

Utilizar Codeberg.

Alojar tu propio repositorio.

Trabajar sin conexión.

Git conserva la capa fundamental independiente de la plataforma.

En un mundo donde las herramientas se convierten fácilmente en suscripciones, clouds y cuentas obligatorias, esta separación resulta casi refrescante.

Git no decide tu workflow

Git Flow.

GitHub Flow.

Trunk-based development.

Ramas largas.

Ramas cortas.

Rebase sistemático.

Merge commits.

Squash merge.

Git puede participar en muchas metodologías diferentes.

Proporciona primitivas en lugar de una organización universal.

Es una fortaleza.

Pero también una fuente de debates fascinantes capaces de transformar una reunión técnica de quince minutos en una excavación arqueológica de convicciones personales.

Una curva de aprendizaje muy real

Git es potente porque su modelo posee una verdadera profundidad.

Y esa profundidad exige esfuerzo.

Working tree.

Index.

HEAD.

Ramas locales.

Ramas remotas.

Remotes.

Merge.

Rebase.

Detached HEAD.

Reset.

Restore.

Reflog.

En algún momento, el principiante solo quería guardar sus cambios y termina mirando un grafo preguntándose en qué momento exacto abandonó el mundo real.

Las interfaces gráficas y las integraciones con IDE facilitan enormemente las operaciones habituales.

Pero comprender algunos conceptos internos sigue siendo extremadamente valioso.

No para recitar comandos.

Para saber qué está modificando realmente la herramienta.

¿Hay que aprender Git desde la línea de comandos?

No exclusivamente.

Git posee un ecosistema inmenso de interfaces: integraciones en VS Code y los IDE de JetBrains, GitHub Desktop, GitKraken, Sourcetree, Fork, Tower y muchas otras.

Una GUI puede hacer que las ramas, diffs y commits sean mucho más visibles.

Incluso puede ser mejor para determinadas tareas.

Pero conocer al menos los comandos fundamentales sigue siendo útil:

status, add, commit, log, diff, branch, switch, merge, fetch, pull, push.

No porque el terminal sea más «real».

Simplemente porque la línea de comandos expone una capa común que casi todas las herramientas gráficas utilizan por debajo o reproducen conceptualmente.

¿Cuándo conviene preferir otra cosa?

Git domina hoy su ámbito de tal manera que una alternativa suele tener que responder a una necesidad bastante específica.

Mercurial conserva una filosofía diferente de control de versiones distribuido y suele considerarse más coherente en determinadas operaciones.

Fossil lleva mucho más lejos la idea de una herramienta todo en uno al integrar versionado, bug tracking, wiki e interfaz web.

Apache Subversion mantiene un modelo centralizado que todavía puede tener sentido en ciertos entornos o workflows existentes.

También están apareciendo enfoques más recientes que exploran otras formas de representar los cambios y las ramas.

Pero para la mayoría de los proyectos de software actuales, elegir algo distinto de Git rara vez es una decisión neutra.

No necesariamente porque Git sea perfecto.

Sino porque todo el ecosistema que existe a su alrededor es gigantesco.

Puntos de atención

Git no es por sí solo una estrategia completa de backup

Git protege admirablemente el historial seguido por el repository.

Pero si la única copia del repositorio se encuentra en el SSD que acaba de morir, su arquitectura distribuida no va a invocar mágicamente un segundo ordenador.

Para beneficiarse realmente de esa distribución, hacen falta varias copias: remote distante, otra máquina, servidor o sistema de backup.

Un commit local es una excelente versión.

Todavía no es una estrategia completa de copia de seguridad.

Los archivos no seguidos no forman parte de la historia

Git no guarda automáticamente todo lo que se encuentra dentro de la carpeta.

Los archivos deben ser seguidos y sus cambios deben convertirse en commits.

Los elementos excluidos mediante .gitignore permanecen deliberadamente fuera del repository.

Esto resulta útil para cachés, builds, entornos virtuales o secretos locales.

Pero un archivo esencial que nunca haya sido añadido al repositorio puede desaparecer sin que Git tenga la menor idea de que existía.

Git recuerda muy bien.

Siempre que le hayamos pedido que mire.

Los secretos no deben convertirse en commits

Una contraseña o una clave API que haya sido incluida en un commit y después eliminada del archivo actual puede seguir existiendo en el historial Git.

Eliminar la línea en el siguiente commit no basta para hacer desaparecer el secreto de los commits anteriores.

El primer reflejo debe ser evitar que entre en el repositorio: variables de entorno, archivos ignorados, gestores de secretos.

Y cuando un secreto haya quedado realmente expuesto, normalmente hay que empezar por revocarlo o renovarlo.

Reescribir la historia no convierte una clave que ya ha sido copiada en un secreto otra vez.

Reescribir el historial es potente porque realmente reescribe el historial

Rebase interactivo.

Amend.

Reset.

Filter-repo.

Force push.

Git permite remodelar profundamente una serie de commits.

En una rama personal, esto puede producir un historial mucho más limpio.

En una rama ya compartida, también puede transformar la jornada de los compañeros en un ejercicio colectivo de resolución de divergencias.

Regla práctica:

cuanto más compartido está un commit, más conviene pensar antes de cambiar su identidad.

Git prefiere el texto a los grandes binarios

Git es extremadamente eficaz con código y archivos de texto.

Resulta mucho menos natural con archivos binarios grandes que se modifican frecuentemente.

Un vídeo de varios gigabytes.

Un archivo Photoshop pesado.

Una escena 3D.

Un proyecto lleno de assets binarios voluminosos.

El historial puede entonces volverse enorme y las diferencias difíciles o imposibles de explotar de manera tradicional.

Git LFS puede mover determinados archivos grandes fuera del almacenamiento Git tradicional manteniendo punteros dentro del repositorio.

Pero para producciones artísticas muy pesadas, otros sistemas de gestión de assets o versiones pueden ser más apropiados.

Los conflictos no son errores de Git

Dos ramas modifican la misma zona de un archivo de manera incompatible.

Git no siempre puede determinar qué versión representa la intención correcta.

Entonces señala un conflicto.

Es frustrante.

Pero no es realmente un fallo.

Git simplemente se niega a inventar la decisión humana.

Una buena herramienta de merge puede ayudar a visualizar ambos lados.

Después, el desarrollador debe comprender qué debe expresar realmente el resultado final.

En este caso concreto, la automatización conoce sus límites.

Y probablemente sea algo saludable.

Open source no significa ausencia de reglas alrededor del nombre

Git es efectivamente software libre y open source bajo GPLv2.

Sin embargo, el proyecto especifica que el nombre Git y sus logotipos están cubiertos por una política de marca destinada, entre otras cosas, a evitar confusiones.

La licencia del código y los derechos de marca son dos cuestiones distintas.

Se puede estudiar, modificar y redistribuir el software según las condiciones de su licencia.

Eso no concede automáticamente carta blanca para presentar cualquier producto derivado como si fuera el proyecto oficial de Git.

La línea de comandos puede parecer hostil porque expone toda la mecánica

Git tiene comandos que se parecen entre sí.

Algunos han evolucionado con los años.

Varios caminos pueden llevar a resultados similares.

Y determinadas operaciones se vuelven peligrosas cuando se utilizan sin comprender sus consecuencias.

Las interfaces modernas reducen buena parte de esta fricción.

Pero ocultar Git por completo también tiene un coste: cuando algo sale del workflow previsto, resulta difícil comprender qué ha ocurrido realmente.

El mejor compromiso probablemente no sea memorizar doscientos comandos.

Es comprender algunos conceptos sólidos:

commit, index, rama, HEAD, remote, merge e historial.

Una vez que estas piezas encajan, Git empieza a dejar de parecer magia negra.

Por fin.

La mayor parte del tiempo.

Git no sirve solamente para conservar lo que has creado. Conserva los caminos que te permitieron llegar hasta allí.