Cómo funciona Git: instantáneas, ramas e historial

Cómo funciona Git: instantáneas, ramas e historial

El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.

Cómo leer este diagrama

• Lee las tres columnas de izquierda a derecha: Editar, Hacer commit, Compartir.
• Los cuatro grupos de carriles son un pipeline: del directorio de trabajo al área de preparación (staging area), de ahí al repositorio local y al remoto; cada flecha acerca el cambio un paso más a estar compartido.
• La decisión «¿Dos personas han cambiado las mismas líneas?» es la única rama del diagrama, y sus dos salidas convergen al final en el historial compartido.

Editar y preparar

«El desarrollador edita archivos en el directorio de trabajo» es la realidad sin commit: archivos en disco que todavía no forman parte del historial. «git add mueve los cambios al área de preparación» es el paso intermedio deliberado: preparar los cambios te deja construir un commit con los que elijas, y no con todo lo que hayas tocado. El diagrama los separa en grupos propios porque ese commit en dos pasos es lo que le da a Git su precisión.

Confirmar la instantánea

«git commit hace una instantánea de los cambios preparados» es donde un cambio se vuelve permanente. «Git guarda el commit con un puntero a su padre» hace explícito el grafo: todo commit, salvo el primero, nombra al commit anterior, y eso es lo que hace que el historial solo admita añadidos y sea auditable. «El puntero de la rama se mueve al nuevo commit» completa el acto: una rama es solo un puntero, así que hacer commit en una rama es mover ese puntero. Al commit en sí le da igual en qué rama está.

Compartir el historial

«git push envía los commits al remoto» cruza del grupo «Repositorio local» al grupo «Repositorio remoto», el único punto donde los datos salen de tu máquina. «El repositorio remoto registra el nuevo historial» es la copia compartida, y «¿Dos personas han cambiado las mismas líneas?» modela la fusión: Git fusiona historiales divergentes de forma automática salvo que se hayan editado las mismas líneas, en cuyo caso «Conflicto de fusión: el desarrollador lo resuelve a mano» hace explícita la decisión humana antes de que «El historial está compartido y al día» cierre el flujo.

Relaciones clave y conclusiones

• Un commit es una instantánea completa enlazada con su padre, y eso convierte el historial en un grafo que solo admite añadidos.
• Una rama es un puntero a un commit, no un contenedor de cambios: por eso crear ramas y cambiar de rama sale barato.
• El área de preparación es el paso intermedio deliberado que te deja elegir qué contiene un commit.
• Git es distribuido: todo el mundo tiene el historial completo en local, y push y pull solo intercambian las piezas que faltan.
• Los conflictos son la excepción, no la regla, y cuando ocurren los resuelve una persona de forma explícita.

Cuándo usar este diagrama

• Enseñar el modelo de instantáneas a un equipo que solo ha usado Git como una secuencia de comandos.
• Explicar ramas, fusiones y conflictos con el modelo de punteros en vez de con comandos memorizados.
• Aterrizar la revisión del flujo de commits y de ramas de un equipo en cómo está estructurado el historial de verdad.

Cómo funciona

1. Traza el flujo de trabajo real de tu equipo

   Anota las cajas con los comandos que usa de verdad tu equipo —ramas de funcionalidad, pull requests, rebase frente a merge— para que el diagrama documente vuestra práctica y no la de un manual.

2. Añade el modelo de ramas

   Inserta filas para la rama de funcionalidad y la rama principal dentro del grupo del repositorio local, y dibuja entre ellas las flechas de fusión, que terminan en el historial compartido.

3. Dibuja la puerta del pull request

   Añade una decisión entre el push local y el registro en el remoto: una revisión y una comprobación de CI que tienen que pasar antes de fusionar la rama en main.

4. Añade las rutas de recuperación

   Incluye las ramas de deshacer —revertir un commit, corregir un mensaje, volver a un estado anterior—, cada una con un resultado explícito, porque la recuperación es la mitad del uso real de Git.

Preguntas frecuentes

¿Qué es Git y en qué se diferencia de otros controles de versiones?

Git es un sistema de control de versiones distribuido basado en instantáneas. Cada commit guarda una imagen completa del repositorio más un puntero a su padre, en lugar de una simple lista de cambios en archivos. Como cada desarrollador tiene el historial completo en local, la mayoría de las operaciones funcionan sin conexión, y colaborar consiste en intercambiar commits con los remotos.

¿Qué es una rama en Git?

Una rama es un puntero móvil a un commit. Cuando haces commit en una rama, el puntero avanza al nuevo commit; al commit en sí no le importa en qué rama está. Por eso crear una rama es instantáneo, y por eso cambiar de rama solo cambia qué instantánea muestra tu directorio de trabajo.

¿Por qué Git tiene un área de preparación?

El área de preparación te deja construir un commit de forma deliberada. Puedes editar varios archivos, preparar solo los que van juntos y hacer commit de esa selección, dejando sin confirmar el trabajo que no viene al caso. El directorio de trabajo, el área de preparación y el repositorio son tres estados separados, que es exactamente el pipeline que dibuja el diagrama.

¿Cómo resuelve Git los conflictos de fusión?

Cuando dos ramas cambian archivos distintos, o líneas distintas, Git las fusiona automáticamente. Cuando cambian las mismas líneas, Git no puede adivinar qué versión es la correcta, así que marca el conflicto y le pide a una persona que elija. El conflicto es una decisión, no un fallo, y por eso el diagrama lo enruta a un paso de resolución explícito antes de compartir el historial.

Edita este diagrama en QueryChart (FlowJam)

Abre ese mismo lienzo de Git como tu propio diagrama, renombra los carriles según tu flujo de trabajo y traza tu propio historial.

Edita este diagrama en QueryChart (FlowJam)