Qué es Git y por qué lo necesita todo desarrollador

Git es un sistema de control de versiones

Git es un programa que registra el historial de cambios de los archivos de un proyecto. Cada vez que usted fija el estado del código, Git guarda una instantánea (commit) con su autor, fecha y descripción. Puede volver a cualquier instantánea, compararla con la actual y averiguar quién cambió una línea concreta y por qué.

Si alguna vez ha guardado carpetas como «proyecto_v2», «proyecto_final» y «proyecto_final_AHORA_SÍ», ya ha hecho control de versiones, solo que a mano. Git hace lo mismo de forma automática, compacta y sin miedo a perder nada. Por eso, cuando los desarrolladores hablan de qué es Git, no se refieren solo a un programa, sino a una herramienta de trabajo básica, tan imprescindible como el editor de código.

En qué se diferencia Git de una «carpeta de copias» o de la nube

Un disco en la nube guarda la última versión del archivo y, en el mejor de los casos, algunas copias automáticas. Git guarda un historial con sentido: usted decide cuándo fijar los cambios y escribe qué se ha hecho exactamente. Además, Git sabe hacer cosas que ningún disco en la nube puede:

• llevar varias líneas de desarrollo a la vez (ramas) y fusionarlas;
• mostrar la diferencia línea a línea entre versiones (git diff);
• combinar los cambios de distintas personas en los mismos archivos;
• encontrar el commit a partir del cual apareció un error (git bisect);
• trabajar sin conexión: todo el historial está en su equipo.

Qué significa Git: el origen del nombre

Git no tiene un significado oficial: no es un acrónimo. Linus Torvalds le puso el nombre a su estilo: en la jerga británica, git es «un tipo desagradable y testarudo». El propio Torvalds bromeaba con que bautiza todos sus proyectos con su nombre. Traducido literalmente, git vendría a ser algo así como «imbécil» o «cabezota».

En el primer README del proyecto, el autor propuso varias interpretaciones en broma: por ejemplo, «global information tracker» cuando todo funciona, y una versión malsonante cuando algo se rompe. Así que si en una entrevista le preguntan qué significan las siglas de Git, la respuesta correcta es: nada, es una palabra, no un acrónimo.

En español se escribe «Git» y se pronuncia con g dura, como en «guitarra»: /git/, no «yit».

De dónde salió Git

Hasta 2005, los desarrolladores del kernel de Linux usaban el sistema propietario BitKeeper. Cuando se retiró la licencia gratuita para la comunidad, Torvalds escribió su propio sistema en pocas semanas. Los requisitos eran exigentes: velocidad en un proyecto enorme, trabajo totalmente distribuido, protección fiable del historial frente a la corrupción y manejo cómodo de miles de ramas paralelas.

Poco después, Junio Hamano asumió el mantenimiento del proyecto, y sigue siendo el maintainer de Git hasta hoy. Actualmente Git es software libre con licencia GPLv2, y sobre él funcionan GitHub, GitLab, Bitbucket, Gitea y muchas plataformas corporativas.

Git como sistema: cómo funciona por dentro

Para que Git deje de parecer un conjunto de comandos mágicos, conviene entender tres ideas. Explican casi todo el comportamiento del sistema.

1. Instantáneas, no diferencias

Muchos sistemas antiguos guardaban los cambios como un conjunto de parches sobre los archivos. Git piensa en instantáneas: cada commit es el estado completo del proyecto en el momento de fijarlo. Para no desperdiciar espacio, los archivos que no han cambiado no se copian: el commit simplemente apunta al objeto ya guardado. Al empaquetar el repositorio, Git además comprime los objetos parecidos, así que el historial incluso de un proyecto grande ocupa poco.

2. Todo se identifica por un hash

