-
1. Вступ
- 1.1 Про систему контролю версій
- 1.2 Коротка історія Git
- 1.3 Основи Git
- 1.4 Git, зазвичай, тільки додає дані
- 1.5 Три стани
- 1.6 Командний рядок
- 1.7 Інсталяція Git
- 1.8 Початкове налаштування Git
- 1.9 Отримання допомоги
- 1.10 Підсумок
-
2. Основи Git
- 2.1 Створення Git-репозиторія
- 2.2 Запис змін до репозиторія
- 2.3 Перегляд історії комітів
- 2.4 Скасування речей
- 2.5 Взаємодія з віддаленими сховищами
- 2.6 Теґування
- 2.7 Псевдоніми Git
- 2.8 Підсумок
-
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 Варіанти стороннього хостингу
- 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 Збереження посвідчення (credential)
- 7.15 Підсумок
-
8. Налаштування Git
-
9. Git and Other Systems
- 9.1 Git як клієнт
- 9.2 Міграція на Git
- 9.3 Підсумок
-
10. Git зсередини
- 10.1 Кухонні та парадні команди
- 10.2 Об’єкти Git
- 10.3 Посилання Git
- 10.4 Файли пакунки
- 10.5 Специфікація посилань (refspec)
- 10.6 Протоколи передачі
- 10.7 Супроводження та відновлення даних
- 10.8 Змінні середовища
- 10.9 Підсумок
-
A1. Додаток A: Git в інших середовищах
- A1.1 Графічні інтерфейси
- A1.2 Git у Visual Studio
- A1.3 Git в Eclipse
- A1.4 Git у Bash
- A1.5 Git у Zsh
- A1.6 Git у Powershell
- A1.7 Підсумок
-
A2. Додаток B: Вбудовування Git у ваші застосунки
- A2.1 Git з командного рядка
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Додаток C: Команди Git
- A3.1 Налаштування та конфігурація
- A3.2 Отримання та створення проектів
- A3.3 Базове збереження відбитків
- A3.4 Галуження та зливання
- A3.5 Поширення й оновлення проектів
- A3.6 Огляд та порівняння
- A3.7 Зневаджування
- A3.8 Латання (patching)
- A3.9 Електронна пошта
- A3.10 Зовнішні системи
- A3.11 Адміністрування
- A3.12 Кухонні команди
10.5 Git зсередини - Специфікація посилань (refspec)
Специфікація посилань (refspec)
Упродовж цієї книги, ми користувались простими відображеннями віддалених гілок до локальних посилань, проте вони можуть бути набагато складнішими. Припустімо, ви виконували команди кількох останніхх секцій, і створили невеличке локальне 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 оновлювати посилання, навіть якщо буде не швидке перемотування вперед.
У типовому випадку, який автоматично записує команда git remote add
, 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, щоб там була вказана лише ця гілка:
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
Ви не можете використовувати часткові шаблони, отже наступне не буде чинним:
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/
щоб це працювало?
Ви можете цього досягнути за допомогою надсилання специфікацій посилань.
Якщо команда 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
.
Вилучення посилань
Ви також можете використовувати специфікацію посилань для вилучення посилань з віддаленого сховища за допомогою чогось схожого на:
$ git push origin :topic
Через те, що специфікація це <src>:<dst>
, якщо відкинути частину <src>
, то, по суті, це каже зробити віддалену гілку topic
нічим, тобто вилучити її.
Чи можете використати новіший синтаксис (доступний від Git версії 1.7.0):
$ git push origin --delete topic