Ediciones ENI Editorial | líder en informática
Compartir un repositorio
¿Qué es un repositorio remoto?
Un repositorio remoto es un repositorio que servirá para centralizar un repositorio. Es un tipo de repositorio que se vuelve realmente importante (e incluso indispensable) cuando varios colaboradores trabajan en el mismo proyecto, ya que permite centralizar el trabajo de cada desarrollador.
En inglés, este tipo de repositorio se llama bare repository o un remote, lo que daría una traducción cercana de repositorio desnudo o repositorio simple. También podemos encontrar las terminologías repositorio de autoridad o repositorio servidor para designar este tipo de repositorio. En el entorno de habla española, se utilizan los términos repositorio remoto o repositorio servidor para designar este tipo de repositorio. Para evitar confusiones y utilizar términos reconocidos, en este libro usaremos el término repositorio remoto para referirnos a este tipo de repositorio, en contraste con el repositorio local (que también podría llamarse repositorio cliente).
El esquema siguiente presenta una arquitectura sencilla compuesta de un repositorio remoto y dos repositorios locales:
Este esquema presenta también un ejemplo del ciclo de vida de la relación entre estos dos tipos de repositorios con líneas de puntos que representan los intercambios entre el repositorio remoto y los repositorio locales. Este ejemplo permitirá entender mejor...
Crear un repositorio remoto
1. Para un nuevo proyecto
Un nuevo proyecto se percibe aquí solo desde el punto de vista de Git, es decir, que un nuevo proyecto puede contener código y existir desde hace varios años. La única característica que lo diferencia de un proyecto existente es no ser administrado por ningún repositorio.
La creación de un depósito remoto Git virgen es muy simple: hay que usar git init añadiendo el parámetro --bare. Por ejemplo, para crear un nuevo repositorio llamado new_browser, hay que usar el comando siguiente:
git init --bare new_browser Git indica que el comando ha concluido con éxito mostrando la siguiente salida:
Initialized empty Git repository in
/Volumes/JedemaKey/Libro/Git/Repo/07/01BareVirgen/new_browser/ 2. Para un proyecto existente
Un proyecto existente es, desde el punto de vista de Git, un proyecto que ya está almacenado en un repositorio de Git. Para esto, se debe utilizar el comando git clone, que copiará un repositorio remoto en un nuevo repositorio local. Este comando se explicará con más detalle en la continuación de este capítulo. Para probar esta parte, se requiere un repositorio local que contenga varios commits. Vamos, pues, a crear una carpeta con un repositorio local, guardar mediante commits las modificaciones en este repositorio y crear una carpeta donde clonaremos el repositorio local....
Clonar un repositorio remoto
Clonar un repositorio equivale a copiar el contenido de un repositorio a un nuevo repositorio. El nuevo repositorio contendrá un directorio de trabajo que permitirá recuperar y guardar las modificaciones.
El hecho de clonar un repositorio vuelve a copiar todo el contenido de un repositorio en un nuevo repositorio. Las ramas, los commits y todos los demás objetos almacenados por Git se duplicarán en un nuevo repositorio.
Los protocolos de intercambio
Para intercambiar con un repositorio remoto, se requiere utilizar un medio de comunicación entre este repositorio y el repositorio local. Los depósitos necesitan intercambiar datos cuando, por ejemplo, un desarrollador desea clonar un repositorio o cuando desea enviar sus modificaciones al repositorio remoto.
Existen cuatro protocolos para intercambiar información entre dos repositorios:
-
Local: empleando el sistema de archivos.
-
SSH: utilizando un acceso SSH al equipo que contiene el repositorio remoto.
-
HTTP: utilizando el protocolo HTTP a través de un servidor HTTP.
-
Git: empleando el protocolo Git diseñado para un buen rendimiento.
Cada uno de estos protocolos tiene sus ventajas y desventajas y es conveniente para aplicaciones diversas. El cuadro siguiente presenta una lista no exhaustiva de las ventajas y desventajas de los diferentes protocolos:
|
Protocolos |
Ventajas |
Inconvenientes |
|
Local |
|
|
|
SSH |
|
|
|
HTTP |
|
|
Funcionamiento interno y ramas remotas
El uso de ramas locales y remotas es sencillo gracias a los comandos git pull y git push. Estos comandos ocultan el sistema interno de Git que permite gestionar estas ramas sin dificultad.
1. Los repositorios remotos vinculados
Un repositorio local puede vincularse con varios repositorios remotos. Para tener la lista de los repositorios remotos vinculados con el repositorio local, se debe utilizar el comando siguiente:
git remote Durante el uso del comando git clone, se introduce un repositorio remoto llamado origin en el archivo .git/config. A continuación mostramos un extracto de la parte que contiene los repositorios remotos:
[remote "origin"]
url = /Volumes/JedemaKey/Libro/Git/Repo/07/test_echange/remote
fetch = +refs/heads/*:refs/remotes/origin/* En este ejemplo, la primera línea define el nombre del repositorio remoto que utilizará Git.
La línea siguiente define la URL para comunicarse con el repositorio remoto.
La siguiente línea permite especificar el lugar donde se almacenan las ramas locales y las ramas remotas seguidas.
2. Las ramas remotas seguidas
El capítulo anterior explica el funcionamiento de las ramas. Las ramas son un sistema muy eficaz para gestionar desarrollos divergentes dentro de un mismo proyecto. Para poder ofrecer un sistema tan flexible de repositorio remoto, Git utiliza ramas ocultas vinculadas al servidor remoto....
Enviar sus modificaciones
Cuando un desarrollador trabaja en un repositorio local y guarda con un commit su trabajo, necesita enviar periódicamente sus modificaciones al repositorio remoto. Enviar sus modificaciones a un repositorio remoto permite compartir con sus otros colaboradores. Este es el comando para enviar al remote llamado origin las modificaciones añadidas en la rama master. Este comando puede utilizarse en un repositorio local:
git push origin master Un remote es un repositorio remoto para que un exista un vínculo con el repositorio local. Aquí, el remote origin es en realidad un acceso directo a un repositorio remoto. Si el repositorio ha sido clonado a partir de la URL http://git-conflict.com/repositorios/CMS.git, entonces origin apuntará siempre a esta URL.
Hay que saber que, si varios desarrolladores trabajan en el mismo servidor remoto, si otro desarrollador envió modificaciones (mediante uno o varios commits) en el servidor y nadie los ha recuperado, entonces nadie podrá enviar sus modificaciones antes de haber recuperado aquellas presentes en el servidor. Este caso puede probarse fácilmente siguiendo estos pasos:
-
Crear un nuevo repositorio remoto:
mkdir test_echange
cd test_echange
git init --bare remoto Cuando la interfaz de línea de comandos se sitúa en el repositorio remoto, el comando git log mostrará la siguiente salida:
fatal: bad default...Recibir las modificaciones
Saber enviar las modificaciones al repositorio remoto es útil, pero todo el valor de un repositorio también radica en el hecho de que los demás colaboradores de un proyecto podrán recuperar los commits contenidos en este repositorio.
El comando siguiente permite actualizar la rama actual con los commits contenidos en el repositorio remoto:
git pull Ejecutado a partir del repositorio local2, este comando mostrará la siguiente salida:
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /Volumes/JedemaKey/Libro/Git/Repo/07/test_echange/remote
* [new branch] master -> origin/master En realidad, el comando git pull es un acceso directo de dos comandos Git ejecutados sucesivamente:
git fetch
git merge FETCH_HEAD El comando git fetch descargará los commits contenidos en el repositorio remoto para la rama específica. Los commits se integrarán en la rama remota seguida.
El comando git merge FETCH_HEAD hará luego merge de las modificaciones contenidas en la rama remota seguida para integrarlas en la rama local.
Para ilustrar el uso de estos dos comandos, debemos modificar el archivo README del repositorio local1 y luego hacer commit:
cd local1
vi README
git add README
git commit -m "README...