Close

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

En Por qué Git, analizamos muchas de las maneras en que Git puede hacer que tu equipo sea más ágil. Una vez que hayas decidido hacer el cambio, el siguiente paso es decidir cómo migrar tu flujo de trabajo de desarrollo existente a Git.

En este artículo se explican algunos de los cambios más importantes que notarás al hacer la transición de tu equipo de SVN a Git. Lo más importante que debes recordar durante el proceso de migración es que Git no es SVN. Para aprovechar todo el potencial de Git, intenta abrirte a nuevas formas de pensar sobre el control de versiones.


Para administradores


La adopción de Git puede llevar desde unos días hasta varios meses, según el tamaño de tu equipo. En esta sección se abordan algunas de las principales preocupaciones de los directores de ingeniería cuando se trata de dar formación sobre Git a los empleados y de migrar repositorios de SVN a Git.

Comandos básicos de Git


Antes se decía que era muy difícil aprender a usar Git. Pero los mantenedores de Git no han dejado de publicar nuevas mejoras, como valores predeterminados más razonables y mensajes de ayuda contextuales que hacen que el proceso de aprendizaje sea mucho más agradable.

Atlassian ofrece una serie completa de tutoriales sobre Git autoguiados, así como seminarios web y sesiones de formación en directo. Todos estos recursos de formación deberían bastar para que tu equipo empiece a usar Git. Para dar los primeros pasos, aquí tienes una lista de comandos básicos de Git para que vayas aprendiendo:

bases de datos
Material relacionado

Cómo mover un repositorio de Git completo

Logotipo de Bitbucket
VER LA SOLUCIÓN

Aprende a usar Git con Bitbucket Cloud

Tarea de Git

Notas

Comandos de Git

Indicar a Git quién eres

Notas

Configura el nombre del autor y la dirección de correo electrónico que se usarán con tus confirmaciones. Ten en cuenta que Git elimina algunos caracteres (por ejemplo, los puntos finales) de user.name.

Comandos de Git

git config --global user.name "Sam Smith"git config --global user.email sam@example.com

Crear un nuevo repositorio local

Notes

 

Comandos de Git

git init

Extraer un repositorio

Notas

Crea una copia de trabajo de un repositorio local:

Comandos de Git

git clone /ruta/a/repositorio

 

Notas

En el caso de un servidor remoto, usa esto:

Comandos de Git

git clone username@host:/path/to/repository

Añadir archivos

Notas

Añade uno o más archivos al entorno de ensayo (índice):

Comandos de Git

git add *

Confirmación

Notas

Confirma los cambios en head (pero aún no en el repositorio remoto):

Comandos de Git

git commit -m "Commit message"

 

Notas

Confirma todos los archivos que hayas añadido con git add y también todos los que hayas modificado desde entonces:

Comandos de Git

git commit -a

Empujar

Notas

Envía los cambios a la rama principal de tu repositorio remoto:

Comandos de Git

git push origin main

Estado

Notas

Obtén una lista de los archivos que has modificado y de los que aún debes añadir o confirmar:

Comandos de Git

git status

Conectarte a un repositorio remoto

Notas

Si no has conectado tu repositorio local a un servidor remoto, añade el servidor para poder enviarle los cambios:

Comandos de Git

git remote add origin

 

Notas

Obtén una lista de todos los repositorios remotos configurados actualmente:

Comandos de Git

git remote -v

Ramas

Notas

Crea una nueva rama y pásate a ella:

Comandos de Git

git checkout -b

 

Notas

Pasa de una rama a otra:

Comandos de Git

git checkout

 

Notas

Obtén una lista de todas las ramas de tu repositorio y averigua en qué rama estás actualmente:

Comandos de Git

rama de git

 

Notas

Elimina la rama de función:

Comandos de Git

git branch -d

 

Notas

Envía la rama al repositorio remoto para que otros puedan usarla:

Comandos de Git

git push origin

 

Notas

Envía todas las ramas al repositorio remoto:

Comandos de Git

git push --all origin

 

Notas

Elimina una rama de tu repositorio remoto:

Comandos de Git

git push origin :

Actualizar desde el repositorio remoto

Notas

Obtén y fusiona los cambios del servidor remoto en tu directorio de trabajo:

Comandos de Git

git pull

 

Notas

Para fusionar una rama diferente en tu rama activa:

Comandos de Git

Git merge

 

Notas

Consulta todos los conflictos de fusión:Consulta los conflictos con el archivo base:Consulta una vista previa de los cambios antes de la fusión:

Comandos de Git

git diff
git diff --base
git diff

 

Notas

Una vez resueltos manualmente los conflictos, marca el archivo modificado:

Comandos de Git

git add

Etiquetas

Notas

Puedes usar etiquetas para marcar un conjunto de cambios importantes, como una publicación:

Comandos de Git

git tag 1.0.0

 

Notas

El ID de confirmación son los primeros caracteres del ID de conjunto de cambios (10 como máximo), y debe ser único. Para obtenerlo, utiliza esto:

Comandos de Git

git log

 

Notas

Envía todas las etiquetas al repositorio remoto:

Comandos de Git

git push --tags origin

Deshacer cambios locales

Notas

Si te equivocas, puedes reemplazar los cambios del árbol de trabajo por el último contenido de head. Los cambios que ya se hayan añadido al índice y los archivos nuevos se mantendrán.

Comandos de Git

git checkout --

 

Notas

Si lo que quieres es eliminar todos tus cambios y confirmaciones locales, obtener el historial más reciente del servidor y dirigir tu rama principal local hacia él, debes hacer esto:

Comandos de Git

git fetch origingit reset --hard origin/main

Buscar

Notas

Busca "foo()" en el directorio de trabajo:

Comandos de Git

git grep "foo()"

Herramientas de migración de Git


Hay varias herramientas disponibles para ayudarte a migrar tus proyectos existentes de SVN a Git, pero antes de elegir cuáles vas a usar debes decidir cómo quieres migrar el código. Tienes estas opciones:

  • Migrar todo tu código base a Git y dejar de usar SVN.
  • No migrar ninguno de tus proyectos existentes a Git y usar Git para los proyectos nuevos.
  • Migrar algunos de sus proyectos a Git mientras sigues usando SVN para otros proyectos.
  • Usar SVN y Git simultáneamente en los mismos proyectos.

Una transición completa a Git limita la complejidad del flujo de trabajo de desarrollo, por lo que esta es la mejor opción. Sin embargo, no siempre es posible hacerlo así en empresas grandes con decenas equipos de desarrollo y quizá cientos de proyectos. En estos casos, un enfoque híbrido es una opción más segura.

La elección de las herramientas de migración depende en gran medida de la estrategia que vaya a aplicarse. A continuación, te presentamos algunas de las herramientas de migración de SVN a Git más habituales.

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.

Para desarrolladores


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.

Conclusión


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.


Compartir este artículo

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Gente que colabora utilizando un muro lleno de herramientas

Blog de Bitbucket

Ilustración de Devops

Ruta de aprendizaje de DevOps

Demostraciones de funciones con expertos de Atlassian del Centro de demostraciones

Cómo funciona Bitbucket Cloud con Atlassian Open DevOps

Suscríbete para recibir el boletín de DevOps

Thank you for signing up