Ana ya tiene Git instalado en su portátil, pero antes de escribir su primer comando necesita entender el vocabulario. Git tiene un léxico propio, denso y muy preciso: cada palabra —repositorio, índice, HEAD, rama, remoto— designa una cosa concreta, y usar mal un término es la puerta de entrada a la confusión. Además, todos los comandos están en inglés mientras que la documentación en español traduce los conceptos, así que conviene manejar las dos etiquetas de cada idea desde el principio.

Esta lección es un glosario razonado. No vamos a ejecutar operaciones —eso llega en el módulo 2—, sino a definir qué significa cada término y cómo se relaciona con los demás. El objetivo es que cuando en el módulo 3 leas "fusionar la rama de Bruno en main", cada palabra de esa frase tenga un significado nítido en tu cabeza.

1. Las tres zonas de Git
2. Los tres estados de un fichero
3. Glosario esencial
4. Referencias: HEAD, ramas y etiquetas
5. Colaboración: remotos, clones y forks
6. Integración: fusión y rebase
7. Vocabulario español ↔ inglés
8. Cómo encajan todos los términos

Todo el trabajo con Git ocurre en tres lugares distintos. Entender esta separación es el 50 % de entender Git.

Es la carpeta que ves en el explorador de ficheros: para Ana, la carpeta gestor-tareas con index.html, estilos.css, app.js y README.md. Son ficheros normales, que puedes abrir y editar con cualquier programa. Git no interfiere con ellos.

Contiene una sola versión del proyecto: la que estás editando ahora mismo.

Es una zona intermedia donde se acumula lo que formará la próxima confirmación. Físicamente es un fichero binario dentro de .git, llamado index —de ahí que a esta zona se la llame indistintamente staging area, index o cache, tres nombres para lo mismo.

Su razón de ser es el control. Sin ella, confirmar significaría "guarda todo lo que he tocado". Con ella, Ana puede haber modificado cinco ficheros y decidir que solo tres de ellos, o incluso solo ciertas líneas de un fichero, forman un cambio con sentido propio. El resultado son confirmaciones limpias, cada una con una única intención.

Es la carpeta oculta .git que está dentro del proyecto. Contiene todo el historial: cada confirmación, cada versión de cada fichero, todas las ramas y etiquetas, la configuración local y las referencias a los remotos.

Dos consecuencias prácticas:

• Si copias la carpeta del proyecto con su .git, te llevas el proyecto entero con su historial.
• Si borras .git, el historial desaparece y queda una carpeta corriente de ficheros. Los ficheros actuales sobreviven; todo lo demás, no.

Como corolario de las tres zonas, cualquier fichero en un proyecto Git está en uno de estos estados.

Un ejemplo con la carpeta de Ana, todavía sin ejecutar comandos:

• Ana crea README.md en un proyecto Git recién creado → el fichero está no rastreado.
• Ana lo prepara → pasa a preparado.
• Ana confirma → pasa a confirmado. Ahora es rastreado y está limpio.
• Ana añade una línea al README.md → vuelve a estar modificado.

Un mismo fichero puede estar en dos estados a la vez: si Ana prepara un cambio y después vuelve a editar el fichero, tendrá una parte preparada y otra modificada sin preparar. Esto desconcierta al principio y tiene todo el sentido cuando se entiende que las tres zonas contienen versiones independientes.

Esta es la tabla de referencia de la lección. Consúltala cuando un término no te suene en lecciones posteriores.

Tres merecen un párrafo propio, porque son los que generan más confusión.

Confirmación (commit). No es "guardar el fichero". Es registrar una instantánea del proyecto entero en un momento concreto, acompañada de metadatos: quién la hizo, cuándo, con qué mensaje y de qué confirmación anterior parte. Se identifica por un hash como a3f5c9e2b1d4..., que en la práctica se abrevia a los primeros siete caracteres (a3f5c9e). Una vez creada, es inmutable.

Además, "commit" funciona como sustantivo y como verbo: hacer un commit (crear una confirmación) y commitear un cambio (registrarlo). En español usaremos "confirmación" y "confirmar", aunque en el habla profesional española se oye constantemente el anglicismo.

