-
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 Кухонні команди
2.6 Основи Git - Теґування
Теґування
Як і більшість СКВ, Git дозволяє поставити теґ на окремому моменті історії, що чимось видатний. Зазвичай ця функціональність використовується щоб позначити релізи (v1.0 тощо). У цій секції, ви дізнаєтесь, як отримати список доступних теґів, як створювати нові теґи, та які типи теґів існують.
Показати ваші теґи
Отримати список доступних теґів у Git елементарно.
Просто наберіть git tag
(з опціональним -l
чи --list
):
$ git tag
v0.1
v1.3
Ця команда виводить список теґів в алфавітному порядку. Цей порядок насправді неважливий.
Ви також можете шукати теґи, що відповідають певному шаблону. Наприклад, сховище Git містить більш ніж 500 теґів. Якщо вас цікавлять виключно версії 1.8.5, ви можете виконати:
$ git tag -l "v1.8.5*"
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5
Зауваження
|
Пошук за шаблонами із спеціальними символами потребує опції
-l чи --list
Якщо ви хочете отримати повний список теґів, то команда Втім, якщо ви використовуєте шаблон зі спеціальними символами, то використання |
Створення теґів
Git підтримує два головних типи теґів: легкі та анотовані.
Легкий теґ дуже схожий на гілку, що не змінюється — це просто вказівник на певний коміт.
Анотовані теґи
Створити анотований теґ у Git просто.
Найлегший спосіб — додати -a
до команди tag
:
$ git tag -a v1.4 -m "моя версія 1.4"
$ git tag
v0.1
v1.3
v1.4
-m
визначає повідомлення теґу, що в ній буде збережено.
Якщо ви не вкажете повідомлення анотованого теґу, Git запустить ваш редактор щоб ви могли його набрати.
Ви можете побачити дані теґу та коміт, на який він вказує, за допомогою команди git show
:
$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date: Sat May 3 20:19:12 2014 -0700
my version 1.4
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
Це показує інформацію про автора теґу, дату створення теґу, та повідомлення перед інформацією про коміт.
Легкі теґи
Другий спосіб позначати коміти — за допомогою легких позначок.
Це просто хеш коміту збережений у файлі — ніякої іншої інформації не зберігається.
Щоб створити легкий теґ, не додавайте жодної з опцій -a
, -s
та -m
, вкажіть лише назву теґу:
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
Цього разу, якщо ви виконаєте git show
з теґом, ви не побачите додаткової інформації про теґ.
Команда покаже тільки коміт:
$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
Створення теґів пізніше
Ви також можете зробити теґ до комітів, від котрих ви вже пішли. Припустімо, що ваша історія комітів виглядає так:
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
Тепер, припустимо ви забули створити теґ до версії проекту v1.2, що має бути на коміті ``updated rakefile''. Ви можете додати теґ і зараз. Щоб створити теґ до коміту, вам треба дописати суму коміту (чи її частину) наприкінці команди:
$ git tag -a v1.2 9fceb02
Ви можете побачити, що ви створили теґ до коміту:
$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5
$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date: Mon Feb 9 15:32:16 2009 -0800
version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date: Sun Apr 27 20:43:35 2008 -0700
updated rakefile
...
Розповсюдження теґів
Без додаткових опцій команда git push
не передає теґи на віддалені сервери.
Вам доведеться явно надсилати теґи на спільний сервер після створення.
Цей процес не відрізняється від розповсюдження віддалених гілок — вам треба виконати git push origin <назва теґу>
.
$ git push origin v1.5
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.5 -> v1.5
Якщо у вас багато теґів, та ви хочете надіслати їх разом, ви також можете використати опцію --tags
команди git push
.
Це передасть усі ваші теґи до віддаленого серверу, яких там досі нема.
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw
Тепер, коли хтось інший зробить клон або отримає зміни з вашого сховища, він отримає також усі ваші теґи.
Переключення до теґів
Якщо ви бажаєте переглянути версії файлів, на які вказує теґ, виконайте git checkout
, хоча тоді ви отримаєте стан ``відокремлений HEAD'' (detached HEAD), що має декілька обмежень:
$ git checkout 2.0.0
Note: checking out '2.0.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch>
HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final
$ git checkout 2.0-beta-0.1
Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final
HEAD is now at df3f601... add atlas.json and cover image
Якщо ви щось зміните й створите коміт у стані ``відокремлений HEAD'', теґ залишиться незмінним, а а новий коміт не належатиме жодній гілці й буде досяжним лише за допомогою хеша коміту. Відповідно, якщо вам треба здійснити зміни — скажімо, ви виправляєте ваду у старшій версії — зазвичай варто створити гілку:
$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'
Якщшо ви це зробите й створите коміт, ваша гілка version2
буде трохи відрізнятися від вашого теґу v2.0.0
, адже вона переміститься вперед до ваших нових змін, отже будьте обережні.