El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
HOME Mis cursos Finalizados
◄ Anterior
◄

¿Qué es Git?

Siguiente ►
►

Antes de escribir un solo comando, conviene entender qué problema viene a resolver Git y por qué se ha convertido en la herramienta estándar de la industria del software. Git es un sistema de control de versiones distribuido: un programa que registra la evolución de un conjunto de ficheros a lo largo del tiempo, permite volver a cualquier estado anterior y coordina el trabajo de varias personas sobre el mismo código sin que se pisen entre ellas. En esta lección veremos cómo se trabajaba antes de que existiera, de dónde salió Git, en qué se diferencia de los sistemas centralizados que le precedieron y por qué acabó imponiéndose. También conoceremos a Ana, Bruno y Carla, el equipo que nos acompañará durante todo el curso construyendo una aplicación llamada gestor-tareas.

Contenido

  1. El problema: cómo lo hacíamos antes
  2. Qué es un sistema de control de versiones
  3. Breve historia de Git
  4. Control de versiones centralizado frente a distribuido
  5. Por qué Git se impuso
  6. Qué no es Git
  7. Nuestro hilo conductor: gestor-tareas, Ana, Bruno y Carla

  1. El problema: cómo lo hacíamos antes

Cualquiera que haya trabajado con ficheros durante un tiempo ha inventado su propio sistema de control de versiones. Suele tener este aspecto:

Escritorio/
├── gestor-tareas/
├── gestor-tareas_copia/
├── gestor-tareas_v2/
├── gestor-tareas_v2_BUENO/
├── gestor-tareas_v2_BUENO_definitivo/
├── gestor-tareas_final_v2_BUENO.zip
├── gestor-tareas_final_ESTE_SI.zip
└── gestor-tareas_ana_revisado_bruno.zip

Este método funciona a medias durante unos días y falla estrepitosamente en cuanto el proyecto crece o entra una segunda persona. Estos son sus problemas concretos:

  • No se sabe qué cambió. Entre _v2 y _v2_BUENO puede haber una línea de diferencia o trescientas. Para averiguarlo hay que comparar carpeta contra carpeta a mano.
  • No se sabe por qué cambió. El nombre de la carpeta no explica la intención. Dentro de tres meses nadie recordará qué se arregló en _ESTE_SI.
  • No se sabe quién lo cambió. Si el .zip ha pasado por correo entre tres personas, la autoría se pierde.
  • Ocupa muchísimo espacio. Cada copia duplica el proyecto entero aunque solo haya cambiado un fichero.
  • Fusionar es un infierno. Si Ana toca estilos.css y Bruno toca el mismo fichero en su copia, unir los dos trabajos significa abrir ambos ficheros en paralelo y copiar líneas a mano.
  • No hay una única verdad. Cuando existen cinco carpetas "buenas", nadie sabe cuál se debe publicar.

Un sistema de control de versiones ataca exactamente estos seis puntos.

  1. Qué es un sistema de control de versiones

Un sistema de control de versiones (VCS, Version Control System) es un programa que:

  1. Guarda instantáneas (snapshots) del estado de un proyecto en momentos concretos que tú decides.
  2. Asocia a cada instantánea metadatos: quién la creó, cuándo y con qué mensaje explicativo.
  3. Permite recuperar cualquier instantánea anterior, comparar dos de ellas o ver la evolución de un fichero concreto.
  4. Permite trabajar en paralelo en líneas de desarrollo independientes y luego unirlas.

La diferencia clave con las carpetas _BUENO es que el historial deja de estar en los nombres de fichero y pasa a estar en una base de datos que el sistema gestiona por ti. En el disco solo hay una carpeta del proyecto; el historial completo vive escondido junto a ella.

Los VCS se suelen clasificar en tres generaciones:

Generación Ejemplos Idea central Limitación principal
Local RCS, SCCS Historial en el propio equipo, fichero a fichero Un solo usuario, sin colaboración
Centralizada (CVCS) CVS, Subversion (SVN), Perforce Un servidor único guarda el historial Dependencia total del servidor
Distribuida (DVCS) Git, Mercurial, Bazaar Cada copia contiene el historial completo Curva de aprendizaje mayor

