Подготовка к миграции из SVN в Git

Скрипты миграции Atlassian

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

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

Плагин SVN Mirror for Stash (ныне Bitbucket)

SVN Mirror для StashSVN Mirror для Stash — это плагин Bitbucket, позволяющий без труда обслуживать гибридную базу кода, с которой можно работать в SVN и Git. В отличие от скриптов миграции Atlassian, с плагином SVN Mirror для Stash системы Git и SVN можно использовать вместе на любом этапе проекта.

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

Что такое Git-SVN?

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

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

Обратите внимание, что работа с git-svn — это лишь один из этапов миграции. Этот инструмент опирается на SVN для работы c серверной частью и не позволяет использовать более мощные возможности Git, такие как ветвление или расширенные процессы совместной работы.

Стратегии развертывания

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

Внешние консультанты по Git

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

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

Внутренние сторонники Git

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

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

Пилотные команды

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

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

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

Безопасность и права доступа

Контроль доступа — это один из аспектов Git, где требуется кардинально переосмыслить управление базой кода.

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

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

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

Если вы беспокоитесь о сопровождении зависимостей в новом наборе репозиториев Git, вам может пригодиться уровень управления зависимостями в сочетании с Git. Уровень управления зависимостями поможет сократить время сборки, поскольку по мере роста проекта вам потребуется так называемое «кэширование» для ускорения сборки. Список рекомендуемых инструментов для уровня управления зависимостями с учетом стека технологий приводится в полезной статье «Git и зависимости проекта».

Репозиторий для каждого разработчика

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

Вместо того чтобы получить репозиторий SVN командой svn checkout и создать его рабочую копию, вы клонируете весь репозиторий Git на локальную машину командой git clone.

Совместная работа происходит путем перемещения веток между репозиториями с помощью команд git push, git fetch и git pull. В Git разработчики обычно делятся ветками, но это можно делать и на уровне коммитов, как в SVN. Однако в Git коммит представляет собой полное состояние всего проекта, а не изменения файла. Ветки можно использовать как в Git, так и в SVN, но важное различие заключается в том, что в Git можно выполнять локальные коммиты, не делясь своей работой. Это позволяет разработчикам свободно экспериментировать и более эффективно действовать в автономном режиме, а также ускоряет работу практически всех команд, задействованных в управлении версиями.

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

Другое важное изменение для пользователей SVN — это «локальные» и «удаленные» репозитории. Локальные репозитории находятся на локальном компьютере, а все остальные называются удаленными. Последний нужен прежде всего затем, чтобы сделать ваш код доступным для остальных участников команды, поэтому там не ведется активная разработка. Локальный репозиторий находится на вашей локальной машине, где вы и создаете ПО.

Не бойтесь ветвления или слияния

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

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

Начиная работу в Git, вы создаете новую ветку и переключаетесь на нее с помощью команды git checkout -b. Таким образом вы получите отдельное направление разработки, где сможете писать код, не беспокоясь о том, что ваша работа помешает другим участникам команды. Если вы непоправимо испортите код, можно будет просто удалить ветку командой git branch -d. Написав какой-либо полезный код, вы создадите запрос pull и объедините этот код с основной веткой.

Возможные варианты рабочих процессов Git

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

• Централизованный рабочий процесс очень похож на обычные процессы SVN, поэтому вы можете начать с него.
• Рабочий процесс с функциональными ветками развивает эту идею: с его помощью разработчики могут изолировать текущую работу и защитить важные общие ветки. Кроме того, функциональные ветки создают основу для управления изменениями с помощью запросов pull.
• Рабочий процесс Git-flow — это более формализованное и структурированное расширение процесса с функциональными ветками, поэтому он идеально подходит для больших команд с четкими циклами релизов.
• И наконец, если вам нужна максимальная изоляция и контроль над изменениями или если в один репозиторий поступает код от нескольких разработчиков, попробуйте рабочий процесс с форками.

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

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

Надеемся, теперь у вас есть прочная основа для внедрения распределенной разработки в своей компании, независимо от ее размера и текущих методов разработки.