Cómo mover todo un repositorio de Git

¿QUÉ ES GIT?

Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o frontend como Cogito o StGIT. Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux.

El mantenimiento del software Git está actualmente (2009) supervisado por Junio Hamano, quien recibe contribuciones al código de alrededor de 280 programadores.

CARACTERÍSTICAS DE GIT

El diseño de Git se basó en BitKeeper y en Monotone.

El diseño de Git resulta de la experiencia del diseñador de Linux, Linus Torvalds, manteniendo una enorme cantidad de código distribuida y gestionada por mucha gente, que incide en numerosos detalles de rendimiento, y de la necesidad de rapidez en una primera implementación.

Entre las características más relevantes se encuentran:

• Fuerte apoyo al desarrollo no lineal, por ende rapidez en la gestión de ramas y mezclado de diferentes versiones. Git incluye herramientas específicas para navegar y visualizar un historial de desarrollo no lineal. Una presunción fundamental en Git es que un cambio será fusionado mucho más frecuentemente de lo que se escribe originalmente, conforme se pasa entre varios programadores que lo revisan.
• Gestión distribuida. Al igual que Darcs, BitKeeper, Mercurial, SVK, Bazaar y Monotone, Git le da a cada programador una copia local del historial del desarrollo entero, y los cambios se propagan entre los repositorios locales. Los cambios se importan como ramas adicionales y pueden ser fusionados en la misma manera que se hace con la rama local.
• Los almacenes de información pueden publicarse por HTTP, FTP, rsync o mediante un protocolo nativo, ya sea a través de una conexión TCP/IP simple o a través de cifrado SSH. Git también puede emular servidores CVS, lo que habilita el uso de clientes CVS pre-existentes y módulos IDE para CVS pre-existentes en el acceso de repositorios Git.
• Los repositorios Subversion y svk se pueden usar directamente con git-svn.
• Gestión eficiente de proyectos grandes, dada la rapidez de gestión de diferencias entre archivos, entre otras mejoras de optimización de velocidad de ejecución.
• Todas las versiones previas a un cambio determinado, implican la notificación de un cambio posterior en cualquiera de ellas a ese cambio (denominado autenticación criptográfica de historial). Esto existía en Monotone.
• Resulta algo más caro trabajar con ficheros concretos frente a proyectos, eso diferencia el trabajo frente a CVS, que trabaja con base en cambios de fichero, pero mejora el trabajo con afectaciones de código que concurren en operaciones similares en varios archivos.
• Los renombrados se trabajan basándose en similitudes entre ficheros, aparte de nombres de ficheros, pero no se hacen marcas explícitas de cambios de nombre con base en supuestos nombres únicos de nodos de sistema de ficheros, lo que evita posibles, y posiblemente desastrosas, coincidencias de ficheros diferentes en un único nombre.
• Re-almacenamiento periódico en paquetes (ficheros). Esto es relativamente eficiente para escritura de cambios y relativamente ineficiente para lectura si el reempaquetado (con base en diferencias) no ocurre cada cierto tiempo.

Git es el rey del software de control de versiones

1.- ELEMENTOS NECESARIOS PARA ESTE TUTORIAL

• Equipo con GNU/Linux, Windows o MacOS
• Git instalado en local
• Conexión a Internet si los repositorios están en Internet

2.- CLONAR EL REPOSITORIO REMOTO COMPLETO

Para este tutorial, el repositorio "origen" está ubicado en los servidores de GitHub, concretamente en https://github.com/raulprietofdez/repo1 y es un fork (copia) de un repositorio ya pre-existente (k2) dentro de GitHub y queremos moverlo a https://github.com/raulprietofdez/repo2. El procedimiento que vamos a utilizar, se puede realizar entre servidores totalmente diferentes y ubicados en diferentes ubicaciones físicas. En la siguiente imagen se ve el repositorio1 forkeado (copiado) del getk2/k2:

Repositorio1

Lo primero que debemos hacer es clonar el repositorio origen (repo1) a un equipo local/intermedio donde tengamos Git instalado. Para clonar el repositorio, ejecutaremos el siguiente comando:

[raul@debian]$ git clone --mirror git clone https://github.com/raulprietofdez/repo1.git
Cloning into bare repository 'repo1.git'...
remote: Enumerating objects: 23775, done.
remote: Counting objects: 100% (3275/3275), done.
remote: Compressing objects: 100% (1143/1143), done.
remote: Total 23775 (delta 1874), reused 3151 (delta 1834), pack-reused 20500
Receiving objects: 100% (23775/23775), 9.45 MiB | 14.04 MiB/s, done.
Resolving deltas: 100% (13448/13448), done.

Una vez descargado el repositorio "origen" (repo1), podremos ver todas las ramas y tags que hemos descargado con los siguientes comandos:

[raul@debian]$ git branch
* master
[raul@debian]$ git tag

3.- CAMBIAR URL DEL REPOSITORIO

El siguiente paso será, en el equipo donde hemos descargado el repositorio origen, cambiar las URLs para que el repositorio apunte al nuevo repositorio (repo2). Para ello, entraremos dentro del directorio del repositorio descargado (repo1) y con el comando "git remote -v" veremos las URLs del repositorio:

[raul@debian x]$ cd repo1/
[raul@debian repo1]$ git remote -v
origin https://github.com/raulprietofdez/repo1.git (fetch)
origin https://github.com/raulprietofdez/repo1.git (push)

Borraremos las URLs del repositorio con el comando siguiente:

[raul@debian repo1]$ git remote rm origin

De nuevo, con el comando siguiente, veremos que las URLs han desaparecido correctamente:

[raul@debian repo1]$ git remote -v

El siguiente paso será añadir la URL del nuevo repositorio (el repositorio debe existir para los pasos siguientes):

[raul@debian repo1]$ git remote add origin https://github.com/raulprietofdez/repo2.git

Comprobaremos que las URLs se han añadido correctamente con el comando:

[raul@debian repo1]$ git remote -v
origin https://github.com/raulprietofdez/repo2.git (fetch)
origin https://github.com/raulprietofdez/repo2.git (push)

4.- ENVIAR DATOS AL NUEVO REPOSITORIO

Una vez añadidas las URLs del nuevo repositorio (repo2), es momento de enviar todos los datos del equipo local al repositorio remoto (repo2). Para ello, ejecutaremos el comando siguiente e introduciremos las credenciales en caso de ser necesarias:

[raul@debian repo1]$ git push origin --all
Username for 'https://github.com': raulprietofdez
Password for 'https://Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.': 
Enumerating objects: 23775, done.
Counting objects: 100% (23775/23775), done.
Compressing objects: 100% (8168/8168), done.
Writing objects: 100% (23775/23775), 9.45 MiB | 12.97 MiB/s, done.
Total 23775 (delta 13448), reused 23775 (delta 13448)
remote: Resolving deltas: 100% (13448/13448), done.
To https://github.com/raulprietofdez/repo2.git
 * [new branch] master -> master

Con el siguiente comando enviaremos también todos los "tags" desde el repositorio local, al nuevo repositorio (repo2):

[raul@debian repo1]$ git push origin --tags
Username for 'https://github.com': raulprietofdez
Password for 'https://Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.': 
Everything up-to-date

En la imagen siguiente se puede ver el repositorio2:

Repositorio2

Y en esta imagen, se puede ver que repo1 y repo2 son iguales, incluso sus commits, tags y branches...

Comparativa repositorio1 y repositorio2

ENJOY!