Migrar a Git desde el control de versiones centralizado

  • Artículo

Para la migración de un equipo a Git desde el control de versiones centralizado se requiere algo más que aprender nuevos comandos. Para admitir el desarrollo distribuido, Git almacena el historial de archivos y la información de rama de forma diferente a un sistema de control de versiones centralizado. Planear e implementar una migración correcta a Git desde un sistema de control de versiones centralizado requiere comprender estas diferencias fundamentales.

Microsoft ha ayudado a migrar muchos equipos internos y clientes de sistemas de control de versiones centralizados a Git. Esta experiencia ha generado las siguientes instrucciones basadas en la práctica que tuvieron un funcionamiento coherente.

Pasos para la migración correcta

Para una migración correcta, los equipos deben:

  • Evaluar las herramientas y los procesos actuales.
  • Seleccionar una estrategia de bifurcación de Git.
  • Decidir si van a migrar el historial y cómo migrarlo.
  • Mantener el sistema de control de versiones anterior.
  • Quitar archivos binarios, ejecutables y herramientas del control de código fuente.
  • Entrenar a los equipos en los conceptos y prácticas de Git.
  • Realizar una prueba de la migración a Git.

Evaluar las herramientas y los procesos actuales

El cambio de sistemas de control de versiones naturalmente interrumpe el flujo de trabajo de desarrollo con nuevas herramientas y prácticas. Esta interrupción puede ser una oportunidad para mejorar otros aspectos del proceso de DevOps.

Los equipos deben considerar la posibilidad de adoptar las siguientes prácticas cuando migran al nuevo sistema:

  • Integración continua (CI), donde cada registro desencadena una compilación y la superación de una prueba. CI ayuda a identificar los defectos de forma temprana y proporciona una red de seguridad sólida para los proyectos.

  • Revisiones de código necesarias antes de registrar el código. En el modelo de bifurcación de Git, la revisión del código de solicitud de incorporación de cambios forma parte del proceso de desarrollo. Las revisiones de código complementan el flujo de trabajo de CI.

  • Entrega continua (CD) para automatizar los procesos de implementación. El cambio de las herramientas de control de versiones requiere cambios en el proceso de implementación, por lo que una migración es un buen momento para adoptar una canalización de versión moderna.

Seleccionar una estrategia de bifurcación de Git

Antes de migrar el código, el equipo debe seleccionar una estrategia de bifurcación.

En Git, las ramas de temas de corta duración permiten a los desarrolladores trabajar cerca de la rama principal e integrar rápidamente, evitando problemas de combinación. Dos estrategias de rama de temas comunes son GitFlow y una variación más sencilla, GitHub Flow.

Git desaconseja las ramas de características aisladas de larga duración, que tienden a retrasar las combinaciones hasta un punto en que la integración resulta difícil. Mediante el uso de técnicas modernas de CD como las marcas de características, los equipos pueden integrar código en la rama principal rápidamente, pero continuar ocultando las características en curso de los usuarios hasta que se completen.

Los equipos que actualmente usan una estrategia de rama de características de larga duración pueden adoptar las marcas de características antes de migrar a Git. El uso de marcas de características simplifica la migración minimizando el número de ramas que se van a migrar. Tanto si usan ramas de características como marcas de características, los equipos deben documentar la asignación entre ramas heredadas y nuevas ramas de Git, de modo que todo el mundo comprenda dónde confirmar su nuevo trabajo.

Decidir si se va a migrar el historial

Es posible que los equipos se sientan tentados a migrar su historial de código fuente existente a Git. Varias herramientas dicen migrar un historial completo de todas las ramas de una herramienta centralizada a Git. Parece que una confirmación de Git se asigna relativamente bien al conjunto de cambios o al modelo de registro que usó la herramienta de control de versiones anterior.

