Миграция на Git из централизованного управления версиями

Статья
08/29/2023

Для миграции команды в Git из централизованного управления версиями требуется больше, чем просто обучение новых команд. Для поддержки распределенной разработки Git хранит сведения журнала файлов и ветвей, отличные от централизованной системы управления версиями. Планирование и реализация успешной миграции в Git из централизованной системы управления версиями требует понимания этих фундаментальных различий.

Корпорация Майкрософт помогла перенести множество внутренних команд и клиентов из централизованных систем управления версиями в Git. Этот опыт привел к созданию следующих рекомендаций, основанных на методиках, которые последовательно соответствуют успешному успеху.

Шаги для успешной миграции

Для успешной миграции команды должны:

Оцените текущие инструменты и процессы.
Выберите стратегию ветвления Git.
Определите, следует ли перенести журнал и как выполнить миграцию.
Сохраняйте предыдущую систему управления версиями.
Удалите двоичные файлы, исполняемые файлы и средства из системы управления версиями.
Обучение команд в концепциях и методиках Git.
Проверьте миграцию в Git.

Оценка текущих средств и процессов

Изменение систем управления версиями естественно нарушает рабочий процесс разработки с новыми инструментами и методиками. Это нарушение может быть возможностью улучшить другие аспекты процесса DevOps.

Teams должны принять следующие методики при переходе к новой системе:

Непрерывная интеграция (CI), где каждый проверка активирует сборку и тестовый проход. CI помогает выявлять дефекты рано и обеспечивает надежную сеть безопасности для проектов.
Обязательные проверки кода перед проверка в коде. В модели ветвления Git проверка кода запроса на вытягивание входит в процесс разработки. Проверки кода дополняют рабочий процесс CI.
Непрерывная доставка (CD) для автоматизации процессов развертывания. Для изменения средств управления версиями требуются изменения процесса развертывания, поэтому миграция является хорошим временем для внедрения современного конвейера выпуска.

Выбор стратегии ветвления Git

Перед переносом кода команда должна выбрать стратегию ветвления.

В Git кратковременные ветви тем позволяют разработчикам работать близко к главной ветви и быстро интегрироваться, избегая проблем слияния. Две распространенные стратегии ветви тем — это GitFlow и более простой вариант GitHub Flow.

Git не рекомендует длительные изолированные ветвь компонента, которые, как правило, задерживают слияние до тех пор, пока интеграция не станет сложной. Используя современные методы CD, такие как флаги функций, команды могут быстро интегрировать код в основную ветвь, но по-прежнему оставаться скрытыми от пользователей, пока они не будут завершены.

Команды, которые в настоящее время используют долговременную стратегию ветвь компонента, могут применять флаги функций перед миграцией в Git. Использование флагов функций упрощает миграцию, минимизируя количество ветвей для миграции. Независимо от того, используются ли они ветвь компонента или флаги функций, команды должны документировать сопоставление между устаревшими ветвями и новыми ветвями Git, поэтому все понимают, где зафиксировать свою новую работу.

Определите, следует ли перенести журнал

Teams может быть заманчиво перенести существующий журнал исходного кода в Git. Несколько средств утверждают, что перенос полной истории всех ветвей из централизованного средства в Git. Фиксация Git, как представляется, сопоставляется относительно хорошо с набором изменений или проверка модели, используемой предыдущим средством управления версиями.

Однако это сопоставление имеет некоторые серьезные ограничения.

В большинстве централизованных систем управления версиями ветви существуют в виде папок в репозитории. Например, основная ветвь может быть папкой с именем /trunk, а другие ветви являются папками, такими как /branch/one и /branch/two. В репозитории Git ветви включают весь репозиторий, поэтому сложно выполнить перевод 1:1.
В некоторых системах управления версиями тег или метка — это коллекция, которая может содержать различные файлы в дереве, даже файлы в разных версиях. В Git тег — это моментальный снимок всего репозитория в определенный момент времени. Тег не может представлять подмножество репозитория или объединять файлы в разных версиях.
Большинство систем управления версиями хранят сведения о том, как файлы изменяются между версиями, включая подробные типы изменений, такие как переименование, отмена и откат. Git сохраняет версии в виде моментальных снимков всего репозитория, а метаданные о том, как файлы изменились, недоступны.

Эти различия означают, что полная миграция истории будет потеряна в лучшем случае и, возможно, вводя в заблуждение. Учитывая потерю, задействованные усилия и относительную редкость использования журнала, рекомендуется, чтобы большинство команд избегали импорта истории. Вместо этого команды должны выполнить миграцию чаевых, приведя только моментальный снимок последней версии ветви в Git. Для большинства команд время лучше всего тратить на области миграции, которые имеют более высокую отдачу от инвестиций, таких как улучшение процессов.

Обслуживание старой системы управления версиями

Во время и после миграции разработчикам может по-прежнему потребоваться доступ к предыдущей истории управления версиями. Хотя предыдущий журнал управления версиями становится менее актуальным с течением времени, важно иметь возможность ссылаться на него. Строго регулируемые среды могут иметь определенные юридические и аудитные требования к журналу управления версиями.

Особенно для команд, которые выполняют миграцию только чаевых, настоятельно рекомендуется поддерживать предыдущую систему на неопределенный срок. Установите старую систему управления версиями только для чтения после миграции.

