Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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.
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.
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.
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.
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
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.
Ahora que comprende cómo las ramas y las combinaciones crean la forma del grafo, esto no debería ser demasiado aterrador.