1 Introducción

Un sistema de control de versiones registra los cambios que sufre un conjunto de archivos a lo largo del tiempo, de modo que sea posible recuperar versiones específicas más adelante, comparar cómo evolucionó el contenido, y combinar el trabajo de varias personas sobre los mismos archivos.

Git es un sistema de control de versiones distribuido. Esto lo distingue de sistemas más antiguos como CVS o Subversion, que son centralizados. La diferencia no es un detalle técnico menor: cambia por completo la forma de trabajar.

1.1 Centralizado frente a distribuido

En un sistema centralizado hay un único servidor que guarda toda la historia del proyecto. Cada persona tiene en su máquina solo la versión de los archivos en la que está trabajando en ese momento; el historial completo vive en el servidor. Para consultar una versión antigua, o incluso para hacer un commit, hace falta comunicarse con ese servidor.

En Git, en cambio, cada copia del repositorio contiene el historial completo del proyecto: todos los commits, todas las ramas, todas las etiquetas. Cuando alguien clona un repositorio, no obtiene solo el estado actual de los archivos, sino una réplica entera de la base de datos de Git. Esto tiene consecuencias prácticas importantes:

1.2 Las tres áreas de trabajo

Para entender casi cualquier operación de Git conviene tener presente que un repositorio local se organiza en tres áreas:

  1. Directorio de trabajo (working directory): los archivos tal como los ves y editas normalmente en el sistema de archivos.
  2. Índice o área de preparación (staging area): una zona intermedia donde se marca qué cambios se incluirán en el próximo commit. Se explica en detalle en El índice.
  3. Repositorio (.git): la base de datos donde Git guarda de forma permanente el historial de commits, una vez confirmados.

La mayoría de los comandos de uso diario —add, commit, restore, reset— son formas de mover cambios entre estas tres áreas. Tenerlas presentes ayuda a predecir qué hace cada comando antes de memorizar su sintaxis.

1.3 Cómo está organizado este manual

Este manual sigue un orden distinto al de las páginas de manual de Git. En vez de un capítulo por subcomando, cada capítulo cubre un concepto. La Parte I explica el modelo de datos interno de Git de forma directa —algo que normalmente se aprende por accidente, después de mucha confusión—, porque una vez entendido, el comportamiento de casi cualquier comando deja de parecer arbitrario. Las partes siguientes construyen sobre esa base, desde el uso diario hasta los flujos de trabajo colaborativos, los internals y las herramientas avanzadas.