Compartir a través de

Migración a Git desde el control de versiones centralizado

La migración de un equipo a Git desde el control de versiones centralizado 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 orientaciones basadas en las prácticas que se realizan con éxito de manera coherente.

Pasos para una migración correcta

Para una migración correcta, los equipos deben:

  • Evalúe las herramientas y los procesos actuales.
  • Seleccione una estrategia de bifurcación de Git.
  • Decida si va a migrar el historial y cómo migrarlo.
  • Mantenga el sistema de control de versiones anterior.
  • Quite archivos binarios, ejecutables y herramientas del control de código fuente.
  • Entrenamiento de equipos en conceptos y prácticas de Git.
  • Pruebe la migración a Git.

Evaluación de las herramientas y procesos actuales

El cambio de sistemas de control de versiones interrumpe naturalmente 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.

Teams debe considerar la posibilidad de adoptar las siguientes prácticas a medida que se migran al nuevo sistema:

  • Integración continua (CI), donde cada comprobación desencadena una compilación y una prueba superada. CI ayuda a identificar los defectos temprano y proporciona una red de seguridad sólida para los proyectos.

  • Revisiones de código necesarias antes de integrar 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.

Selección de 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 integrarse 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 que la integración sea difícil. Mediante el uso de técnicas de CD modernas como feature flags, los equipos pueden integrar código en la rama principal rápidamente, pero aún mantienen ocultas las características en progreso a los usuarios hasta que estén completas.

Los equipos que actualmente usan una estrategia de rama de características de larga duración pueden adoptar 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 flujos de funcionalidades, los equipos deben documentar la asignación entre ramas heredadas y nuevas ramas de Git, de modo que todos sepan dónde deben confirmar su nuevo trabajo.

Decidir si se va a migrar el historial

Es posible que teams se sientan tentados a migrar su historial de código fuente existente a Git. Varias herramientas reclaman 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 comprobación 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, una etiqueta o etiqueta es una colección que puede contener varios archivos en el árbol, incluso archivos en distintas versiones. En Git, una etiqueta es una instantánea de todo el repositorio en un momento dado específico. 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 nombre, recuperar y revertir. Git almacena versiones como instantáneas del estado del repositorio completo, y los metadatos sobre cómo cambiaron los archivos no están disponibles.

Estas diferencias significan que una migración completa del historial será con pérdida en el mejor de los casos y, posiblemente, puede llevar a confusiones. Dada la pérdida, el esfuerzo implicado y la rareza relativa del uso del historial, se recomienda que la mayoría de los equipos eviten importar el historial. En su lugar, los equipos deben realizar una migración de punta, incorporando solo una instantánea de la versión de rama más reciente en Git. Para la mayoría de los equipos, el tiempo se invierte mejor en áreas de la migración que tienen una mayor rentabilidad de la inversión, como mejorar 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 acceso al historial de control de versiones anterior. Aunque el historial de control de versiones anterior se vuelve menos relevante a lo largo del tiempo, todavía es importante poder hacer referencia a él. Los entornos altamente regulados pueden tener requisitos legales y de auditoría específicos para el historial de control de versiones.

Especialmente para los equipos que realizan solo una migración de propinas, se recomienda mantener el sistema anterior indefinidamente. Establezca el sistema de control de versiones anterior en solo lectura una vez que haya migrado.

Los equipos de desarrollo grandes y los entornos regulados pueden colocar breadcrumbs en Git que señalen 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 del tip, que apunta a la URL del servidor anterior del sistema de control de versiones. Si muchas ramas se migran, un archivo de texto de cada rama debe explicar cómo se migran las ramas del sistema anterior. Las rutas de navegación también son útiles para los desarrolladores que empiezan a trabajar en un proyecto una vez que ha sido migrado y no se habían familiarizado con el antiguo sistema de control de versiones.

Eliminación de archivos binarios y herramientas

El modelo de almacenamiento de Git está optimizado para el control de versiones de archivos de texto y el código fuente, 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 que son 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 que son grandes o cambian con frecuencia, use la extensión Git Large File Storage (LFS). Para obtener más información sobre cómo administrar archivos grandes en GitHub, consulte Administración de archivos grandes. Para Azure Repos, consulte Administración y almacenamiento de archivos grandes en Git.

Proporcionar entrenamiento

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, lineal y comprender el modelo de historial de Git y el gráfico de confirmación.

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 se incluyen de forma gratuita:

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

Prueba de la migración

Una vez que los equipos actualicen sus procesos, analicen su código y entrenen a sus miembros, es el momento de migrar el código fuente. Tanto si realiza una migración de tip como una migración de 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:

  • Todos los archivos de código se migran.
  • Todas las ramas están disponibles.
  • No hay archivos binarios sueltos en el repositorio.
  • Los usuarios tienen los permisos adecuados para extraer y empujar.
  • Las compilaciones se realizan correctamente y se superan todas las pruebas.

Migración del código

Realice la migración final durante las 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 el registro de entrada.

Planee una transición firme del sistema de control de versiones anterior a Git. Intentar operar varios sistemas en paralelo significa que los desarrolladores pueden no saber dónde o cómo realizar registros. Configure el sistema de control de versiones anterior como de solo lectura para evitar confusiones. Sin esta protección, puede ser necesaria una segunda migración que incluya cambios provisionales.

El proceso de migración real varía en función del sistema desde el que se va a migrar. 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:

  • Determina cómo se ejecutarán las compilaciones.
  • Decida cuándo se ejecutarán las pruebas.
  • Desarrollar un proceso de administración de versiones.
  • Trasladar las revisiones de código a pull requests.

Estrategia de bifurcació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.

History:

  • Decida cuánto tiempo debe mantener el control de versiones heredado en ejecución.
  • Identifique las ramas que necesitan 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 no reconocibles que se van a quitar del repositorio.
  • Decida un enfoque para archivos grandes, como Git-LFS.
  • Decida un enfoque para entregar herramientas y bibliotecas, como NuGet.

Adiestramiento:

  • Identificar materiales de entrenamiento.
  • Planear eventos de entrenamiento, materiales escritos y vídeos.
  • Identifique a los miembros del equipo para que actúen como expertos locales de Git.

Migración de código:

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

Pasos siguientes

  • Last updated on