Cada objeto de Git —el contenido de un archivo (blob), la estructura de una carpeta (tree), un commit (commit)— recibe un identificador calculado a partir de su contenido. Históricamente es SHA-1 (40 caracteres hexadecimales); en las versiones recientes se puede crear un repositorio con SHA-256. Es imposible modificar un commit antiguo sin que se note: cambiaría su hash y los de todos los commits posteriores.

$ git log --oneline -3
a3f9c21 Añadir formulario de inicio de sesión
7b02e4d Corregir la validación del email
1c8d5f0 Primer commit

Las cadenas cortas de la izquierda son los hashes abreviados de los commits. Con ellos puede referirse a cualquier versión: git show 7b02e4d.

3. Los tres estados de los archivos

Es la base de Git y sale en casi todas las entrevistas. Un archivo del proyecto puede estar en una de tres zonas:

El índice es lo que distingue a Git de muchos otros sistemas. Permite incluir en un commit solo una parte de los cambios: por ejemplo, la corrección de un bug por un lado y el renombrado de variables por otro. Así el historial resulta legible.

Sistema distribuido: por qué cada uno tiene una copia completa

Git es un sistema de control de versiones distribuido (DVCS). Al clonar, no recibe solo los últimos archivos, sino todo el historial del proyecto. La mayoría de las operaciones —commit, ver el historial, crear una rama, comparar— se ejecutan en local y al instante, sin servidor.

En este modelo, un servidor como GitHub es simplemente otra copia del repositorio que el equipo ha acordado tratar como principal. Si no está disponible, el trabajo no se detiene: usted sigue haciendo commits y enviará los cambios más tarde con git push. Si el servidor se pierde por completo, el historial se puede recuperar desde cualquier clon.

Git y GitHub no son lo mismo

Es una confusión habitual entre principiantes. Git es un programa que se ejecuta en su ordenador. GitHub es un servicio web donde se alojan repositorios Git y que ofrece herramientas para el trabajo en equipo: pull requests, code review, issues, CI. GitLab y Bitbucket son servicios similares.

Puede usar Git sin GitHub en absoluto, por ejemplo para notas personales o un proyecto local. En cambio, GitHub sin Git no tiene sentido: está construido en torno a sus repositorios.

Conceptos básicos de Git: el ciclo de trabajo mínimo

Así es el trabajo diario. Estos pocos comandos cubren la mayor parte de lo que un desarrollador hace cada día.

# crear un repositorio en la carpeta actual
git init

# ver qué ha cambiado
git status

# añadir archivos al índice
git add index.html style.css

# fijar la instantánea
git commit -m "Maquetar la página principal"

# ver el historial
git log --oneline

# crear una rama y cambiarse a ella
git switch -c feature/login

# fusionar la rama en la principal
git switch main
git merge feature/login

# enviar los cambios al servidor
git push origin main

El comando git switch apareció en Git 2.23 como sustituto más claro de parte de las funciones de git checkout. En instrucciones antiguas verá git checkout -b feature/login, que hace exactamente lo mismo.

Qué ocurre al hacer git commit

Git toma el contenido del índice, guarda cada archivo como blob, construye objetos tree para las carpetas y crea un objeto commit. En el commit se registran: la referencia al árbol, la referencia al commit padre (o a dos, tras una fusión), el autor, el committer y el mensaje. Después, el puntero de la rama actual avanza al nuevo commit. Una rama en Git es literalmente un archivo con el hash del último commit, por eso las ramas se crean en milisegundos.

Para qué sirve Git: razones prácticas

Puede experimentar sin miedo

Cualquier cambio es reversible. ¿Ha roto el código? git restore archivo devuelve la última versión confirmada. ¿El commit fallido ya está en el historial? git revert crea un commit inverso sin reescribir el historial compartido. Esto cambia la forma de trabajar: se atreve a probar más porque deshacer cuesta segundos.

Trabajo en equipo sin caos

Cada desarrollador trabaja en su rama y no estorba a los demás. Cuando la tarea está lista, los cambios pasan revisión y se fusionan en la rama principal. Si dos personas han tocado el mismo fragmento, Git muestra un conflicto y le deja resolverlo de forma consciente, en lugar de sobrescribir en silencio el trabajo ajeno.