Rama (branch). Intuitivamente es "una línea de desarrollo paralela". Técnicamente es mucho más simple: un fichero de texto con el hash de una confirmación. Cuando Ana confirma un cambio estando en la rama main, Git actualiza ese fichero para que apunte a la nueva confirmación. Por eso crear una rama en Git es instantáneo: solo escribe cuarenta y un bytes en el disco. El módulo 3 desarrolla esto a fondo.

HEAD. Es la respuesta a la pregunta "¿dónde estoy?". Normalmente HEAD apunta a una rama, y esa rama apunta a una confirmación. Cuando cambias de rama, lo que cambia es HEAD.

Existe un caso especial llamado HEAD desacoplado (detached HEAD): cuando HEAD apunta directamente a una confirmación en lugar de a una rama. Ocurre al posicionarse en un punto concreto del historial para inspeccionarlo. No es un error, aunque el mensaje que Git muestra asusta la primera vez. Lo trataremos en el módulo 3.

Los tres son referencias (refs): nombres legibles que apuntan a confirmaciones. Se diferencian en su comportamiento.

Un ejemplo con gestor-tareas, escrito como historia y no como comandos:

• Ana trabaja en la rama main. HEAD apunta a main.
• Bruno crea la rama formulario-validacion para añadir validación al formulario de index.html y trabaja en ella. La rama de Bruno avanza; main se queda donde estaba.
• Cuando la aplicación se publica por primera vez, el equipo pone la etiqueta v1.0 sobre esa confirmación. Esa etiqueta ya no se moverá nunca: siempre señalará exactamente lo que se publicó.

Para versiones publicadas se recomiendan las anotadas, porque dejan constancia de quién publicó qué y cuándo. El módulo 5 dedica una lección completa al tema.

Estos tres términos describen cómo un repositorio se relaciona con otros. El módulo 4 los desarrolla operativamente; aquí solo los definimos.

Remoto (remote). Un repositorio distinto del tuyo con el que sincronizas trabajo. No es "el servidor": es cualquier otro repositorio Git, que puede estar en GitHub, en un servidor de la empresa o incluso en otra carpeta de tu propio disco. Un repositorio puede tener varios remotos, cada uno con un nombre corto. Por convención, el principal se llama origin.

Clon (clone). Copia completa de un repositorio: todo el historial, todas las ramas, todas las etiquetas. Cuando Bruno clone el repositorio de gestor-tareas, tendrá exactamente la misma información que Ana, y Git configurará automáticamente el remoto origin apuntando al sitio del que clonó.

Fork. Un concepto de plataforma, no de Git. Es la copia de un repositorio ajeno bajo tu propia cuenta en GitHub, GitLab o similar, que te permite trabajar sobre él sin tener permiso de escritura en el original. Es la base del flujo de contribución a proyectos de código abierto, y se trata en el módulo 7.

Los cuatro verbos que se usarán constantemente a partir del módulo 4:

La distinción entre fetch y pull es la que más problemas causa a los principiantes: fetch es siempre seguro porque no modifica nada de lo tuyo; pull puede provocar fusiones y conflictos.

Dos formas de unir el trabajo de dos líneas de desarrollo. Aquí solo los definimos; el módulo 3 trata la fusión y el módulo 5, el rebase.

Fusión (merge). Integra los cambios de una rama en otra creando una nueva confirmación —la confirmación de fusión— que tiene dos padres: la última confirmación de cada rama. El historial conserva la forma real de lo que ocurrió: dos líneas que se separaron y volvieron a juntarse.

Rebase. Toma las confirmaciones de una rama y las reaplica una a una sobre otra base, como si el trabajo se hubiera hecho desde el principio a partir del estado más reciente. El resultado es un historial lineal, sin bifurcaciones visibles. A cambio, las confirmaciones originales se sustituyen por otras nuevas con hash distinto: es una reescritura del historial.