Git pertenece a la tercera generación, y esa decisión de diseño explica casi todo lo demás.

  1. Breve historia de Git

El origen de Git está directamente ligado al desarrollo del kernel de Linux.

  • 1991–2002. Los parches del kernel se intercambiaban por correo electrónico en forma de ficheros de texto. Con miles de colaboradores, el sistema se volvió inmanejable.
  • 2002. El proyecto adoptó BitKeeper, una herramienta distribuida y propietaria cuya licencia permitía su uso gratuito a los desarrolladores del kernel.
  • 2005. Esa licencia gratuita se retiró tras un conflicto entre la empresa propietaria y parte de la comunidad. El kernel se quedó de golpe sin sistema de control de versiones.
  • Abril de 2005. Linus Torvalds empezó a escribir su propio sistema. Los requisitos que se marcó fueron explícitos y radicales:
    • Velocidad, porque el kernel es enorme y las operaciones cotidianas debían ser instantáneas.
    • Diseño sencillo en el fondo, aunque la interfaz fuera austera.
    • Soporte fuerte para desarrollo no lineal, es decir, miles de ramas en paralelo.
    • Completamente distribuido, sin servidor obligatorio.
    • Capacidad de manejar proyectos del tamaño del kernel sin degradarse.
    • Integridad garantizada: que fuera imposible corromper el historial sin que se notara.

El desarrollo fue vertiginoso: en pocas semanas Git ya alojaba su propio código y poco después el del kernel. En julio de 2005 Torvalds cedió el mantenimiento a Junio Hamano, que sigue siendo el mantenedor principal y bajo cuya dirección Git ganó la interfaz más amable que usamos hoy.

Sobre el nombre. "git" es una palabra del inglés británico coloquial que significa, aproximadamente, "individuo desagradable". Torvalds bromeó diciendo que tiene la costumbre de nombrar sus proyectos en su honor. En la documentación también se ofrecen otras lecturas retroactivas, como Global Information Tracker.

  1. Control de versiones centralizado frente a distribuido

Esta es la diferencia conceptual más importante de la lección.

El modelo centralizado (CVS, Subversion)

Existe un servidor que contiene el historial completo del proyecto. Los desarrolladores tienen en su equipo únicamente una copia de trabajo: los ficheros en su versión actual, sin historial. Para casi cualquier operación —ver el historial, crear una rama, confirmar un cambio, comparar con una versión antigua— hay que hablar con el servidor.

graph TD
    S[(Servidor central<br/>historial completo)]
    A["Ana<br/>copia de trabajo<br/>(sin historial)"]
    B["Bruno<br/>copia de trabajo<br/>(sin historial)"]
    C["Carla<br/>copia de trabajo<br/>(sin historial)"]
    A -->|commit / update| S
    B -->|commit / update| S
    C -->|commit / update| S

Consecuencias directas:

  • Si el servidor está caído o no hay red, no se puede trabajar más allá de editar ficheros.
  • Si el disco del servidor se pierde y no hay copia de seguridad, se pierde todo el historial.
  • Cada confirmación viaja por la red, así que las operaciones son lentas.

El modelo distribuido (Git)

Cada persona tiene un repositorio completo, con todo el historial desde la primera confirmación. El servidor compartido existe, pero es una conveniencia organizativa, no una necesidad técnica: es simplemente uno más de los repositorios, al que todos han acordado sincronizarse.

graph TD
    R[("Repositorio compartido<br/>historial completo")]
    A["Ana<br/>repositorio completo<br/>+ copia de trabajo"]
    B["Bruno<br/>repositorio completo<br/>+ copia de trabajo"]
    C["Carla<br/>repositorio completo<br/>+ copia de trabajo"]
    A <-->|push / fetch| R
    B <-->|push / fetch| R
    C <-->|push / fetch| R
    A <-.->|intercambio directo posible| B

Consecuencias directas:

  • Ana puede consultar el historial, confirmar cambios y crear ramas en un avión sin wifi.
  • Cada clon es una copia de seguridad del proyecto entero.
  • Bruno y Carla podrían intercambiar trabajo directamente entre sus equipos sin pasar por el servidor.

