De SVN a Git: prepárate para la migración

Scripts de migración de Atlassian

Si quieres cambiar de golpe a Git, los scripts de migración de Atlassian son una buena opción para ti. Estos scripts proporcionan todas las herramientas necesarias para convertir de forma fiable tus repositorios SVN en repositorios de Git. Además, gracias al historial nativo de Git que se obtiene, no tendrás que lidiar con ninguna incidencia de interoperabilidad de SVN a Git después del proceso de conversión.

Puedes consultar un completo recorrido técnico para usar estos scripts y convertir todo tu código base en una colección de repositorios de Git. En este recorrido se explica todo, desde la extracción de la información de autor de SVN hasta la reorganización de estructuras de repositorio SVN no estándar.

Plugin SVN Mirror for Stash (ahora Bitbucket)

SVN Mirror for StashSVN Mirror for Stash es un plugin de Bitbucket que permite mantener fácilmente código base híbrido que funciona tanto con SVN como con Git. A diferencia de los scripts de migración de Atlassian, SVN Mirror for Stash permite usar Git y SVN simultáneamente en el mismo proyecto durante el tiempo que quieras.

Esta solución intermedia es una opción fantástica para las empresas más grandes. Permite ir adoptando Git paulatinamente, ya que los distintos equipos pueden migrar sus flujos de trabajo en el momento que más les convenga.

¿Qué es git-svn?

La herramienta git-svn es una interfaz entre un repositorio de Git local y un repositorio SVN remoto. Con ella, los desarrolladores pueden escribir código y crear confirmaciones de forma local con Git para luego enviarlas a un repositorio SVN central de forma similar a las confirmaciones de SVN. Esto debe ser algo temporal, pero resulta útil cuando se está valorando pasar de SVN a Git.

git svn es una buena opción si no estás seguro de hacer el cambio a Git y quieres que algunos de tus desarrolladores prueben los comandos de Git sin hacer una migración completa. También es perfecto para la fase de formación: en lugar de cambiar de golpe, tu equipo puede ir habituándose con los comandos de Git locales sin preocuparse por los flujos de trabajo de colaboración.

Ten en cuenta que git svn solo se debe usar de forma temporal durante el proceso de migración. Esto se debe a que depende de SVN para el back-end y, por tanto, no puede aprovechar las funciones de Git más potentes, como la ramificación o los flujos de trabajo de colaboración avanzados.

Estrategias de implementación

La migración del código base solamente es una parte de la adopción de Git. También debes pensar cómo presentarás Git a las personas que trabajan con ese código base. Los consultores externos, los expertos en Git internos y los equipos piloto son los tres pilares básicos para que tu equipo de desarrollo se pase a Git.

Consultores de Git externos

Los consultores de Git pueden encargarse del proceso de migración por ti por un módico precio. Esto tiene la ventaja de que obtienes un flujo de trabajo de Git a la medida de tu equipo sin tener que dedicar tu tiempo a conseguirlo. También pone a tu disposición recursos de formación de expertos mientras tu equipo aprende a usar Git. Los Partners de Atlassian son expertos en la migración de SVN a Git y un buen recurso para buscar un consultor de Git.

Por otro lado, diseñar e implementar un flujo de trabajo de Git por tu cuenta es una excelente manera de que tu equipo comprenda el funcionamiento interno de su nuevo proceso de desarrollo. Esto evita que el equipo se sienta perdido cuando el consultor ya no esté.

Expertos en Git internos

Un experto en Git es un desarrollador de tu empresa al que le encanta la idea de empezar a usar Git. Es una buena opción para las empresas con una sólida cultura de desarrollo y programadores a los que les guste ser los pioneros. La idea es que uno de tus ingenieros se convierta en un experto en Git para que pueda diseñar un flujo de trabajo de Git adaptado a tu empresa y hacer de consultor interno cuando llegue el momento de hacer la transición del resto del equipo a Git.

