Descripción del historial de Git

Git representa el historial de una manera fundamentalmente diferente de los sistemas centralizados de controles de versiones (CVCS), como 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, denominadas commits en Git, pueden tener varios padres, creando un historial que se asemeja 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 familiarizados con CVCS encuentran a Git confuso.

Conceptos básicos del historial de confirmaciones

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

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. 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 el desarrollador tiene su propia copia completa del repositorio. Deben mantener su repositorio local sincronizado con el repositorio remoto obteniendo las confirmaciones más recientes del repositorio remoto. Para ello, extraen 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 por defecto. Este pull trajo un nuevo commit y la rama principal del repositorio local se mueve a ese commit.

Descripción del historial de ramas

Ahora es el momento de realizar un cambio en el código. Es habitual tener varias ramas activas al trabajar 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
• git checkout cool-new-feature para comenzar a operar en la sucursal

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

Las confirmaciones son alcanzables por la rama cool-new-feature ya que se realizaron en esa rama. Ahora que la funcionalidad está completa, debe fusionarse en la rama principal. Para ello, use el siguiente comando:

git merge cool-new-feature main

La estructura del gráfico del historial se vuelve visible cuando hay una combinación. Git crea un nuevo commit cuando una rama se fusiona con 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 hubo ningún conflicto. Si hubiera conflictos, el commit de fusión incluiría los cambios necesarios para resolverlos.

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 fusionan commits de sus propias ramas en la rama main aproximadamente 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 simplificación del historial de registros de Git.