Tabla comparativa

Aspecto Centralizado (SVN / CVS) Distribuido (Git)
Dónde vive el historial Solo en el servidor En cada copia del repositorio
Trabajar sin red Prácticamente imposible Todo salvo sincronizar
Velocidad del historial Depende de la red Lectura de disco local
Coste de crear una rama Alto: copia en servidor, operación pesada Mínimo: un fichero con un identificador
Confirmar un cambio Publica para todo el mundo al instante Local; se publica cuando tú decides
Riesgo si cae el servidor Pérdida del historial si no hay copias Cualquier clon puede restaurarlo
Identificador de versión Número correlativo (1, 2, 3…) Hash criptográfico del contenido
Unidad de trabajo típica Fichero o directorio Proyecto completo (instantánea)
Permisos por carpeta Soportado de forma nativa No; se gestiona con repositorios o herramientas externas
Ficheros binarios grandes Se maneja razonablemente bien Requiere extensiones como Git LFS

Ninguna herramienta es perfecta: Subversion sigue siendo razonable para repositorios enormes de binarios con permisos finos por carpeta. Pero para desarrollo de software, el modelo distribuido ganó por goleada.

  1. Por qué Git se impuso

Git no era el único sistema distribuido: Mercurial y Bazaar aparecieron casi al mismo tiempo. Estas son las razones técnicas y de contexto que explican su dominio.

5.1 Velocidad

Casi todas las operaciones son locales. Ver el historial de app.js, comparar la versión actual con la de hace un mes o cambiar de rama son lecturas de disco, no peticiones de red. En proyectos donde SVN tardaba segundos, Git tarda milisegundos. Esa diferencia cambia la forma de trabajar: si consultar el historial es instantáneo, se consulta constantemente.

5.2 Ramas baratas

En Git, una rama es literalmente un fichero de 41 bytes que contiene el identificador de una confirmación. Crearla es instantáneo y no duplica nada. Esto convirtió una operación que en los sistemas centralizados era excepcional y temida en algo cotidiano: una rama por cada tarea, por cada corrección, por cada experimento. Lo veremos en profundidad en el módulo 3.

5.3 Trabajo offline

Como cada repositorio es completo, se puede confirmar, consultar el historial, crear ramas y fusionar sin conexión. La red solo hace falta para compartir el trabajo con los demás, y eso ocurre cuando tú lo decides, no en cada cambio.

5.4 Integridad garantizada

Todo en Git se identifica por un hash criptográfico calculado a partir de su contenido. Si un byte de un fichero antiguo se corrompe en el disco, el hash deja de coincidir y Git lo detecta. Además, cada confirmación incluye el identificador de la anterior, así que alterar un punto del historial invalida todos los posteriores. Es imposible modificar el pasado en silencio. El módulo 1 vuelve sobre esto con detalle en la lección El Modelo de Datos de Git.

5.5 El área de preparación

Git introduce una zona intermedia entre "he editado ficheros" y "he registrado un cambio en el historial", llamada área de preparación o staging area. Permite construir confirmaciones cuidadas, eligiendo exactamente qué partes del trabajo entran en cada una. La veremos en la lección Terminología Básica de Git.

5.6 El efecto GitHub

A la calidad técnica se sumó un factor social: el nacimiento de GitHub en 2008, que convirtió el intercambio de código en algo social y visible, y popularizó el flujo de fork y pull request. Más tarde llegaron GitLab, Bitbucket y otros. Hoy conocer Git es un requisito de entrada en prácticamente cualquier puesto técnico.

Resumen de las razones

Razón Qué te permite en la práctica
Velocidad Consultar y navegar el historial sin fricción
Ramas baratas Aislar cada tarea, experimentar sin miedo
Trabajo offline Ser productivo sin conexión, publicar después
Integridad Confiar en que el historial no se ha alterado
Área de preparación Confirmaciones limpias y con sentido
Ecosistema Integración con plataformas, CI y herramientas

  1. Qué no es Git