En comparación con un consultor externo, esto tiene la ventaja de que la empresa adquiere experiencia en Git a nivel interno. Sin embargo, formar a un experto en Git requiere más tiempo y se corre el riesgo de elegir un flujo de trabajo de Git inadecuado o de implementarlo mal.

Equipos piloto

La tercera opción para pasarse a Git es probarlo en un equipo piloto. Esto va muy bien si tienes un equipo pequeño que está trabajando en un proyecto relativamente aislado. Y funciona aún mejor si el equipo piloto cuenta con consultores externos y expertos en Git internos.

Esto tiene la ventaja de que se requiere la implicación de todos y, además, reduce el riesgo de elegir un flujo de trabajo incorrecto, ya que durante la creación del nuevo proceso de desarrollo se recibe feedback de todo el equipo. En otras palabras, esta opción permite juntar todas las piezas antes que si un consultor o un campeón diseñan el nuevo flujo de trabajo por su cuenta.

Por otro lado, el uso de un equipo piloto implica más tiempo de preparación y formación inicial, ya que no hay un desarrollador creando el nuevo flujo de trabajo, sino que todo un equipo puede ser menos productivo durante el tiempo que tarde en acostumbrarse al nuevo flujo de trabajo. Sin embargo, no hay duda de que este inconveniente inicial compensa a largo plazo.

Seguridad y permisos

El control de acceso es un aspecto de Git que exige replantear la forma de trabajar con el código base.

En SVN, todo el código base suele almacenarse en un único repositorio central y se limita el acceso a diferentes equipos o personas por carpeta. Sin embargo, en Git no es posible hacerlo así, ya que los desarrolladores deben recuperar todo el repositorio para poder trabajar en él. Por lo general, no se puede recuperar un subconjunto del repositorio, cosa que sí se puede hacer con SVN. Los permisos solo se pueden conceder para repositorios de Git completos.

Esto significa que tienes que dividir tu gran y monolítico repositorio SVN en varios repositorios de Git pequeños. Esto lo vivimos de primera mano en Atlassian cuando nuestro equipo de desarrollo de Jira migró a Git. Todos nuestros plugins de Jira solían almacenarse en un único repositorio SVN, pero después de la migración, cada uno terminó en su propio repositorio.

Ten en cuenta que Git está diseñado para integrar de forma segura las contribuciones de código de miles de desarrolladores de Linux independientes, por lo que seguro que hay una forma de configurar el control de acceso que tu equipo necesita, aunque puede que para ello tengas que redefinir tu ciclo de compilación.

Si te preocupa mantener las dependencias entre tu nuevo grupo de repositorios de Git, puede que te resulte útil disponer de una capa de gestión de dependencias además de Git. Una capa de gestión de dependencias te ayudará con los tiempos de compilación porque, a medida que un proyecto crece, necesitas almacenamiento en caché para acelerar este proceso. Puedes encontrar una lista de herramientas recomendadas de capa de gestión de dependencias para todos los recursos tecnológicos en este artículo: Git y dependencias de proyectos.

Un repositorio para cada desarrollador

Como desarrollador, el cambio más importante al que tendrás que adaptarte es la naturaleza descentralizada de Git. En lugar de un único repositorio central, cada desarrollador tiene su propia copia de todo el repositorio. Esto cambia drásticamente la forma de colaborar con los otros programadores.

En lugar de extraer un repositorio SVN con svn checkout y obtener una copia de trabajo, se clona todo el repositorio de Git en el equipo local con git clone.

La colaboración se produce al mover ramas entre repositorios con git push, git fetch o git pull. Normalmente se comparte a nivel de rama en Git, pero también puede hacerse a nivel de confirmación, de manera similar a SVN. En Git, sin embargo, una confirmación representa el estado completo de todo el proyecto en lugar de las modificaciones del archivo. Como puedes usar ramas tanto en Git como en SVN, la diferencia más importante es que puedes confirmar localmente con Git sin tener que compartir tu trabajo. Esto te permite experimentar con más libertad y trabajar con más eficacia sin conexión, y acelera casi todos los comandos relacionados con el control de versiones.

