- 
  1. Введение- 1.1 О системе контроля версий
- 1.2 Краткая история Git
- 1.3 Что такое Git?
- 1.4 Командная строка
- 1.5 Установка Git
- 1.6 Первоначальная настройка Git
- 1.7 Как получить помощь?
- 1.8 Заключение
 
- 
  2. Основы Git
- 
  3. Ветвление в Git- 3.1 О ветвлении в двух словах
- 3.2 Основы ветвления и слияния
- 3.3 Управление ветками
- 3.4 Работа с ветками
- 3.5 Удалённые ветки
- 3.6 Перебазирование
- 3.7 Заключение
 
- 
  4. Git на сервере- 4.1 Протоколы
- 4.2 Установка Git на сервер
- 4.3 Генерация открытого SSH ключа
- 4.4 Настраиваем сервер
- 4.5 Git-демон
- 4.6 Умный HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Git-хостинг
- 4.10 Заключение
 
- 
  5. Распределённый Git
- 
  6. GitHub
- 
  7. Инструменты Git- 7.1 Выбор ревизии
- 7.2 Интерактивное индексирование
- 7.3 Припрятывание и очистка
- 7.4 Подпись
- 7.5 Поиск
- 7.6 Перезапись истории
- 7.7 Раскрытие тайн reset
- 7.8 Продвинутое слияние
- 7.9 Rerere
- 7.10 Обнаружение ошибок с помощью Git
- 7.11 Подмодули
- 7.12 Создание пакетов
- 7.13 Замена
- 7.14 Хранилище учётных данных
- 7.15 Заключение
 
- 
  8. Настройка Git- 8.1 Конфигурация Git
- 8.2 Атрибуты Git
- 8.3 Хуки в Git
- 8.4 Пример принудительной политики Git
- 8.5 Заключение
 
- 
  9. Git и другие системы контроля версий- 9.1 Git как клиент
- 9.2 Переход на Git
- 9.3 Заключение
 
- 
  10. Git изнутри- 10.1 Сантехника и Фарфор
- 10.2 Объекты Git
- 10.3 Ссылки в Git
- 10.4 Pack-файлы
- 10.5 Спецификации ссылок
- 10.6 Протоколы передачи данных
- 10.7 Обслуживание репозитория и восстановление данных
- 10.8 Переменные окружения
- 10.9 Заключение
 
- 
  A1. Приложение A: Git в других окружениях- A1.1 Графические интерфейсы
- A1.2 Git в Visual Studio
- A1.3 Git в Visual Studio Code
- A1.4 Git в Eclipse
- A1.5 Git в IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.6 Git в Sublime Text
- A1.7 Git в Bash
- A1.8 Git в Zsh
- A1.9 Git в PowerShell
- A1.10 Заключение
 
- 
  A2. Приложение B: Встраивание Git в ваши приложения- A2.1 Git из командной строки
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
 
- 
  A3. Приложение C: Команды Git- A3.1 Настройка и конфигурация
- A3.2 Клонирование и создание репозиториев
- A3.3 Основные команды
- A3.4 Ветвление и слияния
- A3.5 Совместная работа и обновление проектов
- A3.6 Осмотр и сравнение
- A3.7 Отладка
- A3.8 Внесение исправлений
- A3.9 Работа с помощью электронной почты
- A3.10 Внешние системы
- A3.11 Администрирование
- A3.12 Низкоуровневые команды
 
10.5 Git изнутри - Спецификации ссылок
Спецификации ссылок
На протяжении всей книги мы использовали довольно простые соответствия между локальными ветками и ветками в удалённых репозиториях, но всё может быть чуть сложнее. Допустим, вы добавили удалённый репозиторий:
$ 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 git@github.com: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.
| Примечание | Вы не можете использовать спецификации ссылок, чтобы получать данные из одного репозитория, а отправлять в другой. Для реализации такого поведения обратитесь к разделу Поддержание GitHub репозитория в актуальном состоянии главы 6. | 
Удаление ссылок
Кроме того, спецификации ссылок можно использовать для удаления ссылок на удалённом сервере:
$ git push origin :topicТак как спецификация ссылки задаётся в виде <src>:<dst>, то, пропуская <src>, мы указываем Git, что указанную ветку на удалённом сервере надо сделать пустой, что приводит к её удалению.
Начиная с версии Git v1.7.0, можно использовать следующий синтаксис:
$ git push origin --delete topic