Aclarar los límites evita malentendidos frecuentes en los primeros días:

  • Git no es GitHub. Git es el programa que se instala en tu equipo. GitHub, GitLab o Bitbucket son servicios web que alojan repositorios Git y añaden funcionalidades propias (incidencias, revisiones, permisos). Puedes usar Git toda tu vida sin abrir una cuenta en ninguno.
  • Git no es una copia de seguridad automática. Solo guarda lo que tú le pides que guarde, cuando se lo pides.
  • Git no es un sistema de sincronización de carpetas. No se parece a Dropbox: nada se sincroniza solo, y esa es precisamente la ventaja.
  • Git no está pensado para ficheros binarios grandes. Vídeos, imágenes pesadas o modelos 3D inflan el repositorio porque no se comprimen bien entre versiones. Para eso existe Git LFS, que se trata en el módulo 10.
  • Git no es un gestor de despliegues, aunque casi todos los sistemas de despliegue modernos se apoyan en él.

  1. Nuestro hilo conductor: gestor-tareas, Ana, Bruno y Carla

Durante los diez módulos del curso seguiremos un único proyecto. Aprender Git con ejemplos sueltos genera conocimiento igualmente suelto; seguir un proyecto real de principio a fin permite entender por qué se usa cada comando en cada momento.

El proyecto

gestor-tareas es una pequeña aplicación web para gestionar listas de tareas. Empieza siendo una carpeta en el portátil de Ana con cuatro ficheros:

Fichero Contenido
index.html Estructura de la página: título, formulario y lista de tareas
estilos.css Aspecto visual
app.js Lógica: añadir, marcar y borrar tareas
README.md Descripción del proyecto e instrucciones

Este es el estado inicial, tal y como está hoy en el portátil de Ana. Todavía no hay ni rastro de Git: es solo una carpeta.

<!-- index.html -->
<!DOCTYPE html>
<html lang="es">
<head>
  <meta charset="UTF-8">
  <title>Gestor de Tareas</title>
  <link rel="stylesheet" href="estilos.css">
</head>
<body>
  <h1>Mis tareas</h1>
  <form id="nueva-tarea">
    <input type="text" id="texto" placeholder="¿Qué hay que hacer?">
    <button type="submit">Añadir</button>
  </form>
  <ul id="lista"></ul>
  <script src="app.js"></script>
</body>
</html>

Fíjate en la sencillez deliberada: una cabecera, un formulario con un campo de texto y un botón, y una lista vacía que se rellenará desde JavaScript. Todo el ejemplo cabe en una pantalla para que la atención se quede en Git y no en la aplicación.

// app.js
const formulario = document.getElementById('nueva-tarea');
const lista = document.getElementById('lista');

formulario.addEventListener('submit', function (evento) {
  evento.preventDefault();
  const texto = document.getElementById('texto').value;
  if (texto === '') return;
  const elemento = document.createElement('li');
  elemento.textContent = texto;
  lista.appendChild(elemento);
  formulario.reset();
});

Línea a línea: se obtienen las referencias al formulario y a la lista; se escucha el evento de envío; evento.preventDefault() impide que la página se recargue; si el campo está vacío no se hace nada; en caso contrario se crea un <li>, se le pone el texto, se añade a la lista y se vacía el formulario. Es intencionadamente básico: a lo largo del curso, Bruno y Carla lo irán ampliando y esos cambios serán el material de nuestros ejemplos.

El equipo

Persona Papel en el proyecto Qué aprenderemos con ella
Ana Arranca el proyecto y lo mantiene Crear el repositorio, primeras confirmaciones, configuración
Bruno Se incorpora en segundo lugar Clonar, trabajar en ramas, resolver conflictos
Carla Se incorpora la última Colaboración, revisiones de código, integración continua

El recorrido

graph LR
    M1["Módulos 1-2<br/>Ana sola<br/>carpeta local"] --> M2["Módulos 3-4<br/>Entra Bruno<br/>ramas y remoto"]
    M2 --> M3["Módulos 5-7<br/>Entra Carla<br/>rebase, revisiones, flujos"]
    M3 --> M4["Módulos 8-10<br/>Equipo consolidado<br/>buenas prácticas, CI, escala"]

La historia avanza en paralelo al temario: lo que en el módulo 2 es una carpeta con cuatro ficheros, en el módulo 10 será un repositorio compartido con ramas de release, revisiones de código e integración continua.