Sin embargo, esta asignación tiene algunas limitaciones graves.

  • En la mayoría de los sistemas de control de versiones centralizados, las ramas existen como carpetas en el repositorio. Por ejemplo, la rama principal podría ser una carpeta denominada /trunk, y otras ramas son carpetas como /branch/one y /branch/two. En un repositorio de Git, las ramas incluyen todo el repositorio, por lo que una traducción 1:1 es difícil.

  • En algunos sistemas de control de versiones, un tag o label es una colección que puede contener varios archivos del árbol, incluso archivos en distintas versiones. En Git, un tag es una instantánea de todo el repositorio en un momento dado. Una etiqueta no puede representar un subconjunto del repositorio ni combinar archivos en distintas versiones.

  • La mayoría de los sistemas de control de versiones almacenan detalles sobre la forma en que cambian los archivos entre versiones, incluidos tipos de cambio específicos, como cambiar el nombre, recuperar y revertir. Git almacena las versiones como instantáneas del repositorio completo y los metadatos sobre la forma en que cambiaron los archivos no están disponibles.

Estas diferencias significan que una migración completa del historial en el mejor de los casos será defectuosa y, posiblemente, engañosa. Dado lo anterior, el esfuerzo que implica y la rareza relativa del uso del historial, se recomienda a la mayoría de los equipos que eviten importar el historial. En su lugar, los equipos deben realizar una migración sugerida, llevando solo una instantánea de la versión de rama más reciente a Git. Para la mayoría de los equipos, es mejor invertir el tiempo en áreas de la migración que tienen una mayor rentabilidad, como la mejora de los procesos.

Mantenimiento del sistema de control de versiones anterior

Durante y después de una migración, es posible que los desarrolladores todavía necesiten tener acceso al historial de control de versiones anterior. Aunque el historial de control de versiones anterior se vuelve menos relevante con el paso del tiempo, sigue siendo importante poder consultarlo. Los entornos altamente regulados pueden tener requisitos legales y de auditoría específicos para el historial de control de versiones.

Especialmente en el caso de los equipos que realizan solo una migración sugerida, se recomienda mantener el sistema anterior indefinidamente. Establezca el sistema de control de versiones anterior en solo lectura después de migrar.

Los equipos de desarrollo grandes y los entornos regulados pueden colocar rutas de navegación en Git que apunten al antiguo sistema de control de versiones. Un ejemplo sencillo es un archivo de texto agregado como la primera confirmación en la raíz de un repositorio de Git, antes de la migración sugerida, que apunta a la dirección URL del servidor de control de versiones anterior. Si se migran muchas ramas, se debe explicar en un archivo de texto en cada rama cómo se migraron las ramas del sistema anterior. Las rutas de navegación también son útiles para los desarrolladores que empiezan a trabajar en un proyecto después de migrarlo y no están familiarizados con el sistema de control de versiones anterior.

Eliminación de archivos binarios y herramientas

El modelo de almacenamiento de Git está optimizado para los archivos de texto y el código fuente del control de versiones, que son compactos y altamente comprimibles. Los archivos binarios suelen ser grandes y, una vez agregados a un repositorio, permanecen en el historial del repositorio y en cada clon futuro. Debido a la forma en que Git almacena el historial, los desarrolladores deben evitar agregar archivos binarios a repositorios, especialmente archivos binarios muy grandes o que cambian a menudo. La migración a Git es una oportunidad para quitar estos archivos binarios del código base.

También se recomienda excluir bibliotecas, herramientas y resultados de compilación de los repositorios. En su lugar, use sistemas de administración de paquetes como NuGet para administrar las dependencias.

Es posible que los recursos como iconos y ilustraciones necesiten alinearse con una versión específica del código fuente. Los recursos pequeños y con poca frecuencia modificados, como los iconos, no sobredimensionan el historial, y puede incluirlos directamente en un repositorio. Para almacenar recursos grandes o que cambian con frecuencia, use la extensión de Almacenamiento de archivos de gran tamaño (LFS) de Git. Para obtener más información sobre cómo administrar archivos de gran tamaño en GitHub, consulte Administración de archivos de gran tamaño. Para Azure Repos, consulte Administrar y almacenar archivos de gran tamaño en Git.

Aprendizaje

