gitcvs-миграция

gitcvs-миграция — Git для пользователей CVS

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

Требуется некоторое базовое знакомство с Git. Достаточно будет пройти gittutorial[7] и gitglossary[7].

Предположим, общий репозиторий настроен в /pub/repo.git на хосте foo.com. Затем, как отдельный участник коммита, вы можете клонировать общий репозиторий по SSH с помощью:

$ git clone foo.com:/pub/repo.git/ my-project
$ cd my-project

и начать работу. Эквивалент cvs update это

$ git pull origin

который объединяет любые работы, которые могли быть выполнены другими с момента клонирования. Если в вашем рабочем каталоге есть несохраненные изменения, сохраните их перед запуском git pull.

Вы можете обновить общий репозиторий со своими изменениями, сначала сохранив свои изменения, а затем используя команду git push:

$ git push origin master

чтобы «отправить» эти коммиты в общий репозиторий. Если кто-то другой обновил репозиторий в более позднее время, git push, как и cvs commit, будет жаловаться, в этом случае необходимо подтянуть любые изменения перед повторной попыткой отправки.

В команде git push выше мы указываем имя удаленного ветвления для обновления (master). Если мы этого не сделаем, git push пытается обновить все ветви в удалённом репозитории, которые имеют такое же имя, как ветвь в локальном репозитории. Поэтому последняя push может быть выполнена с помощью любой из:

$ git push origin
$ git push foo.com:/pub/project.git/

при условии, что общий репозиторий не имеет других ветвей, кроме master.

Мы предполагаем, что вы уже создали Git-репозиторий для своего проекта, возможно, созданный с нуля или из tar-архива (см. gittutorial[7]), или импортированный из уже существующего CVS-репозитория (см. следующий раздел).

Предположим, ваш существующий репозиторий находится в /home/alice/myproject. Создайте новый «голый» репозиторий (репозиторий без рабочего каталога) и импортируйте в него свой проект:

$ mkdir /pub/my-repo.git
$ cd /pub/my-repo.git
$ git --bare init --shared
$ git --bare fetch /home/alice/myproject master:master

Далее, предоставьте каждому участнику команды права чтения/записи в этот репозиторий. Один из простых способов сделать это — предоставить всем участникам команды доступ по SSH к машине, на которой размещен репозиторий. Если вы не хотите давать им полный доступ к оболочке на машине, есть ограниченная оболочка, которая позволяет пользователям только выполнять Git-отправки и -получения; см. git-shell[1].

Поместите всех коммитеров в одну группу и сделайте репозиторий доступным для записи этой группой:

$ chgrp -R $group /pub/my-repo.git

Убедитесь, что коммитеры имеют umask не более 027, чтобы каталоги, которые они создают, были доступны для записи и поиска другими членами группы.

Сначала установите версию 2.1 или выше cvsps с https://github.com/andreyvit/cvsps и убедитесь, что она находится в вашей переменной PATH. Затем перейдите в каталог с рабочей копией CVS проекта, который вас интересует, и запустите git-cvsimport[1]:

$ git cvsimport -C <destination> <module>

Это поместит Git-архив указанного CVS-модуля в каталог <destination>, который будет создан при необходимости.

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

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

Импорт инкрементальный, поэтому если вы запустите его снова через месяц, он загрузит любые CVS-обновления, которые были сделаны в это время. Для этого вы не должны изменять импортированные ветви; вместо этого создавайте новые ветви для собственных изменений и объединяйте импортированные ветви по мере необходимости.

Если вам нужен общий репозиторий, вам нужно создать голое клонирование импортированного каталога, как описано выше. Затем используйте импортированный каталог как еще один клон разработки для целей объединения инкрементальных импортов.

Git позволяет указывать скрипты, называемые «хуками», которые будут выполняться в определённые моменты. Например, вы можете использовать их, чтобы отправлять все коммиты в общий репозиторий на список рассылки. См. githooks[5].

Вы можете настроить более подробные разрешения с помощью хуков обновления. См. Управление доступом к ветвям с помощью хуков обновления.

Также возможно предоставить настоящий доступ к CVS-репозиторию Git, чтобы разработчики всё ещё могли использовать CVS; см. git-cvsserver[1] для получения подробностей.

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

Например, вы можете выбрать одного человека для ведения основного публичного репозитория проекта. Другие разработчики затем клонируют этот репозиторий и работают каждый в своём клоне. Когда у них есть набор изменений, которыми они довольны, они просят администратора получить из ветки, содержащей изменения. Администратор проверяет их изменения и объединяет их в основной репозиторий, из которого другие разработчики получают необходимые обновления. Ядро Linux и другие проекты используют варианты этой модели.

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

gittutorial[7], gittutorial-2[7], gitcore-tutorial[7], gitglossary[7], giteveryday[7], Справочник пользователя Git