Conflicto (conflict). Tanto la fusión como el rebase pueden acabar en conflicto: ocurre cuando las mismas líneas de un fichero se han cambiado de forma distinta en las dos partes, y Git no puede decidir cuál es correcta. No es un error ni un fallo: es Git pidiendo una decisión humana. Si Bruno y Carla modifican la misma regla de estilos.css, habrá conflicto; si Bruno toca estilos.css y Carla app.js, Git integrará ambos sin intervención.

Los comandos de Git están en inglés y no se traducen nunca. La documentación en español, en cambio, traduce los conceptos. Esta tabla cierra la brecha.

Consejo lingüístico. En un equipo español real oirás una mezcla: "hazme un pull request", "he commiteado el cambio", "hay que mergear la rama". No es incorrecto en la conversación profesional. En este curso usaremos la terminología en español y añadiremos el término inglés entre paréntesis la primera vez, para que reconozcas ambos.

Para cerrar, un mapa mental que sitúa cada término en su lugar:

Y la frase que resume todo lo visto, aplicada a nuestro proyecto:

En su repositorio de gestor-tareas, Ana edita ficheros en su directorio de trabajo, prepara los cambios que quiere agrupar en el área de preparación y crea una confirmación que queda registrada para siempre en .git. HEAD indica en qué rama está trabajando; esa rama avanza con cada confirmación. Cuando publican una versión, ponen una etiqueta. Bruno clona el repositorio desde el remoto origin, trabaja en su propia rama y, cuando termina, su trabajo se fusiona con el de Ana.

Si esa frase te resulta comprensible entera, la lección ha cumplido su objetivo.

• Confundir "guardar el fichero" con "confirmar". Guardar en el editor solo escribe en el disco; Git no se entera de nada hasta que preparas y confirmas. Son dos operaciones sin relación.
• Creer que el área de preparación es un estorbo. Al principio parece un paso burocrático de más. Es justo lo contrario: es lo que permite que cada confirmación tenga una sola intención en lugar de ser un cajón de sastre. Verás su valor en cuanto tengas cambios de tres tareas distintas mezclados en tu carpeta.
• Pensar que una rama es una copia de la carpeta. No lo es. Es un puntero de cuarenta y un bytes. Esta confusión, heredada de SVN, hace que la gente evite crear ramas por miedo a "duplicar el proyecto".
• Usar "fork" y "clon" como sinónimos. Clonar es traerte una copia a tu equipo (es Git). Hacer un fork es copiar el repositorio a tu cuenta del servidor (es la plataforma). Lo habitual es hacer fork y luego clonar tu fork.
• Traducir "checkout" mentalmente como "confirmar". checkout significa "situarse en", nunca "guardar". Es un falso amigo peligroso porque en algunos sistemas centralizados significaba "bloquear un fichero para editarlo".
• Entender el conflicto como un fallo. Un conflicto significa que Git ha detectado correctamente que dos personas cambiaron lo mismo y te pide una decisión. Que aparezca es señal de que el sistema funciona.
• Consejo: vuelve a esta lección. No hace falta memorizar la tabla hoy. Ténla a mano y reléela al empezar cada módulo nuevo; los términos se asientan con el uso.

Ana tiene su repositorio de gestor-tareas con index.html, estilos.css, app.js y README.md confirmados. Durante una tarde de trabajo hace lo siguiente, en este orden:

1. Edita estilos.css para cambiar el color de fondo.
2. Prepara estilos.css.
3. Crea un fichero nuevo, notas-personales.txt.
4. Edita app.js para añadir el borrado de tareas.
5. Vuelve a editar estilos.css para ajustar un margen.

Indica en qué estado está cada uno de los cinco ficheros al final de la tarde. Cuidado con el punto 5.

Traduce estas cinco frases de jerga profesional a un español preciso usando la terminología de la lección, e indica a qué módulo del curso pertenece cada operación:

1. "Hazme un fork del repo y luego clónatelo."
2. "Stagea solo el CSS, el JS déjalo fuera del commit."
3. "He hecho pull y me han saltado conflictos en app.js."
4. "Taggea la versión 1.0 en la master."
5. "Rebasa tu rama sobre main antes de mergear."

