Заключение по git-svn

Утилиты git svn полезны в том случае, если ваша разработка по каким-то причинам требует наличия рабочего Subversion-сервера. Однако, стоит воспринимать их как «функционально урезанный» Git, ибо при использовании всех возможностей Git вы столкнётесь с проблемами в преобразованиях, которые могут сбить с толку вас и ваших коллег. Чтобы избежать неприятностей, старайтесь следовать следующим рекомендациям:

• Держите историю в Git линейной, чтобы она не содержала слияний, сделанных с помощью git merge. Перемещайте всю работу, которую вы выполняете вне основной ветки обратно в неё; не выполняйте слияний.

• Не устанавливайте отдельный Git-сервер для совместной работы. Можно иметь такой сервер для того, чтобы ускорить клонирование для новых разработчиков, но не отправляйте на него ничего, не имеющего записи git-svn-id. Возможно, стоит даже добавить перехватчик pre-receive, который будет проверять каждое изменение на наличие git-svn-id и отклонять коммиты, если они не имеют такой записи.

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

Git и Mercurial

Вселенная распределённых систем контроля версий не заканчивается на Git. На самом деле, существуют и другие системы, каждая со своим подходом к управлению версиями. На втором месте по популярности после Git находится Mercurial и у этих систем много общего.

К счастью, если вам нравится Git, но приходится работать с Mercurial-репозиторием, существует способ использовать Git-клиент для работы с Mercurial. Учитывая тот факт, что Git работает с серверами через концепцию «удалённых репозиториев» (remotes), неудивительно, что работа с Mercurial-репозиторием происходит через своего рода обёртку над «удалённым репозиторием». Проект, добавляющий такую интероперабельность, называется git-remote-hg и расположен по адресу https://github.com/felipec/git-remote-hg.

git-remote-hg

Для начала необходимо установить git-remote-hg. Ничего особенного — просто поместите файл в любое место, откуда он будет виден другим программам, типа:

$ curl -o ~/bin/git-remote-hg \

https://raw.githubusercontent.com/felipec/git-remote-hg/master/git-remote-hg

$ chmod +x ~/bin/git-remote-hg

…предполагая, что ~/bin включён в $PATH. Есть ещё одна зависимость: библиотека mercurial для Python. Если у вас установлен Python, просто выполните:

$ pip install mercurial

(Если же у вас ещё нет Python, пора исправить это: скачайте установщик с https://www.python.org/.)

Ну и наконец понадобится сам клиент Mercurial. Если он ещё не установлен — скачайте и установите с https://www.mercurial-scm.org/.

Теперь можно отжигать! Всё что потребуется — репозиторий Mercurial с которым вы можете работать. К счастью, подойдёт любой, так что мы воспользуемся репозиторием «привет, мир», используемом для обучения работе с Mercurial.

$ hg clone http://selenic.com/repo/hello /tmp/hello

Основы

Теперь, когда у нас есть подходящий «серверный» репозиторий, мы готовы разобрать типичные приёмы работы с Mercurial. Как вы увидите, эти две системы очень похожи, так что всё пройдёт гладко.

Как и всегда, вначале мы клонируем репозиторий:

$ git clone hg::/tmp/hello /tmp/hello-git

$ cd /tmp/hello-git

$ git log --oneline --graph --decorate

* ac7955c (HEAD, origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master, master) Create a makefile

* 65bb417 Create a standard 'hello, world' program

Наверняка вы обратили внимание, что мы использовали обыкновенный git clone. Это потому, что git-remote-hg работает на довольно низком уровне, подобно тому, как в Git реализован HTTP/S протокол (git-remote-hg служит как бы в качестве «помощника» для работы с удалённым репозиторием по новому протоколу (hg), расширяя базовые возможности Git). Подобно Git, Mercurial рассчитан на то, что каждый клиент хранит полную копию репозитория со всей историей, поэтому приведённая выше команда выполняет полное копирование со всей историей и делает это достаточно быстро.

git log показывает два коммита, на последний из которых указывает довольно много ссылок. На самом деле, не все из них реально существуют. Давайте-ка посмотрим, что хранится внутри каталога .git:

$ tree .git/refs

.git/refs

├── heads

│   └── master

├── hg

│   └── origin

│   ├── bookmarks

│   │   └── master

│   └── branches

│   └── default

├── notes

│   └── hg

├── remotes

│   └── origin

│   └── HEAD

└── tags

9 directories, 5 files

git-remote-hg пытается нивелировать различия между Git и Mercurial, преобразовывая форматы за кулисами. Ссылки на объекты в удалённом репозитории хранятся в каталоге refs/hg. Например, refs/hg/origin/branches/default — это Git-ссылка, содержащая SHA-1 ac7955c — коммит на который ссылается ветка master. Таким образом, каталог refs/hg — это что-то типа refs/remotes/origin, с той разницей, что здесь же отдельно хранятся закладки и ветки Mercurial.

Файл notes/hg — отправная точка для выяснения соответствия между хешами коммитов в Git и идентификаторами ревизий в Mercurial. Давайте посмотрим что там:

$ cat notes/hg

d4c10386...

$ git cat-file -p d4c10386...

tree 1781c96...

author remote-hg <> 1408066400 -0800

committer remote-hg <> 1408066400 -0800

Notes for master

$ git ls-tree 1781c96...

100644 blob ac9117f... 65bb417...

100644 blob 485e178... ac7955c...

$ git cat-file -p ac9117f

0a04b987be5ae354b710cefeba0e2d9de7ad41a9

Итак, refs/notes/hg указывает на дерево, которое содержит список других объектов и имён. Команда git ls-tree выводит права доступа, тип, хеш и имя файла для содержимого дерева. Наконец, добравшись до первого элемента дерева, мы обнаружим, что это блоб с названием ac9117f (SHA-1 коммита, на которую указывает ветка master), содержащий 0a04b98 (идентификатор последней ревизии ветки default в Mercurial).

Всё это немного запутанно, но хорошие новости в том, что, по большому счёту, нам не нужно беспокоится об организации данных в git-remote-hg. В целом, работа с Mercurial сервером не сильно отличается от работы с Git сервером.

Ещё одна вещь, которую следует учитывать: список игнорируемых файлов. Mercurial и Git используют очень похожие механизмы для таких списков, но всё же хранить .gitignore в Mercurial репозитории — не самая удачная идея. К счастью, в Git есть механизм игнорирования специфичных для локальной копии репозитория файлов, а формат списка исключений в Mercurial совместим с Git, так что можно просто скопировать .hgignore кое-куда:

$ cp .hgignore .git/info/exclude

Файл .git/info/exclude работает подобно .gitignore, но не фиксируется в истории изменений.