Я хотел бы узнать рекомендуемый способ переместить наш код из репозитория SVN в репозиторий GIT, чтобы мы перешли к команде разработчиков и начали использовать GIT.
Можем ли мы сделать переход и сохранить все фиксации в репозитории SVN?
Кроме того, наша команда довольна SVN в настоящее время, но они не знают, что ветвление в GIT намного проще, чем SVN, где я могу найти практический пример, который доказывает силу GIT при ветвлении?
Эрик Раймонд (esr) создал reposurgeon, "командный интерпретатор для выполнения сложных операций редактирования в истории управления версиями". Инструмент включает скрипты для различных целей, включая очистку результатов конверсий VCS. Проверьте это из https://gitlab.com/esr/reposurgeon.
Начиная с версии 2.0, он включает поддержку для чтения дампов для SVN для полного и идиоматического перевода в Git, Mercurial и т.д.; см. http://esr.ibiblio.org/?p=4071. Reposurgeon был использован для преобразования нескольких больших проектов в Git, в том числе Emacs, чей репозиторий, ESR говорит, "большой, сложный в структуре веток и достаточно старый, чтобы начать работу как репозиторий CVS. Эта последняя часть имеет значение, поскольку некоторые из самые уродливые проблемы перевода, скрывающиеся в предыстории проектов Subversion, - это странные последовательности операций Subversion (включая комбинации операций копирования ветвей), сгенерированных cvs2svn."
(Инструмент git -svn, включенный в Git, будет обрабатывать многие репозитории Subversion, включая ветки. Его довольно часто используют, особенно команды, которые находятся в процессе выполнения преобразования, поскольку он позволяет Git (см. ESRs Не конвертировать репозитории с помощью git -svn!, где он обсуждает недостатки git -svn в качестве инструмента преобразования.)
Что касается вашего второго вопроса, это не ветвление, где сила Git настолько полезна (хотя Git по крайней мере такой же мощный, как Subversion в этом отношении); его когда дело доходит до слияния тех ветвей, которые Git светит. Прочтите Git Community Book, особенно раздел в главе 3 под названием " Основное ветвление и слияние" и раздел в главе 7 под названием " Расширенное слияние.
Поскольку уже есть много людей, работающих с git-svn, я бы сказал, что это очень возможно. Следующая команда довольно хорошо известна:
git svn clone -s http://svn/repo
В соответствии с руководство (проверено локально), это сохранит "багажник, теги и ветки".
Обновление Apr 2014
Существует инструмент под названием Svn2Git, который делает довольно хорошую работу по упрощению этого процесса. Документация по проекту Github довольно хороша. (Требуется Ruby)
Стоит отметить, что в то время как git -svn по умолчанию использует только путь, который вы указываете, а не ветки, теги и соединительные линии. Svn2git - это противоположность. По умолчанию он будет искать туловище, ветки и метки под этим путем, и вы должны использовать --nobranches или --notags, чтобы он не искал их (хотя это может свести на нет преимущества svn2git).
Как только вы перейдете к Git, я предлагаю вам переместить всех и остаться с помощью Git. Это сложнее, но переход будет стоить того. Github.com поддерживает доступ к репо с помощью клиента Subversion (но вы можете потерять мощность ветвления Git), и это может быть хорошим зазором.
Когда вы используете метод ниже для перемещения, все текущие фиксации останутся в репозитории Subversion. Возможно, вы сможете выполнить одностороннюю синхронизацию из репо Subversion в репозиторий Git, но другой способ очень быстро усложняется. Я бы не рекомендовал пытаться синхронизировать в любом случае и просто переводить все одноразовые.
Git ветвление мощное, но не все есть Git. Наличие полной истории на местном уровне означает, что вы можете делать все, что вы можете сделать с Subversion, но без необходимости обращаться к серверу. Просмотр и поиск истории, отмена изменений, локализация, разветвление локально становятся намного быстрее. Git также сжимает данные, поэтому проверка Subversion (которая включает только последнюю версию) заканчивается примерно таким же размером, как и Git checkout (включая полную историю). Кроме того, поскольку данные сжимаются при передаче, то нажатие и вытягивание происходит намного быстрее. Не нажимайте Git ветки, поместите все в Git.
git svn.Во-первых, клонируйте репо Subversion. Это может занять некоторое время.
git svn clone http://www.example.com/svn-repo/projectA/trunk/
Где http://www.example.com/svn-repo/ - это URL-адрес репозитория Subversion, а projectA/trunk/ - это путь, который вы хотите скопировать в Git.
Если у вас есть стандартный макет, например projectA/trunk, projectA/branches/ и projectA/tags/, чем вы можете добавить --stdlayout и клонировать из каталога вверху, как этот
git svn clone --stdlayout http://www.example.com/svn-repo/projectA/ projectA.git-svn
И, если у вас есть папка с соединительными линиями, ветками и тегами, именованными по-разному, то выше, вы даете git svn clone пользовательские имена для каждого.
git svn clone --trunk my-trunk --branches my-branches --tags my-tags http://www.example.com/svn-repo/projectA/ projectA.git-svn
После этого все, что вам нужно сделать, это нажать на удаленный репозиторий Git с помощью --mirror.
cd projectA.git-svn
git push --mirror [email protected]:Account/projectA.git
На этом этапе вы должны сделать репозиторий Subversion доступным только для чтения, чтобы люди не пытались совершить переход к удаленному местоположению.
Репо может быть полностью преобразовано, включая теги и все ветки с помощью git svn clone.
Там некоторые настройки, чтобы получить теги правильные, см. эту ссылку для получения дополнительной информации.
Эта тема была рассмотрена здесь в SO хотя бы один раз раньше:
Как импортировать ветки svn и теги в git -svn?
Безопасный и плавный подход к миграции с Svn на Git заключается в использовании SubGit - серверный инструмент Git/Svn, Можно установить SubGit в репозиторий Subversion и продолжать использовать как Subversion, так и Git одновременно, пока процесс миграции длится.
Отказ от ответственности: я разработчик SubGit, который с удовольствием использует SubGit уже полгода.
Я переместил наш репозиторий CVS некоторое время назад на git, сначала преобразовывая в subversion, а затем в git. Это хорошо работает при использовании для этого правильного инструментария.
См. Самый надежный способ конвертировать CVS-репозиторий, содержащий проекты Eclipse, в git?
Кроме того, когда это делается, будьте аккуратно протестированы.
Что касается ветвления git, это не умная часть. Преимущество возникает, когда вам нужно объединить ветки.
Джон Альбин написал несколько хороших сценариев здесь и здесь который сделает для вас всю конверсию (включая преобразование автора). Сценарии не идеальны (у меня были некоторые hickups с несколькими ветвями и особенно с внешними svn).
Atlassian на самом деле написал руководство по миграции svn на git (и у них также есть хорошие руководства на этих страницах).
git очень мощный, но есть одно предостережение: до сих пор git не имеет ничего такого простого, как svn: externals. Существуют альтернативы (git поддерево и git подмодули), но они никогда не работают так же интуитивно, как svn externals (но это для другого вопроса: оглянитесь вокруг stackoverflow, вы найдете много вопросов, относящихся к этой теме)