Uno de los mayores desafíos para migrar a Git es ayudar a los desarrolladores a comprender cómo Git almacena los cambios y cómo confirma el historial de desarrollo de formularios. No es suficiente preparar una hoja de referencia rápida que asigna comandos antiguos a comandos de Git. Los desarrolladores deben dejar de pensar en el historial de control de versiones en términos de un modelo centralizado y lineal, y comprender el modelo de historial y el gráfico de confirmación de Git.

Las personas aprenden de diferentes maneras, por lo que debe proporcionar varios tipos de materiales de entrenamiento. La formación basada en laboratorio con un instructor experto funciona bien para algunas personas. El libro Pro Git es un excelente punto de partida que está disponible gratis en línea.

Entre los cursos prácticos disponibles de forma gratuita se incluyen:

Las organizaciones deben trabajar para identificar a los expertos de Git en los equipos, capacitarlos para ayudar a los demás y animar a otros miembros del equipo a formularles preguntas.

Prueba de la migración

Una vez que los equipos actualicen sus procesos, analicen su código y entrenen a sus miembros, será el momento de migrar el código fuente. Tanto si realiza una migración sugerida como si migra el historial, es importante realizar una o varias migraciones de prueba en un repositorio de pruebas. Antes de realizar una migración final, asegúrese de que:

  • Se migren todos los archivos de código.
  • Estén disponibles todas las ramas.
  • No haya archivos binarios dispersos en el repositorio.
  • Los usuarios tengan los permisos adecuados para capturar e insertar.
  • Las compilaciones se realicen correctamente y se superen todas las pruebas.

Migrar el código

Realice la migración final durante horas no laborables, idealmente entre hitos cuando haya tiempo de inactividad natural. La migración al final de un sprint puede provocar problemas mientras los desarrolladores intentan finalizar el trabajo. Intente migrar durante un fin de semana, cuando nadie necesite hacer registros.

Planee una transición firme del sistema de control de versiones anterior a Git. Intentar operar varios sistemas en paralelo significa que es posible que los desarrolladores no sepan dónde o cómo registrar. Establezca el sistema de control de versiones anterior en solo lectura para ayudar a evitar confusiones. Sin esta protección, puede ser necesaria una segunda migración que incluya los cambios intermedios.

El proceso de migración real varía en función del sistema desde el que se realiza la migración. Para obtener información sobre la migración desde el control de versiones de Team Foundation, consulte Migración de TFVC a Git.

Lista de comprobación para la migración

Flujos de trabajo de equipo:

  • Determine cómo se ejecutarán las compilaciones.
  • Decida cuándo se ejecutarán las pruebas.
  • Desarrolle un proceso de administración de versiones.
  • Mueva las revisiones de código a solicitudes de incorporación de cambios.

Estrategia de ramificación:

  • Elija una estrategia de bifurcación de Git.
  • Documente la estrategia de bifurcación, por qué se seleccionó y cómo se asignan las ramas heredadas.

Historial:

  • Decida cuánto tiempo debe mantener en ejecución el control de versiones heredado.
  • Identifique las ramas que es necesario migrar.
  • Si es necesario, cree rutas de navegación para ayudar a los ingenieros a volver al sistema heredado.

Archivos binarios y herramientas:

  • Identifique los archivos binarios y los archivos que no se pueden comparar que hay que quitar del repositorio.
  • Decida un enfoque para archivos grandes, como Git-LFS.
  • Decida un enfoque para entregar herramientas y bibliotecas, como NuGet.

Formación:

  • Identifique los materiales de entrenamiento.
  • Planee eventos de entrenamiento, materiales escritos y vídeos.
  • Identifique a los miembros del equipo que actuarán como expertos locales de Git.

Migración del código:

  • Realice varias ejecuciones de prueba para asegurarse de que la migración se realizará sin problemas.
  • Identifique y comunique un tiempo de transición.
  • Cree el nuevo repositorio Git.
  • Establezca el sistema antiguo en solo lectura.
  • Migre primero la rama principal y, a continuación, cualquier otra rama necesaria.

Pasos siguientes