Aun así, es importante entender que un repositorio remoto no es un enlace directo al repositorio de otra persona. No es más que un marcador que evita que tengas que volver a escribir la URL completa cada vez que interactúes con un repositorio remoto. Trabajarás en un entorno aislado hasta que envíes o incorpores los cambios de una rama en un repositorio remoto.

El otro gran cambio para los usuarios de SVN es el concepto de repositorios «locales» y «remotos». Los repositorios locales están en tu equipo local, y todos los demás se denominan repositorios remotos. El objetivo principal de un repositorio remoto es dar acceso a tu código al resto del equipo sin que haya ninguna actividad de desarrollo en él. Los repositorios locales residen en tu equipo local y es donde se desarrolla todo el software.

No tengas miedo de crear ramificaciones o de fusionar

En SVN, confirmas el código editando los archivos en tu copia de trabajo y, luego, ejecutas svn commit para enviar el código al repositorio central. Todos los demás pueden incorporar esos cambios en sus propias copias de trabajo con svn update. Las ramas de SVN generalmente se reservan para los aspectos de mayor envergadura y duración de un proyecto, ya que la fusión es un procedimiento peligroso que puede causar problemas en el proyecto.

El flujo de trabajo de desarrollo básico de Git es muy diferente. En lugar de estar atado a una sola línea de desarrollo (por ejemplo, trunk/), todo gira en torno a la ramificación y la fusión.

Cuando quieras empezar a hacer cualquier cosa en Git, crea y extrae una nueva rama con git checkout -b. Así obtendrás una línea de desarrollo exclusiva en la que podrás escribir código sin preocuparte de que afecte a nadie más de tu equipo. Si cometes un error irreparable, solo tienes que eliminar la rama con git branch -d. Y si haces algo útil, puedes hacer una solicitud de incorporación de cambios para fusionarlo en la rama main.

Posibles flujos de trabajo de Git

Al elegir un flujo de trabajo de Git, es importante tener en cuenta las necesidades de tu equipo. Un flujo de trabajo sencillo puede acelerar y flexibilizar el desarrollo, mientras que un flujo de trabajo más complejo puede garantizar más coherencia y control sobre el trabajo en curso. Puedes adaptar y combinar los enfoques generales siguientes según tus necesidades y las diferentes funciones del equipo. Así, un desarrollador principal puede usar ramas de función mientras un contratista trabaja en una bifurcación, por ejemplo.

• Un flujo de trabajo centralizado es lo más parecido a los procesos de SVN habituales, por lo que es una buena opción para empezar.
• Partiendo de esa idea, el uso de un flujo de trabajo de rama de función permite a los desarrolladores mantener aislado su trabajo en curso y proteger las ramas compartidas importantes. Las ramas de función también son la base para gestionar los cambios a través de solicitudes de incorporación de cambios.
• Un flujo de trabajo de Gitflow es una extensión más formal y estructurada para las ramas de función, lo que lo convierte en una excelente opción para equipos más grandes con ciclos de publicación bien definidos.
• Por último, puedes plantearte un flujo de trabajo de bifurcación si necesitas el máximo aislamiento y control sobre los cambios, o si tienes muchos desarrolladores que contribuyen a un repositorio.

Pero si lo que realmente quieres es sacar el máximo partido de Git como equipo profesional, debes valorar el flujo de trabajo de ramas de función. Se trata de un flujo de trabajo verdaderamente distribuido, muy seguro, increíblemente escalable y totalmente ágil.

Pasar tu equipo a Git puede parecer complicado, pero no tiene por qué serlo. En este artículo hemos hablado de algunas de las opciones más habituales para migrar tu código base existente, implementar Git en los equipos de desarrollo y ocuparte de la seguridad y los permisos. También hemos visto los desafíos más importantes para los que deben prepararse los desarrolladores durante el proceso de migración.

Esperamos que hayas adquirido una base sólida para introducir el desarrollo distribuido en tu empresa, sea cual sea su tamaño o sus prácticas de desarrollo actuales.