Historia de Git

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

Git almacena el historial como un gráfico de instantáneas (denominado confirmaciones) de todo el repositorio. 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 Git es confuso para los usuarios.

Nota:

Si no encuentra ningún cambio en el historial de Git que sabe que ha realizado, descubra cómo funciona la simplificación del historial de Git en Descripción de la simplificación del historial de Git.

Conceptos básicos del historial de confirmaciones

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

La confirmación 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 la confirmación C es una rama. Se denomina main porque es el nombre predeterminado de la rama principal en un repositorio de Git. Las ramas son punteros a confirmaciones específicas; por eso, crear una rama es tan ligero 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 mediante la obtención de las confirmaciones más recientes del repositorio remoto. Para ello, extraeré la rama principal con este comando:

git pull origin main

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

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 ramas nuevas son pesadas y no se suelen crear. El primer paso es desproteger en una rama nueva mediante este 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 seguido de git checkout cool-new-feature para empezar a trabajar en la rama.

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

La rama cool-new-feature puede acceder a mis confirmaciones desde que las hice en esa rama. He terminado con mi característica y quiero combinarla con main. Para ello, usaré este comando:

git merge cool-feature main

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

Historial 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.

Ahora que comprende cómo las ramas y las fusiones mediante combinación crean la forma del gráfico, no debería ser demasiado aterrador.