Repository compartido en Git

En la sección introductoria, dijimos que una de las ventajas de Git es que ofrece un modelo de colaboración distribuida. También ya hemos explicado cómo "recuperar" un proyecto preexistente alojado en un servidor remoto usando el comando git clone.

Entremos en más detalles sobre el uso de un repositorio remoto por parte de múltiples colaboradores, comenzando por el modelo más simple, el del "repositorio compartido".

Repository compartido

La forma más sencilla de colaborar utilizando Git es la denominada “modello shared repository”.

En la práctica, dado que un repositorio de Git contiene todo el historial del proyecto, en este modo hay un repositorio compartido ubicado en una computadora remota al que pueden acceder todos los colaboradores y que se utiliza para recuperar o enviar nuevos commit.

Los desarrolladores web colaboradores individuales recuperan una copia local del repositorio remoto compartido en sus computadoras usando el comando git clone. Los commit agregados por colaboradores individuales en sus copias locales se pueden enviar a la copia remota compartida mediante el comando git push. Los commit agregados por otros colaboradores a la copia remota compartida se pueden recuperar y devolver a su copia local mediante los comandos git fetch y git pull.

De esta forma, el repositorio remoto compartido actúa como una “master copy” (la versión original de un contenido, por ejemplo, un álbum de música o una película de la que se hacen copias) de la historia del repositorio, es decir, es el historia original y oficial de los repositorios que todos pueden acceder.

History original

Obviamente, la otra característica fundamental de Git entra en juego al enviar y recuperar nuevos commit, es decir, la protección de los cambios en el historial. En el caso que se muestra en la imagen de arriba, dos colaboradores agregaron un commit (D y E respectivamente) a la misma secuencia de commit (A-B-C) recuperada de un repositorio remoto.

En esta situación, el histy de los dos repositorios locales es "localmente" correcto. Ambos saben que tienen una confirmación más que el repositorio remoto, y ambos pueden enviar potencialmente su propio commit adicional al repositorio remoto.

En el momento en que uno de los dos colaboradores envía su commit al repositorio remoto original, la situación cambia.

You shall not push

Una vez que la confirmación del colaborador con el cilindro (E) se haya convertido en parte del repositorio remoto original, ya no será posible que el otro colaborador envíe su commit (D) al repositorio remoto. De hecho, para Git un commit no se compone solo de los cambios realizados en los archivos que forman parte del proyecto, sino que es un snapshot dentro de una secuencia de snapshot.

El colaborador sin cilindro tiene dos opciones:

• recupera del repository remoto la history actualizada (A-B-C-E), agrega a esta su commit y luego lo envía al repository remoto
• fuerza el envío de su history (A-B-C-D) al repository remoto, sobrescribiendo y eliminando así todos los rastos del commit E del repository remoto

La segunda opción es obviamente la que no debe usarse en situaciones normales. Git permite sobrescribir el historial, pero solo se debe hacer cuando realmente se hace, es decir, para corregir algo, no para frustrar el trabajo de otros.

En cuanto a la primera opción, existen varias situaciones posibles cuando recuperas el historial remoto actualizado y lo vuelves a copiar a tu copia local, que veremos en las siguientes secciones.

Una nota final: obviamente, el repositorio remoto compartido también se usa para mantener sincronizados el branch y tag.