Hola de nuevo 
Desde hace un par de semanas vengo preparando cuidadosamente ciertos cambios de cierto calado en el proyecto. Es más una reorganización general de código que una reescritura de la aplicación, pero al final las cosas se harán muy diferentes.
Como la aplicación debe poder seguir estando disponible e incluso es muy probable que tenga que añadir alguna funcionalidad o corregir algún bug sobre la versión que tengo ahora mismo, el sistema de control de versiones que uso ahora, el svn de la forja de rediris se me queda algo corto, de manera que pensé seriamente en cambiarme a git.
Cuando supe de la existencia del comando git-svn me decidí del todo, y esta tarde mismo he realizado el cambio. El repositorio svn seguirá disponible, y de vez en cuando actualizaré el código alojado allí, pero operaré en git, que es más cómodo para crear una rama aparte y realizar cambios faraónicos pudiendo volver rápidamente a master para arreglar cualquier cosilla.
Por ahora he creado un repositorio en gitorious a la espera de acabar en algún sitio algo más serio.
Una pequeña receta sobre como lo he hecho:
¿Cómo pasar un repositorio bajo svn a git en dos cómodos pasos?
- Instala git-svn
$ sudo apt-get install git-svn
- Clona el repositorio svn creando uno git
$ git svn clone <url-repo-svn>
Esto nos habrá creado un repositorio git con todos los commits realizados en el repositorio svn. Si nos fijamos en el fichero de configuración en .git/config pone lo siguiente:
[svn-remote "svn"] url = <url-repo-svn> fetch = :refs/remotes/git-svn
¿Cómo trabajar con él?
- svn update ahora es git svn rebase
git svn rebaseSi sabes algo de git, te verás extrañado de que no se haga merge. Esto es porque se sigue usando la lógica de svn. Cuando haces svn-update lo que se hace es aplicar parches a tu trabajo actual. Bien pues rebase hace algo parecido, aplica a todos tus commits locales, los cambios que ha habido en el servidor
- svn commit ahora es git svn dcommit
git svn dcommitEste tipo de commit tiene un inconveniente enorme, y es que NO se manejan commits de merge. Es decir, no puedes mandar al repositorio svn commits resultado de mezclar dos ramas, tienes que hacer rebase siempre.
Eso último de no poder hacer merges en el historial que se envie a svn le quita bastante gracia a trabajar con git, de manera que me parece que no lo usaré directamente.
Supongo que más de uno ya estará pensando que lo que puedo hacer es mantener un branche llamado svn y hacer rebase allí de todo lo que hago en las demas, manteniendo un master habitual y teniendo una rama especial para sincronizar. No parece ser lo más agradable del mundo, y a final acabaré con un historial en svn algo falseado con respecto al que vaya creando en git, pero creo que es lo que haré, y bueno menos da una piedra
Espero que le sea útil a alguien.
Un saludo.
Puedes hacer una reunión sin crear un commit de reunión en Git. Git no podrá después contar con la información de que has hecho una reunión, sino que verá un commit muy grande con los cambios que has hecho en esa rama, pero bueno, si pones un mensaje bueno te valdrá. Si ambas ramas están subidas a SVN (ya que has clonado con “git svn clone -s”, sigues una estructura de ramas de SVN “normal” y has creado la rama en SVN con “git svn branch”), deberías intentar primero hacer una reunión con SVN, ya que así Git sí verá que has hecho una reunión “de verdad”.
Pero bueno, si la reunión de Subversion te da más trabajo de la cuenta (cosa que suele ocurrir), puedes “aplastar” todos los cambios hechos en una rama y traértelos a un nuevo commit en tu rama actual con:
git merge –squash miotrarama
A continuación creas tu commit, y reunión que no es una reunión hecha
. A unas malas, también puedes traerte commits de una rama a otra con:
git cherry-pick sha1_del_commit_a_traerse
Es un poco casero, pero puede sacarte del apuro en algunos casos.
Comentario por Antonio García — abril 19, 2010 @ 9:09 pm
Hola Antonio,
Gracias por la sabiduría concentrada, creo que git merge –squash es exactamente lo que necesitaba.
Manteniendo mi rama svn puedo hacer merge –squash con master, y a continuación enviar un commit muy grande al svn sin información de merge.
Lo único malo que tiene es que acabaré enviando commits enormes al svn como resultado del merge –squash, pero como lo que pretendo es simplemente mantener el código actualizado en rediris y no tanto un historial saneado, me da igual.
Lo de crear branches de verdad en svn, es de lo que vengo huyendo, tuve un par de experiencias mareantes y creo que desde aquellos aciagos días, le cogí algo de tirria a vimdiff. No way.
Lo de cherry-pick también me podría servir, dado que con merge –squash tengo un commit enorme con el contenido de un merge, llevarlo de un sitio a otro podría estar bien.
Llega un pelín tarde pues ya tengo el siguiente post escrito, pero para el siguiente a ese, prometo documentar como funciona (si consigo que lo haga xD).
Muchas gracias
Comentario por Javier Santacruz López-Cepero — abril 19, 2010 @ 9:24 pm
[...] y como comenté al final de la entrada anterior, no podemos mandar desde git al svn commits resultado de un merge entre branches. De manera que [...]
Pingback por Trabajando efectivamente con svn y git « IdiginBPEL — abril 19, 2010 @ 9:49 pm