En el artículo anterior vimos como trabajar con repositorios locales, y aunque con esto, ya tenemos adelantado mucho respecto a no utilizar ningún tipo de sistema de control de versiones, lo cierto es que la gracia de todo esto se encuentra en la colaboración. Es decir, que varios usuarios trabajen de forma simultánea en un mismo proyecto. Este proyecto estará ubicado en un repositorio remoto. La realidad, es que tal y como comentamos en el artículo anterior, nosotros trabajaremos en el repositorio local, y sincronizaremos puntualmente con el repositorio remoto.

En este artículo vamos a ver como trabajar con repositorios remotos. Además veremos como gestionar estos repositorios remotos, es decir, como añadir, quitar, etc, para sincronizar nuestro repositorio local con uno o varios repositorios remotos.

Repositorios remotos

Tal y como indiqué en el segundo artículo de esta serie sobre crear tu primer repositorio, es posible que o bien lo hayamos hecho de cero:

mkdir ejemplo00
cd ejemplo00
git init

O bien lo hayamos clonado de un repositorio remoto existente:

git clone git@github.com:atareao/ejemplo01.git

En el primero de los casos evidentemente no tendremos repositorio remoto, mientras que en el segundo si.

Para ver que repositorios remotos tenemos, deberemos ejecutar la siguiente orden:

git remote -v

Que en el segundo caso, nos arrojará el siguiente resultado:

origin  git@github.com:atareao/ejemplo01.git (fetch)
origin  git@github.com:atareao/ejemplo01.git (push)

En el caso de que tuviéramos mas de un repositorio remoto aparecerían listados también. Por ejemplo:

launchpad   git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator (fetch)
launchpad   git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator (push)
origin  git@github.com:atareao/my-weather-indicator.git (fetch)
origin  git@github.com:atareao/my-weather-indicator.git (push)

Gestión de repositorios remotos

A lo mejor a priori, puedes pensar que no tiene mucho sentido mantener varios repositorios remotos, pero todo tiene su razón de ser. Por ejemplo, en el caso de Launchpad.net, además de permitir hospedar el código, tiene diferentes sistemas de seguimiento. Además del típico de errores, también tiene uno para especificaciones y nuevas características, otro para ayuda a la comunidad y un sitio específico para traducir aplicaciones a múltiples idiomas.

He sido un fiel seguidor y usuario de Launchpad, pero inicialmente utilizaban otro sistema de control de versiones, Bazaar, y esto es lo que me hizo decantarme por GitHub. Ahora que ha dado opción para utilizar git, supongo que empezaré a utilizar de nuevo Launchpad, pero en la modalidad que estamos viendo aquí, es decir, utilizando dos repositorios remotos. Creo que es la mejor forma de aprovechar las ventajas que nos ofrece cada uno de los dos repositorios.

Añadir nuevos repositorios

Ya hemos visto como se pueden ver los repositorios remotos que tenemos referenciados. Si queremos añadir un repositorio remoto, ejecutaremos la siguiente orden:

git remote add [nombre] [url]

Por ejemplo:

git remote add launchpad git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator

Donde:

  • [nombre] es launchpad
  • [url] es git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator

Eliminar repositorios existentes

Otra situación que se nos puede dar es la necesidad de querer eliminar uno de estos repositorios remotos, sea por la circunstancia que sea. Para hacer esto, ejecutaremos la siguiente orden:

git remote remove [nombre]

Por ejemplo:

git remote remove launchpad

Donde:

  • [nombre] es launchpad en este ejemplo.

Cambiar el nombre a repositorios existentes

Otra circunstancia que se te puede dar es querer cambiar el nombre un determinado repositorio que tienes añadido. Puedes hacerlo a lo bruto, es decir, quitar el repositorio y luego añadirlo, o bien utilizar la siguiente orden:

git remote rename [nombre] [nuevo_nombre]

Por ejemplo:

git remote rename launchpad launchpad_v2

Donde:

  • [nombre] es launchpad en este ejemplo.
  • [nuevo_nombre] es launchpad_v2.

Información de repositorios

Por último, nos queda obtener información de cada uno de los repositorios remotos que hemos añadido a nuestro repositorio local. Para hacer esto, ejecutaremos la siguiente orden:

git remote show [nombre]

Por ejemplo:

git remote show launchpad

Donde:

  • [nombre] es launchpad en este ejemplo.

En el caso que nos ocupa, al ejecutar esta orden, el resultado que nos arroja es el siguiente:

* remote launchpad
  Fetch URL: git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator
  Push  URL: git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator
  HEAD branch: master
  Remote branch:
    master tracked
  Local ref configured for 'git push':
    master pushes to master (up to date)

Sincronizar con los repositorios remotos

Una vez ya dominamos la gestión de los repositorios remotos, vamos a lo que realmente nos interesa que es la sincronización de nuestro repositorio local, con los repositorios remotos.

Descargando de los repositorios remotos

La primera de las operaciones a realizar es obtener la información de los repositorios remotos. Para esto, ejecutaremos la siguiente orden:

git fetch [nombre]

Por ejemplo:

git fetch origin

Donde,

  • [nombre] es origin en este ejemplo.

Para este ejemplo, he modificado directamente en GitHub un archivo. Al ejecutar git remote show origin me muestra la siguiente información:

* remote origin
  Fetch URL: git@github.com:atareao/my-weather-indicator.git
  Push  URL: git@github.com:atareao/my-weather-indicator.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (local out of date)

Indicándonos en la última línea que nuestro repositorio local no está actualizado. Vamos a obtener la información del repositorio remoto, utilizando la orden indicada anteriormente, git fetch origin. Al hacer esto vemos lo siguiente:

remote: Counting objects: 3, done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
De github.com:atareao/my-weather-indicator
   548f4c7..b932d81  master     -> origin/master

Si ahora ejecutamos git status para ver la situación de nuestro repositorio nos encontraremos con el siguiente resultado:

En la rama master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use «git pull» para actualizar su rama local)
nothing to commit, working tree clean

Ahora el repositorio remoto está accesible localmente, pero todavía no lo hemos unido a nuestro repositorio local. De hecho, si revisamos los archivos modificados en remoto en nuestro repositorio local, veremos que no están actualizados. Para actualizarlos debemos ejecutar la orden git pull. En mi caso, ejecuto la siguiente orden:

git pull origin

Y me arroja el siguiente resultado:

Updating 548f4c7..b932d81
Fast-forward
 test.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Si ahora revisamos el contenido de los archivos modificados en remoto, veremos que coinciden con nuestros archivos locales.

Si la rama actual en la que estamos trabajando está configurada para trabajar con la rama remota, en lugar de hacer las dos operaciones secuenciales git fetch y git pull podemos hacerlo de un solo golpe, directamente con git pull. Pero, ¿Que es esto de las ramas?. Esto lo veremos en el próximo artículo.

Subiendo al repositorio remoto

Y ahora, ¿en que situación se encuentra nuestro repositorio local respecto al otro repositorio remoto?. Es decir, al modificar el repositorio local, evidentemente, ha quedado desactualizado el otro repositorio remoto. Para comprobarlo ejecutaremos la orden git remote show launchpad, que nos arroja el siguiente resultado:

* remote launchpad
  Fetch URL: git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator
  Push  URL: git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator
  HEAD branch: master
  Remote branch:
    master tracked
  Local ref configured for 'git push':
    master pushes to master (fast-forwardable)

Como podemos observar en la última línea ha pasado de decir (up to date) a decir (fast-forwardable). Pues vallamos allá, hagamos un push a este repositorio. Esto es tan sencillo como ejecutar la orden:

git push launchpad

Y si de nuevo, volvemos a comprobar el estado del repositorio remoto launchpad ejecutando la orden git remote show launchpad veremos el siguiente resultado:

* remote launchpad
  Fetch URL: git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator
  Push  URL: git+ssh://lorenzo-carbonell@git.launchpad.net/my-weather-indicator
  HEAD branch: master
  Remote branch:
    master tracked
  Local ref configured for 'git push':
    master pushes to master (up to date)

Aquí hemos simplificado, porque la orden correcta es:

git push [nombre] [rama]

Donde:

  • [nombre]es el nombre de nuestro repositorio remotor
  • [rama] es el nombre de la rama con la que queremos sincronizar… (uhmmm otra vez esto de la rama).

Conclusiones

Con este artículo sobre repositorios remotos, y el previo sobre repositorios locales, ya tenemos lo principal para trabajar con git.

En el siguiente artículo, vamos a complicar el asunto y vamos a introducirnos en el mundo de las ramas, que hemos empezado a atisbar en este artículo.

avatar
1 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
0 Comment authors
Git y GitHub. Trabajando con repositorios remotos. | PlanetaLibre Recent comment authors

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

  Subscribe  
más nuevo más antiguo más votado
Notificarme de
trackback

[…] Visitar la fuente original […]