Errores Comunes y Consejos

  • Confundir Git con GitHub. Es el malentendido número uno. Repítelo mentalmente: Git es el programa local; GitHub es una web que aloja repositorios Git. Todo lo que haremos hasta el módulo 4 funciona sin conexión a internet y sin cuenta en ningún servicio.
  • Pensar que Git guarda diferencias entre versiones. Conceptualmente, Git guarda instantáneas completas del proyecto en cada confirmación (con una compresión muy eficiente por debajo, que reutiliza el contenido que no cambia). Este matiz, que veremos en la lección 01-04, explica por qué cambiar de rama es tan rápido.
  • Seguir usando carpetas _BUENO "por si acaso" cuando ya usas Git. Es señal de desconfianza en la herramienta, y suele desaparecer en cuanto se entiende el modelo de datos. Mientras tanto, no hace daño; pero el objetivo es dejar de necesitarlo.
  • Querer memorizar comandos antes de entender el modelo. Git tiene decenas de comandos y muchas opciones. Quien memoriza recetas se bloquea en cuanto algo se sale del guion; quien entiende el modelo deduce el comando. Dedica tiempo a las lecciones 01-03 y 01-04.
  • Consejo: instala Git aunque aún no vayas a usarlo. La siguiente lección lo cubre y así podrás experimentar en cuanto lleguemos al módulo 2.
  • Consejo: elige un proyecto propio como banco de pruebas. Además de seguir gestor-tareas, aplicar cada lección a algo tuyo consolida el aprendizaje mucho más rápido.

Ejercicios

Ejercicio 1: Diagnóstico del método artesanal

Imagina esta situación real. Ana envía por correo a Bruno un fichero gestor-tareas_v2.zip. Bruno modifica estilos.css y le devuelve gestor-tareas_v2_bruno.zip. Mientras tanto, Ana ha seguido trabajando y ha modificado estilos.css y app.js en su copia.

Enumera al menos cuatro problemas concretos que aparecen ahora, y para cada uno indica qué característica de un sistema de control de versiones lo resolvería.

Ejercicio 2: Centralizado o distribuido

Para cada una de estas cinco situaciones, indica si es posible en un sistema centralizado (SVN), en uno distribuido (Git), en ambos o en ninguno. Justifica brevemente:

  1. Consultar quién modificó por última vez la línea 12 de app.js sin conexión a internet.
  2. Recuperar el historial completo del proyecto después de que se incendie el servidor, si no hay copias de seguridad pero tres personas tienen su copia de trabajo.
  3. Confirmar un cambio sin que el resto del equipo lo vea todavía.
  4. Restringir el acceso de un usuario a una única subcarpeta del proyecto.
  5. Crear diez ramas de prueba en menos de un segundo.

Ejercicio 3: Argumentario para el equipo

Carla aún trabaja con carpetas comprimidas y no ve la necesidad de cambiar: "yo me organizo bien y nunca he perdido nada". Escribe un argumentario de cinco puntos, uno por cada beneficio de Git visto en la lección, redactado de forma que responda a esa objeción concreta (no basta con listar características: hay que conectarlas con su situación).

Soluciones

Solución al Ejercicio 1

Problemas que aparecen y su solución:

Problema Característica que lo resuelve
Hay dos versiones distintas de estilos.css y nadie sabe cuál es la buena Fusión asistida: el sistema combina automáticamente cambios en zonas distintas del fichero y avisa solo de los solapamientos reales
No se sabe qué cambió Bruno exactamente Comparación de versiones (diff): muestra línea a línea las diferencias
No se sabe por qué lo cambió Mensajes de confirmación: cada cambio lleva una explicación escrita por su autor
El trabajo de Ana en app.js puede perderse si se descomprime el .zip de Bruno encima Historial inmutable: nada se sobrescribe; todo estado confirmado se puede recuperar
No hay una versión oficial del proyecto Repositorio compartido con una rama principal acordada
Se han duplicado dos veces todos los ficheros para cambiar unas pocas líneas Almacenamiento eficiente: solo se guarda el contenido nuevo

