Phenquestions
Что такое теги Git?
Теги Git - это указатели на определенные коммиты. Они как закладки. Вы можете использовать любое соглашение для создания тегов. Но большинство команд разработчиков используют номера версий, такие как v1.0.1 или v.1.1-a1 для создания тегов.
Создание тегов
В Git есть два типа тегов:
- Легкие теги
- Аннотированные теги
Легкие теги
Легкие теги легко создавать. Вы можете просто использовать следующую командную строку:
$ git tagЭти теги хранятся в .папка git вашего рабочего репозитория.
Давайте создадим несколько легких тегов Git:
$ git tag v1.0.1$ git tag Release-20190401
В первом случае мы создали тег с «v1.0.1 ”. Во втором случае мы создали тег с «Release-20190401». Облегченные теги не возвращают никакого значения. Кроме того, важно отметить, что, поскольку эти два тега были установлены вплотную друг к другу, они указывают на одну и ту же фиксацию.
Аннотированные теги
Аннотированные теги позволяют хранить больше информации. Вы можете использовать опцию «-a» для создания этих тегов:
$ git tag -aПопробуем создать аннотированный тег:
git tag -a v1.0.2Появится текстовое окно, в котором вы можете ввести комментарий, который должен выглядеть следующим образом:
## Напишите сообщение для тега:
# V1.0.2
# Строки, начинающиеся с '#', будут проигнорированы.
Введите комментарий и сохраните его. Итак, теперь ваш тег v1.0.2 сохранено с комментарием. Кроме того, вы можете напрямую ввести комментарий в командной строке следующим образом:
git tag -a v1.0.3-м "Моя версия 1.0.3 "Поиск тегов в вашем коде
Теперь, когда мы создали несколько тегов, давайте посмотрим, что у нас есть:
$ git tag -lРелиз-20190401
v1.0.1
v1.0.2
v1.0.3
Мы видим, что все наши теги отображаются в алфавитном порядке. Вы можете получить дополнительную информацию о тегах, используя “-n
Релиз-20190401 Обновлен README.мкр
v1.0.1 Обновленный README.мкр
v1.0.2 Моя версия 1.0.2
v1.0.3 Моя версия 1.0.3
Здесь вы можете заметить разницу между легкими и аннотированными тегами. В этом примере «Release-20190401» и «v1.0.1 дюйм - это легкие теги. «V1.0.2 »и« v1.0.3 ”- аннотированные теги. Все они указывают на одну и ту же фиксацию (фиксация 34671):
$ git журналсовершить 106e0bb02a58ec3e818e9acdf3bb19a9247a0e84 (HEAD -> master, tag: v1.0.4)
Автор: Зак Х
Дата: Сб, 6 апр, 21:06:02 2019 -0700
Добавлена функция 2
совершить 161c6e564e79624623ed767397a98105426d0ec4
Автор: Зак Х
Дата: Сб, 6 апр, 21:05:25 2019 -0700
Добавлена функция 1
совершить 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, тег: v1.0.2,
тег: v1.0.1, тег: Release-20190401)
Автор: Зак Х
Дата: 6 апр, сб 20:24:53 2019 -0700
Обновленный README.мкр
совершить afe9b0c7c9fbce3c3d585afe67358a5eec226e2c (origin / master)
Автор: Зак Х
Дата: 6 апр, сб, 20:23:55 2019 -0700
В этом
Однако облегченные теги показывают комментарии от самого коммита, который называется «Обновлен README.md », а аннотированные теги показывают отдельные комментарии, которые были добавлены к ним в процессе создания тега.
Кончик: Если вы хотите узнать номер фиксации определенного тега, вы можете использовать команду «git show»:
$ git show v1.0.3тег v1.0.3
Теггер: Zak H
Дата: Сб, 6 апр, 20:43:30 2019 -0700
Моя версия 1.0.3
совершить 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, тег: v1.0.2, тег:
v1.0.1, тег: Release-20190401)
Автор: Зак Х
Дата: 6 апр, сб, 20:24:53 2019 -0700
Обновленный README.мкр
diff --git a / README.md b / README.мкр
индекс 9daeafb… 180cf83 100644
--- а / README.мкр
+++ b / README.мкр
@@ -1 +1 @@
-контрольная работа
+test2
Пометка старых коммитов
Вы также можете вернуться и пометить более старую фиксацию. Посмотрим логи:
$ git log --oneline106e0bb (HEAD -> master, тег: v1.0.4) Добавлена функция 2
161c6e5 Добавлена функция 1
34671d8 (тег: v1.0.3, тег: v1.0.2, тег: v1.0.1, тег: Release-20190401) Обновлен README.мкр
afe9b0c (origin / master) Инициализация
$
Мы замечаем, что фиксация 161c6e5 не имеет связанного тега. Мы можем пометить этот коммит так:
$ git tag -a Release-20190402 161c6e5Появится всплывающее окно комментария. После того, как мы добавили комментарий, мы увидим, что теперь у нас есть теги фиксации:
$ git tag -n1Релиз-20190401 Обновлен README.мкр
Release-20190402 Добавлен тег в более старую фиксацию
v1.0.1 Обновленный README.мкр
v1.0.2 Моя версия 1.0.2
v1.0.3 Моя версия 1.0.3
v1.0.4 Добавленная функция 2
Удаление тегов
Предположим, вы решили, что вам не нужны теги «Release-», поскольку они сбивают с толку. Сначала вы можете найти все теги «Release-»:
$ git tag -l Release *Релиз-20190401
Релиз-20190402
Теперь вы можете удалить их с помощью опции «-d»:
$ git tag -d Выпуск-20190401Удален тег "Release-20190401" (был 34671d8)
$ git tag -d Выпуск-20190402
Удален тег Release-20190402 (был 6ee37bc)
Если мы снова проверим теги, мы увидим только те теги, которые начинаются с «v»:
$ git tag -n1v1.0.1 Обновленный README.мкр
v1.0.2 Моя версия 1.0.2
v1.0.3 Моя версия 1.0.3
v1.0.4 Добавленная функция 2
Перезапись тегов
Предположим, у нас есть ситуация, когда «v1.0.4-дюймовый тег указывает на функцию 2:
$ git log --onelined7b18a4 (HEAD -> master) Добавлена функция 3
106e0bb (тег: v1.0.4) Добавлена функция 2
161c6e5 Добавлена функция 1
34671d8 (тег: v1.0.3, тег: v1.0.2, тег: v1.0.1) Обновлен README.мкр
afe9b0c (origin / master) Инициализация
Но нам нужен тег «v1.0.4 дюйма, чтобы указать на Особенность 3. Если мы попытаемся изменить теги, мы получим такую ошибку:
$ git tag v1.0.4 d7b18a4фатальный: тег 'v1.0.4 'уже существует
Мы можем решить эту проблему с помощью опции «-f»:
$ git tag -f v1.0.4 d7b18a4Обновлен тег v1.0.4 '(было 106e0bb)
Если мы снова проверим журнал, мы увидим, что тег переместился в нужную нам фиксацию:
$ git log --onelined7b18a4 (HEAD -> master, tag: v1.0.4) Добавлена функция 3
106e0bb Добавлена функция 2
161c6e5 Добавлена функция 1
34671d8 (тег: v1.0.3, тег: v1.0.2, тег: v1.0.1) Обновлен README.мкр
afe9b0c (origin / master) Инициализация
Кроме того, вы также можете удалить тег и повторно добавить его в новую фиксацию.
Обмен тегами с другими пользователями
Когда вы отправляете свой код в удаленный репозиторий, теги Git не отправляются автоматически. Если вы хотите поделиться своими тегами с другими пользователями, вы должны отправлять их исключительно.
Теги можно вставить так:
$ git push origin v1.0.4Подсчет объектов: 12, готово.
Дельта-сжатие с использованием до 4 потоков.
Сжатие объектов: 100% (4/4), готово.
Запись объектов: 100% (12/12), 902 байта | 150.00 КиБ / с, готово.
Всего 12 (дельта 0), повторно используется 0 (дельта 0)
К / Users / zakh / _work / LearnGIT / git_tagging / remote / project_mayhem
* [новый тег] v1.0.4 -> v1.0.4
Теперь, если другие пользователи клонируют удаленный репозиторий, они будут видеть только вставленный тег («v1.0.4 ”в данном случае).
Использование веток против тегов
Филиалы полезны для новых функций или экспериментов. Как правило, вы хотите выполнить ветвление, когда есть будущая работа, которую необходимо выполнить, и работа мешает вашему текущему развитию. С другой стороны, теги более полезны в качестве снимков. Вы должны использовать их, чтобы запомнить конкретные вещи, которые вы уже сделали.
В заключении
Тег Git - это недостаточно используемая функция, которая может предоставить отличный способ отслеживать выпуски и специальные функции. Если вы установите передовые методы работы с тегами, это поможет вам легко общаться с командой разработчиков и упростить процессы разработки.
Дальнейшее изучение:
- https: // git-scm.com / book / en / v2 / Git-Basics-Tagging
- https: // программная инженерия.stackexchange.com / questions / 165725 / git-branching-and-tagging-best-практики
- https: // www.атласский.com / git / tutorials / инспектирование-репозиторий / git-tag
- https: // ru.википедия.org / wiki / Software_versioning
- https: // www.техопедия.ru / definition / 25977 / версии программного обеспечения