Крупные команды разработки и регулируемые среды могут размещать точечные сворачки в Git, что указывает на старую систему управления версиями. Простой пример — текстовый файл, добавленный в качестве первой фиксации в корне репозитория Git перед миграцией чаевых, указывающий НА URL-адрес старого сервера управления версиями. Если многие ветви переносятся, текстовый файл в каждой ветви должен объяснить, как ветви перенесены из старой системы. При выборе шаблонов также полезно для разработчиков, которые начинают работать над проектом после миграции и не знакомы со старой системой управления версиями.

Удаление двоичных файлов и инструментов

Модель хранения Git оптимизирована для управления текстовыми файлами и исходным кодом, которые являются компактными и высоко сжатыми. Двоичные файлы обычно большие, и после их добавления в репозиторий они остаются в журнале репозитория и в каждом будущем клоне. Из-за того, как Git хранит журнал, разработчики должны избегать добавления двоичных файлов в репозитории, особенно двоичных файлов, которые очень большие или часто изменяются. Миграция в Git — это возможность удалить эти двоичные файлы из базы кода.

Также рекомендуется исключить библиотеки, инструменты и выходные данные сборки из репозиториев. Вместо этого используйте такие системы управления пакетами, как NuGet, для управления зависимостями.

Ресурсы, такие как значки и рисунки, могут соответствовать определенной версии исходного кода. Небольшие, редко изменяемые ресурсы, такие как значки, не будут включать журнал больших двоичных объектов, и их можно включить непосредственно в репозиторий. Чтобы хранить большие или часто изменяющиеся ресурсы, используйте расширение Git Large File служба хранилища (LFS). Дополнительные сведения об управлении большими файлами в GitHub см. в разделе "Управление большими файлами". Сведения об Azure Repos см. в статье "Управление большими файлами" в Git.

Обучение

Одна из самых больших проблем при миграции в Git помогает разработчикам понять, как Git сохраняет изменения и как фиксирует журнал разработки форм. Недостаточно подготовить памятку, которая сопоставляет старые команды с командами Git. Разработчикам необходимо прекратить думать об журнале управления версиями с точки зрения централизованной, линейной модели и понять модель журнала Git и граф фиксации.

Люди учиться разными способами, поэтому следует предоставить несколько типов учебных материалов. Живут, лабораторные занятия с экспертом инструктором хорошо работают для некоторых людей. Книга Pro Git является отличной отправной точкой, которая доступна бесплатно в Интернете.

Доступные бесплатные учебные курсы включают:

Организации должны работать над определением экспертов по Git в командах, предоставлять им возможность помочь другим пользователям и поощрять других членов группы задавать им вопросы.

Проверка миграции

Когда команды обновляют процессы, анализируют свой код и обучают своих членов, пришло время перенести исходный код. Независимо от того, выполняется ли миграция или журнал миграции, важно выполнить одну или несколько тестовых миграций в репозиторий тестов. Прежде чем выполнить окончательную миграцию, убедитесь в том, что:

Все файлы кода переносятся.
Доступны все ветви.
В репозитории нет странных двоичных файлов.
У пользователей есть соответствующие разрешения для получения и отправки.
Сборки успешны, и все тесты проходят.

Перенос кода

Выполните окончательную миграцию в нерабочие часы, в идеале между вехами при наличии естественного простоя. Миграция в конце спринта может вызвать проблемы, пока разработчики пытаются завершить работу. Попробуйте перенести в выходные дни, когда никто не должен проверка в.

Запланируйте переход фирмы из старой системы управления версиями в Git. Попытка параллельного управления несколькими системами означает, что разработчики могут не знать, где или как проверка. Установите старую систему управления версиями только для чтения, чтобы избежать путаницы. Без этой защиты может потребоваться вторая миграция, включающая промежуточные изменения.

Фактический процесс миграции зависит от системы, из которую выполняется миграция. Сведения о миграции из система управления версиями Team Foundation см. в разделе "Миграция из TFVC в Git".

Контрольный список действий по миграции

Рабочие процессы группы:

Определите, как будут выполняться сборки.
Определите, когда будут выполняться тесты.
Разработка процесса управления выпусками.
Перемещение проверок кода в запросы на вытягивание.

Стратегия ветвления:

Выберите стратегию ветвления Git.
Задокументируйте стратегию ветвления, почему она была выбрана и как сопоставляются устаревшие ветви.

Журнал.

Определите, сколько времени будет работать устаревшая система управления версиями.
Определите ветви, которые необходимо перенести.
При необходимости создайте метрики, чтобы помочь инженерам вернуться к устаревшей системе.

Двоичные файлы и инструменты:

Определите, какие двоичные файлы и неустранимые файлы удаляются из репозитория.
Определите подход к большим файлам, например Git-LFS.
Определите подход к доставке средств и библиотек, таких как NuGet.

Обучение:

Определите учебные материалы.
Планирование учебных мероприятий, письменных материалов и видео.
Определите членов команды, чтобы служить местными экспертами Git.

Миграция кода:

Выполните несколько тестов, чтобы обеспечить плавность миграции.
Определите и сообщите о времени переключение.
Создайте репозиторий Git.
Задайте для старой системы доступ только для чтения.
Сначала переносите главную ветвь, а затем все остальные необходимые ветви.