Con cuatro de estos puntos bien argumentados el ejercicio está resuelto.

Solución al Ejercicio 2

  1. Solo distribuido. En Git el historial está en el disco local, así que se consulta sin red. En SVN esa consulta requiere hablar con el servidor.
  2. Solo distribuido. Las copias de trabajo de SVN no contienen historial: se recuperaría el último estado de los ficheros, pero el pasado se perdería. Cualquier clon de Git contiene el historial íntegro y basta para reconstruir el servidor.
  3. Solo distribuido. En SVN, confirmar (commit) publica en el servidor de inmediato. En Git, confirmar es local y publicar (push) es un segundo paso independiente.
  4. Solo centralizado (de forma nativa). SVN permite listas de control de acceso por ruta. Git no tiene permisos por carpeta dentro de un repositorio; se resuelve dividiendo en varios repositorios o con herramientas de la plataforma de alojamiento.
  5. Solo distribuido, en la práctica. SVN permite crear ramas, pero implica una operación en el servidor por cada una. En Git cada rama es un fichero diminuto y crear diez es instantáneo.

Solución al Ejercicio 3

Argumentario orientado a la objeción "yo me organizo bien":

  1. No se trata de ti, se trata del equipo. Tu orden personal no ayuda a Ana ni a Bruno cuando los tres tocáis app.js la misma tarde. Git fusiona automáticamente los cambios que no se solapan y solo pide intervención humana en el conflicto real.
  2. El historial responde preguntas que tú no puedes. "¿Por qué esta línea está aquí?" tiene respuesta inmediata seis meses después: quién la escribió, cuándo y con qué mensaje. Ninguna carpeta comprimida guarda esa información.
  3. Puedes experimentar sin miedo. Con ramas baratas, probar un rediseño completo de estilos.css cuesta un segundo y descartarlo, otro. Sin control de versiones, experimentar significa arriesgar lo que funciona.
  4. Es tu red de seguridad, no una carga. Nunca has perdido nada todavía. Un borrado accidental, un disco averiado o un cambio mal hecho a las once de la noche son cuestión de tiempo; cada clon del repositorio es una copia completa del proyecto.
  5. Es el idioma común de la profesión. Las revisiones de código, el despliegue automático y la integración continua se apoyan en Git. Quedarse fuera no es una preferencia personal: excluye del flujo de trabajo del resto del equipo.

Conclusión

Git existe porque el método artesanal de las carpetas _v2_BUENO no escala: no explica qué cambió, ni por qué, ni quién lo hizo, y hace imposible el trabajo en paralelo. Nació en 2005 de la necesidad concreta del kernel de Linux y se diseñó desde el primer día para ser rápido, distribuido, barato en ramas e íntegro por construcción. Su carácter distribuido —cada copia contiene el historial completo— es la decisión que lo separa de sistemas centralizados como SVN y la que explica su velocidad, su trabajo sin conexión y su resistencia a fallos.

También hemos conocido a Ana, Bruno y Carla, y el proyecto gestor-tareas que construirán a lo largo del curso: hoy es una carpeta con cuatro ficheros en un portátil; al final será un repositorio compartido con ramas de release, revisiones de código e integración continua.

El siguiente paso es tener Git funcionando en tu equipo. En la lección Instalando Git veremos cómo instalarlo en Linux, macOS y Windows, cómo comprobar que la instalación es correcta y por qué en este curso trabajaremos con la línea de comandos en lugar de con un cliente gráfico.

◄ Anterior
◄
Siguiente ►
►

Dominando Git: De Principiante a Avanzado

Módulo 1: Introducción a Git

Módulo 2: Operaciones Básicas de Git

Módulo 3: Ramas y Fusión

Módulo 4: Trabajando con Repositorios Remotos

Módulo 5: Operaciones Avanzadas de Git

Módulo 6: Herramientas y Técnicas de Git

Módulo 7: Estrategias de Colaboración y Flujo de Trabajo

Módulo 8: Mejores Prácticas y Consejos de Git

Módulo 9: Solución de Problemas y Depuración

Módulo 10: Git en el Mundo Real

El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
© Copyright 2026. Todos los derechos reservados