Indica si cada afirmación es verdadera o falsa y explica por qué:

1. Si borro la carpeta .git, pierdo los ficheros de mi proyecto.
2. Una etiqueta se mueve automáticamente cuando hago una nueva confirmación.
3. git fetch puede provocar un conflicto de fusión.
4. Un fichero puede estar preparado y modificado a la vez.
5. Un clon contiene menos información que el repositorio original.
6. HEAD siempre apunta a una rama.

Solución al Ejercicio 1

El punto interesante es estilos.css: la versión que hay en el área de preparación (con el color nuevo, sin el margen) y la que hay en el directorio de trabajo (con ambos cambios) son distintas. Si Ana confirmara ahora, el ajuste de margen no entraría en la confirmación.

Solución al Ejercicio 2

1. "Haz una copia del repositorio en tu cuenta (fork) y después clónala en tu equipo." → Fork: módulo 7. Clonar: módulo 2 y módulo 4.
2. "Prepara solo el fichero CSS; deja el JavaScript fuera de la confirmación." → Módulo 2.
3. "He extraído los cambios del remoto y han aparecido conflictos de fusión en app.js." → Extraer: módulo 4. Conflictos: módulo 3.
4. "Pon una etiqueta con el nombre v1.0 sobre la última confirmación de la rama principal." → Módulo 5.
5. "Aplica un rebase de tu rama sobre main antes de fusionarla." → Rebase: módulo 5. Fusión: módulo 3.

Solución al Ejercicio 3

1. Falso. Los ficheros del directorio de trabajo son ficheros normales y siguen ahí. Lo que se pierde es todo el historial: confirmaciones, ramas, etiquetas y configuración local. El proyecto se convierte en una carpeta corriente.
2. Falso. Ese es el comportamiento de una rama, que avanza con cada confirmación. Una etiqueta es fija por definición: siempre señala la misma confirmación. Es justamente lo que la hace útil para marcar versiones publicadas.
3. Falso. fetch solo descarga información del remoto y actualiza las referencias remotas; no toca tu directorio de trabajo ni tus ramas locales, así que no puede provocar conflictos. Quien puede provocarlos es pull, porque descarga e integra.
4. Verdadero. Es exactamente el caso de estilos.css en el ejercicio 1. Las tres zonas contienen versiones independientes del mismo fichero, así que puede haber diferencias tanto entre repositorio y área de preparación como entre área de preparación y directorio de trabajo.
5. Falso. Un clon contiene el historial completo: todas las confirmaciones, ramas y etiquetas. Esa es precisamente la característica que define a un sistema distribuido, como vimos en la lección ¿Qué es Git?. (Existen clones deliberadamente parciales —shallow clones— pero son la excepción, no la norma; se tratan en el módulo 10.)
6. Falso. Lo habitual es que HEAD apunte a una rama, pero puede apuntar directamente a una confirmación: es el estado de HEAD desacoplado (detached HEAD), que se produce al situarse en un punto concreto del historial. Se trata en el módulo 3.

Ya dispones del vocabulario que sostiene el resto del curso. Los conceptos clave son tres zonas (directorio de trabajo, área de preparación y repositorio) y tres estados (modificado, preparado, confirmado), que juntos explican el flujo básico de trabajo. Sobre ellos se apoyan las referencias —ramas, etiquetas y HEAD—, que son nombres apuntando a confirmaciones, y los conceptos de colaboración —remoto, clon, fork— y de integración —fusión, rebase, conflicto—, que desarrollaremos en los módulos 3, 4 y 5.

También has visto la correspondencia español↔inglés, imprescindible porque los comandos nunca se traducen y en un equipo real oirás las dos formas mezcladas.

Sabemos ya cómo se llaman las cosas. La siguiente pregunta es cómo son por dentro: qué guarda Git exactamente cuando confirmas, por qué los identificadores son hashes de cuarenta caracteres y qué hay dentro de .git. Es el contenido de El Modelo de Datos de Git, la lección que aporta el modelo mental sobre el que descansan todos los módulos siguientes.