Поделиться через

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

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

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

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

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

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

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

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

Командам следует принять следующие практики при переходе на новую систему:

  • Непрерывная интеграция (CI), при которой каждая фиксация активирует сборку и тестирование. CI помогает выявлять дефекты рано и обеспечивает надежную сеть безопасности для проектов.

  • Обязательные проверки кода перед проверкой кода. В модели ветвления Git проверка кода pull request является частью процесса разработки. Проверки кода дополняют рабочий процесс CI.

  • Непрерывная доставка (CD) для автоматизации процессов развертывания. Для изменения средств управления версиями требуются изменения процесса развертывания, поэтому миграция является хорошим временем для внедрения современного конвейера выпуска.

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

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

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

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

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

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

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

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

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

  • В некоторых системах управления версиями тег или метка — это коллекция, которая может содержать различные файлы в дереве, даже файлы в разных версиях. В Git тег — это моментальный снимок всего репозитория в определенный момент времени. Тег не может представлять подмножество репозитория или объединять файлы в разных версиях.

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

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

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

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

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

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

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

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

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

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

Предоставление обучения

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

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

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

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

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

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

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

Перенос кода

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

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

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

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

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

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

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

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

History:

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

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

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

Тренировка:

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

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

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

Дальнейшие шаги

  • Last updated on