Git es una herramienta para trackear cambios en cualquier conjunto de archivos, generalmente utilizado para coordinar el trabajo entre equipos de programadores durante el desarrollo del software. Sus objetivos incluyen la velocidad, la integridad de los datos y la compatibilidad con flujos de trabajo no lineales distribuidos (miles de sucursales paralelas que se ejecutan en diferentes sistemas).
Todos los que nos dedicamos a la programación usamos a diario git o herramientas similares de control de versiones. En este post vamos a explicar un escenario de trabajo bastante habitual: cómo conectar un proyecto a más de 1 repositorio.

Cómo conectar un proyecto a más de 1 repositorio

Vamos a imaginar que tenemos un proyecto en la carpeta /home/raulsanchez/workspace/proyecto ya sincronizado con un repositorio de bitbucket git@bitbucket.org:sinapsis-team/proyecto.git
En este repositorio tenemos 2 ramas de trabajo: master & staging. Si miramos el fichero de configuración de git tendríamos la información del repositorio y sus ramas:
raulsanchez@raulsanchez:~/workspace/proyecto$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote «origin«]
url = git@bitbucket.org:sinapsis-team/proyecto.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch «master»]
remote = origin
merge = refs/heads/master
[branch «staging»]
remote = origin
merge = refs/heads/staging
Ahora queremos añadir otro repositorio de código git@bitbucket.org:sinapsis-team/otro_proyecto.git
El comando para ello sería:
git remote add newremote git@bitbucket.org:sinapsis-team/otro_proyecto.git
Y si volvemos al fichero de configuración de git ahora se habrá añadido esto:
[remote «newremote«]
url = git@bitbucket.org:sinapsis-team/otro_proyecto.git
fetch = +refs/heads/*:refs/remotes/newremote/*
Para complicarlo un poco, vamos a suponer que en este otro repositorio, y en realidad sería lo habitual, tenemos las mismas ramas de trabajo: master & staging
Entonces, ¿cómo sabrá git qué rama «master» debe descargar si hacermos un «git checkout master» a secas?
Una solución muy cómoda es utilizar alias en nuestra configuración local, vamos a llamar «remote-master» a la rama «master» del repositorio «newremote», así la tendremos diferenciada de la rama «master» del repositorio original:
git switch -c remote-master newremote/master
Y si volvemos al fichero de configuración de git ahora se habrá añadido esto
[branch «remote-master»]
remote = newremote
merge = refs/heads/master
Y ahora ya no tendríamos problema para movernos entre las ramas de los repositorios
Si queremos descargar «master» del repositorio original haríamos un «git checkout master» y si queremos descargar «master» del segundo repositorio haríamos un «git checkout remote-master»