Skip to content

Latest commit

 

History

History
145 lines (109 loc) · 8.47 KB

refspec.asc

File metadata and controls

145 lines (109 loc) · 8.47 KB
Raw

Спецификации ссылок

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

$ git remote add origin https://github.com/schacon/simplegit-progit

Эта команда добавляет секцию в файл .git/config, в которой заданы имя удалённого репозитория (origin), его URL и спецификация ссылок для извлечения данных:

[remote "origin"]
	url = https://github.com/schacon/simplegit-progit
	fetch = +refs/heads/*:refs/remotes/origin/*

Формат спецификации следующий: опциональный `, далее пара `<src>:<dst>`, где `<src>` -- шаблон ссылок в удалённом репозитории, а `<dst>` -- соответствующий шаблон локальных ссылок. Символ ` сообщает Git, что обновление необходимо выполнять даже в том случае, если оно не является простым смещением.

По умолчанию, после выполнения git remote add origin, Git забирает все ссылки из refs/heads/ на сервере, и записывает их в refs/remotes/origin/ локально. Таким образом, если на сервере есть ветка master, историю данной ветки можно получить, выполнив любую из следующих команд:

$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master

Все эти команды эквивалентны, так как Git развернёт каждую запись до refs/remotes/origin/master.

Если хочется, чтобы Git забирал при обновлении только ветку master, а не все доступные на сервере, можно изменить соответствующую строку в конфигурации:

fetch = +refs/heads/master:refs/remotes/origin/master

Эта настройка будет использоваться по умолчанию при вызове git fetch для данного удалённого репозитория. Если же вам нужно изменить спецификацию всего раз, можно задать конкретное соответствие веток в командной строке. Например, чтобы получить данные из ветки master из удалённого репозитория в локальную origin/mymaster, можно выполнить:

$ git fetch origin master:refs/remotes/origin/mymaster

Можно задать несколько спецификаций за один раз. Получить данные нескольких веток из командной строки можно так:

$ git fetch origin master:refs/remotes/origin/mymaster \
	 topic:refs/remotes/origin/topic
From [email protected]:schacon/simplegit
 ! [rejected]        master     -> origin/mymaster  (non fast forward)
 * [new branch]      topic      -> origin/topic

В данном случае слияние ветки master выполнить не удалось, поскольку слияние не было простым смещением вперёд. Такое поведение можно изменить, добавив перед спецификацией знак +.

В конфигурационном файле также можно задавать несколько спецификаций для получения обновлений. Чтобы каждый раз получать обновления веток master и experiment из репозитория origin, добавьте следующие строки:

[remote "origin"]
	url = https://github.com/schacon/simplegit-progit
	fetch = +refs/heads/master:refs/remotes/origin/master
	fetch = +refs/heads/experiment:refs/remotes/origin/experiment

Начиная с версии Git 2.6.0 можно указывать шаблоны спецификаций, соответствующие нескольким веткам:

fetch = +refs/heads/qa*:refs/remotes/origin/qa*

Для достижения аналогичного результата можно так же использовать пространства имён (или каталоги). Если ваша QA команда использует несколько веток для своей работы и вы хотите получать только ветку master и все ветки команды QA, то можно добавить в конфигурацию следующее:

[remote "origin"]
	url = https://github.com/schacon/simplegit-progit
	fetch = +refs/heads/master:refs/remotes/origin/master
	fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*

Если у вас сложный рабочий процесс при котором все команды — разработчики, QA и специалисты по внедрению — ведут работы в одном репозитории, вы можете разграничить их с помощью пространств имён.

Спецификации ссылок для отправки данных на сервер

Здорово, что можно получать данные по ссылкам в отдельных пространствах имён, но нам же ещё надо сделать так, чтобы команда QA сначала смогла отправить свои ветки в пространство имён qa/. Мы решим эту задачу, используя спецификации ссылок для команды push.

Если команда QA хочет отправлять изменения из локальной ветки master в qa/master на удалённом сервере, они могут использовать такой приём:

$ git push origin master:refs/heads/qa/master

Если же они хотят, чтобы Git автоматически делал так при вызове git push origin, можно добавить в конфигурационный файл значение для push:

[remote "origin"]
	url = https://github.com/schacon/simplegit-progit
	fetch = +refs/heads/*:refs/remotes/origin/*
	push = refs/heads/master:refs/heads/qa/master

Аналогично, это приведёт к тому, что при вызове git push origin локальная ветка master будет по умолчанию отправляться в удалённую ветку qa/master.

Note

Вы не можете использовать спецификации ссылок, чтобы получать данные из одного репозитория, а отправлять в другой. Для реализации такого поведения обратитесь к разделу ch06-github.asc главы 6.

Удаление ссылок

Кроме того, спецификации ссылок можно использовать для удаления ссылок на удалённом сервере:

$ git push origin :topic

Так как спецификация ссылки задаётся в виде <src>:<dst>, то, пропуская <src>, мы указываем Git, что указанную ветку на удалённом сервере надо сделать пустой, что приводит к её удалению.

Начиная с версии Git v1.7.0, можно использовать следующий синтаксис:

$ git push origin --delete topic