Compartir a través de


Descripción del historial de Git

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Git almacena el historial como un gráfico de instantáneas (denominada confirmaciones) del repositorio completo. Cada confirmación también contiene un puntero a una o varias confirmaciones anteriores. Las confirmaciones pueden tener varios elementos primarios, creando un historial similar a un gráfico en lugar de una línea recta. Esta diferencia en el historial es increíblemente importante y es la razón principal por la que los usuarios encuentran Git confuso.

Nota:

Si no encuentra ningún cambio en el historial de Git que sabe que ha realizado, obtenga más información sobre cómo funciona la simplificación del historial de Git en Git perdió mis cambios: Eche un vistazo a la simplificación del historial de Git.

Conceptos básicos del historial de confirmaciones

Comience con un ejemplo de historial simple: un repositorio con 3 confirmaciones lineales.

tres confirmaciones en una línea

Confirmar A es el elemento primario de la confirmación B y la confirmación B es el elemento primario de la confirmación C. Este historial es muy similar a un CVCS. La flecha que apunta a confirmar C es una rama. Se denomina main porque es el nombre predeterminado de la rama mainline en un repositorio de Git. Las ramas son punteros a confirmaciones específicas, por lo que la bifurcación es tan ligera y fácil en Git.

Una diferencia clave en Git en comparación con CVCS es que tengo mi propia copia completa del repositorio. Necesito mantener el repositorio local sincronizado con el repositorio remoto obteniendo las confirmaciones más recientes del repositorio remoto. Para ello, extraeré la rama principal con el siguiente comando:

git pull origin main

Esto copia ("extrae") todas las confirmaciones de la main rama del repositorio remoto (llamado origin de forma predeterminada) a la main rama del repositorio local. La operación de extracción copió una nueva confirmación y la main rama del repositorio local apunta ahora a esta nueva confirmación.

se agrega una cuarta confirmación, D, a la línea

Descripción del historial de ramas

Ahora quiero realizar un cambio en mi código. Es habitual tener varias ramas activas en las que se trabaja en diferentes características en paralelo. Esto contrasta con CVCS, donde las nuevas ramas son pesadas y rara vez creadas. El primer paso es desproteger en una nueva rama mediante el siguiente comando:

git checkout -b cool-new-feature

Se trata de un acceso directo que combina dos comandos: git branch cool-new-feature para crear la rama seguida de git checkout cool-new-feature para empezar a trabajar en la rama.

Se ha agregado la característica cool-new-feature de rama

Ahora, dos ramas apuntan a la misma confirmación. Haré algunos cambios en la cool-new-feature rama en dos nuevas confirmaciones, E y F.

se agregaron dos nuevas confirmaciones

Mis confirmaciones son accesibles por la cool-new-feature rama desde que las hice en esa rama. He terminado con mi característica y quiero combinarla en main. Para ello, usaré el siguiente comando:

git merge cool-feature main

después de la combinación

La estructura del gráfico del historial se vuelve visible cuando hay una combinación. Git crea una nueva confirmación al combinar mi rama en otra rama. Se trata de una confirmación de combinación. No hay ningún cambio incluido en esta confirmación de combinación, ya que no tenía conflictos. Si tuviera conflictos, la confirmación de combinación incluiría los cambios necesarios para resolver esos conflictos.

Historia en el mundo real

Este es un ejemplo del historial de Git que se parece más al código en el desarrollo activo en un equipo. Hay tres personas que combinan confirmaciones de sus propias ramas en la rama principal aproximadamente al mismo tiempo.

registro de consola del grafo de Git

Ahora que comprende cómo las ramas y las combinaciones crean la forma del grafo, esto no debería ser demasiado aterrador.