El historial como documentación

Los buenos mensajes de commit responden a la pregunta «por qué el código es así». El comando git blame archivo muestra quién cambió por última vez cada línea y en qué commit, y git log -p archivo, toda la evolución del archivo. Un año después, esto ahorra horas de investigación.

Lo exigen las empresas

Saber Git aparece prácticamente en todas las ofertas de desarrollador, tester, ingeniero DevOps o analista de datos. En las entrevistas no se evalúan comandos memorizados, sino la comprensión: en qué se diferencia merge de rebase, qué es el índice, cómo deshacer un commit, cómo resolver un conflicto. Y un perfil de GitHub con un historial de commits cuidado funciona como portfolio.

Quién más necesita Git

Git resulta útil en cualquier lugar donde haya archivos de texto y el historial importe: redactores técnicos (documentación en Markdown), maquetadores, analistas (scripts SQL, notebooks), administradores de sistemas (configuraciones de servidores, infraestructura como código). Para archivos binarios grandes —vídeo, PSD, datasets— se usa la extensión Git LFS, porque Git en sí está optimizado para texto.

Pro Git, el mejor libro sobre Git

Si quiere profundizar, empiece por el libro «Pro Git» de Scott Chacon y Ben Straub. Es gratuito, se distribuye con licencia abierta y está publicado en la web oficial git-scm.com, en la sección Book, también con traducción al español. Es el famoso «pro git» que tanta gente busca: un manual completo desde lo básico hasta el funcionamiento interno.

Cómo sacarle partido:

• capítulos 1–3 (introducción, fundamentos, ramificaciones): el mínimo imprescindible; repita los comandos en la terminal;
• el capítulo sobre repositorios remotos y GitHub: cuando empiece a trabajar en equipo;
• el capítulo «Los entresijos internos de Git»: cuando quiera entender de verdad cómo funcionan los objetos y las referencias.

El segundo apoyo oficial es la ayuda integrada: git help commit o git commit --help abren la documentación completa del comando, y git commit -h muestra un resumen breve de las opciones.

Errores de concepto típicos de los principiantes

• «Git guarda los archivos automáticamente». No: mientras no haga un commit, los cambios solo existen en el directorio de trabajo.
• «El commit llega directamente a GitHub». El commit es local. Solo llega al servidor después de git push.
• «git add es para archivos nuevos». git add también añade al índice los cambios de archivos ya rastreados.
• «Lo borrado del historial no se puede recuperar». Casi siempre se puede: git reflog guarda los movimientos de los punteros y el commit «perdido» se encuentra por su hash.
• «Las ramas son copias del proyecto». Una rama es un puntero ligero a un commit, no un duplicado de los archivos.

Por dónde empezar a aprender

1. Instale Git y compruebe la versión: git --version.
2. Configure su nombre y correo: git config --global user.name y user.email.
3. Cree un repositorio de prueba, haga 5–10 commits y revise git log y git diff.
4. Practique con ramas: créelas, fusiónelas, provoque un conflicto a propósito y resuélvalo.
5. Cree una cuenta en GitHub, suba allí el repositorio y abra su primer pull request.

Este orden da resultados más rápido que leer manuales de principio a fin: ve al instante cómo cada comando cambia el estado del repositorio.

Conclusión

Git es un sistema de control de versiones distribuido que guarda el historial del proyecto en instantáneas, lo protege con hashes y permite al equipo trabajar en paralelo con ramas. El nombre no tiene un significado oficial, y en la práctica, qué es Git se resume en una herramienta obligatoria para cualquier desarrollador. Domine el ciclo add — commit — push, entienda las tres zonas de los archivos y las ramas, y después profundice con el libro Pro Git. Todo esto, paso a paso, desde el primer commit hasta el pull request, se trabaja en la práctica en el curso de Git.