Este artículo pretende dejar un par de apuntes de cómo configurar un remote para un repositorio Git en diferentes escenarios.

Surge a raíz de un problema que mi amigo Oriol Puig | experimentó hace unos días, donde tuvo la necesidad de configurar un remote no estándar para un proyecto que está desarrollando actualmente.

Remote estándar (bidireccional)

Un remote de Git, por defecto, se crea de forma bidireccional.

Esto es, se define un mismo repositorio remoto tanto para lectura (fetch/pull) como escritura (push).

Crear este tipo de remotes no es complicado.

> git remote add estandar <url>
> git remote -v
estandar  <url> (fetch)
estandar  <url> (push)

Este tipo de remote permite tanto leer como escribir cambios desde el repositorio local. Nada nuevo para aquellos que usamos o hemos usado Git.

Remote de sólo lectura

No obstante, en alguna ocasión nos puede interesar disponer de un repositorio clonado que sólo pueda ‘leer’ del repositorio remoto.

Para ello, hay que ejecutar los siguientes comandos.

> git remote add readonly <url>
> git remote -v
readonly  <url> (fetch)
readonly  <url> (push)
> git remote set-url --push readonly <invalid_URL>
> git remote -v
readonly  <url> (fetch)
readonly  <invalid_URL> (push)

Esta configuración evitará que, por ejemplo, podamos hacer push por error al repositorio remoto, o que tengamos configurado un repositorio cuya única finalidad es precisamente ser punto de sólo lectura.

Remote de sólo escritura

Igual que en el caso anterior, es posible que pueda interesarnos tener un repositorio clonado que sólo pueda ‘escribir’, de manera que no se puedan sincronizar los cambios desde el mismo en el repositorio clonado.

En este caso, los comandos a ejecutar son los siguientes.

> git remote add writeonly <invalid_URL>
> git remote -v
writeonly  <invalid_URL> (fetch)
writeonly  <invalid_URL> (push)
> git remote set-url --push writeonly <url>
> git remote -v
writeonly  <invalid_url> (fetch)
writeonly  <url> (push)

Este escenario permite ignorar completamente los commit generados en el repositorio remoto, permitiendo publicar, por ejemplo, ramas de trabajo que no serán sincronizadas directamente en nuestro repositorio local en caso de que éstas cambien en remoto.