Historia de Git

Git representa el historial de una manera fundamentalmente diferente de los sistemas de controles de versiones centralizados (CVCS), como el control de versiones de Team Foundation, Perforce o Subversion. Los sistemas centralizados almacenan un historial independiente para cada archivo de un repositorio. Git almacena el historial como un gráfico de instantáneas de todo el repositorio. Estas instantáneas, llamadas confirmaciones en Git, pueden tener varios elementos primarios, creando un historial que parece 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 familiarizados con los CVCS encuentran que Git es confuso.

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. 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 los CVCS es que el desarrollador tiene su propia copia completa del repositorio. Necesitan mantener su repositorio local sincronizado con el repositorio remoto obteniendo las últimas confirmaciones del repositorio remoto. Para hacer esto, tiran de la rama principal con el siguiente comando:

git pull origin main

Esto combina todos los cambios de la rama principal en el repositorio remoto, que Git denomina origin de forma predeterminada. Esta incorporación de cambios trajo una nueva confirmación y la rama principal del repositorio local se mueve a esa confirmación.

Descripción del historial de ramas

Ahora es el momento de realizar un cambio en el código. Es común tener múltiples ramas activas cuando 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
• git checkout cool-new-feature para empezar a trabajar en la rama

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

La rama cool-new-feature puede acceder a las confirmaciones, ya que se han confirmado en esa rama. Ahora que la característica está completada, debe combinarse con la rama principal. Para ello, ejecute el siguiente comando:

git merge cool-new-feature main

La estructura del gráfico del historial se vuelve visible cuando hay una fusión mediante combinación. Git crea una nueva confirmación cuando la rama se combina 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, ya que no hubo conflictos. Si hubiera conflictos, la confirmación de fusión incluiría los cambios necesarios para resolverlos.

Historial en el mundo real

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

Pasos siguientes

Obtenga más información sobre cómo trabajar con el historial de Git en GitHub y Azure Repos o la simplificación del historial de registro de Git.