Как использовать теги Git для улучшения процессов разработки

Для большинства команд разработчиков Git стал важным инструментом контроля версий. Основная причина популярности Git — его беспрепятственная способность создавать ветки. Команды разработчиков могут использовать ветки для работы над определенными функциями или выпусками. Однако тег Git — это часто упускаемая из виду команда, которая может помочь командам упростить свои рабочие процессы. В этой статье мы подробно рассмотрим, что, как и почему используют теги Git.

Что такое теги 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 -m «My version 1.0.3»

Поиск тегов в вашем коде

Теперь, когда мы создали несколько тегов, давайте посмотрим, что у нас есть:

$ git tag -l
Release-20190401
v1.0.1
v1.0.2
v1.0.3

Мы видим, что все наши теги отображаются в алфавитном порядке. Вы можете получить дополнительную информацию о тегах, используя «-n », где обозначает количество строк комментариев.

$ git tag — n1
Release-20190401 Обновлен README.md
v1.0.1 Обновлен README.md
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 log
commit 106e0bb02a58ec3e818e9acdf3bb19a9247a0e84 (HEAD -> master, tag: v1.0.4)
Автор: Зак Х
Дата: Сб, 6 апреля, 21:06:02 2019 -0700

Добавлена ​​функция 2

commit 161c6e564e79624623ed767397a98105426d0ec4
Автор: Zak H
Дата: Сб 6 апреля 21:05:25 2019 -0700

Добавленная функция 1

commit 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, tag: v1.0.2,
tag: v1.0.1, tag: Release-20190401)

Автор: Зак Х
Дата: 6 апр, сб, 20:24:53 2019 -0700

Обновлен README. md

commit afe9b0c7c9fbce3c3d585afe67358a5eec226e2c (origin/master)
Автор: Zak H
Дата: 6 апр, сб, 20:23:55 2019 -0700

Init

Однако облегченные теги показывают комментарии из самой фиксации, которая называется «Обновлено README.md», в то время как аннотированные теги показывают отдельные комментарии, которые были добавлены к ним в процессе создания тега.

Совет: если вы хотите найти номер фиксации определенного тега , вы можете использовать команду «git show»:

$ git show v1.0.3
tag v1.0.3
Tagger: Zak H
Дата: Сб, 6 апр, 20:43:30 2019 -0700

Моя версия 1.0.3

фиксация 34671d824f9b9951e57f867998cb3c02a11c4805 (тег: v1.0.3, тег: v1.0.2, тег:
v1.0.1, тег: Release-20190401)
Автор: Зак Х
Дата: Сб, 6 апреля 20:24:53 2019 -0700

Обновлен README.md

diff —git a/README.md b/ README.md
index 9daeafb..180cf83 100644
— a/README.md
+++ b/README.md
@@ -1 + 1 @@
-test
+ test2

Пометка старых коммитов

Вы также можете вернуться и пометить более старую фиксацию. Давайте посмотрим на журналы:

$ git log —oneline
106e0bb (HEAD -> master, tag: v1.0.4) Добавлена ​​функция 2
161c6e5 Добавлена ​​функция 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1, tag: Release-20190401) Обновлен README.md
afe9b0c (origin/ master) Init
$

Мы заметили, что фиксация 161c6e5 не имеет связанного тега. Мы можем пометить эту фиксацию следующим образом:

$ git tag -a Release-20190402 161c6e5

Появится всплывающее окно комментариев. После того, как мы добавили комментарий, мы увидим, что теперь у нас есть теги фиксации:

$ git tag -n1
Release-20190401 Обновлено README.md
Release-20190402 Добавлен тег к более ранней фиксации
v1.0.1 Обновлен README.md
v1.0.2 Моя версия 1.0.2
v1.0.3 Моя версия 1.0. 3
v1.0. 4 Добавленная функция 2

Удаление тегов

Предположим, вы решили, что не хотите — «Теги, поскольку они сбивают с толку. Сначала вы можете найти все теги «Release-»:

$ git tag -l Release *
Release-20190401
Release-20190402

Теперь вы можете удалить их с помощью опции «-d»:

$ git tag -d Release-20190401
Удален тег ‘Release-20190401’ (был 34671d8)
$ git tag -d Release-20190402
Удален тег ‘Release-20190402’ (был 6ee37bc)

Если мы снова проверим теги, мы должны увидеть только те теги, которые начинаются с «v»:

$ git tag -n1
v1.0.1 Обновлен README.md
v1.0.2 Моя версия 1.0.2
v1.0.3 Моя версия 1.0.3
v1.0.4 Добавлена ​​функция 2

Теги перезаписи

Предположим, у нас есть ситуация, когда тег «v1.0.4» указывает на функцию 2:

$ git log —oneline
d7b18a4 (HEAD -> master) Добавлена ​​функция 3
106e0bb (tag: v1.0.4) Добавлена ​​функция 2
161c6e5 Добавлена ​​функция 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1) Обновлен README.m d
afe9b0c (origin/master) Init

Но мы хотим, чтобы тег «v1.0.4» указывал на функцию 3. Если мы попытаемся изменить его, мы получаем эту ошибку:

$ git tag v1.0.4 d7b18a4
fatal: tag ‘v1.0.4’ уже существует

Мы можем решить эту проблему с помощью опции «-f»:

$ git tag -f v1.0.4 d7b18a4
Обновленный тег ‘v1. 0.4 ‘(было 106e0bb)

Если мы снова проверим журнал, мы увидим, что тег переместился в нужную фиксацию:

$ git log —oneline
d7b18a4 (HEAD -> master, tag: v1.0.4) Добавлена ​​функция 3
106e0bb Добавлена ​​функция 2
161c6e5 Добавлена ​​функция 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1) Обновлен README.md
afe9b0c (origin/master) Init

Кроме того, вы также можете удалить тег и повторно добавить его в новую фиксацию.

Совместное использование тегов с другими пользователями

Когда вы отправляете свой код в удаленный репозиторий, теги Git не отправляются автоматически. Если вы хотите поделиться своими тегами с другими пользователями, вы должны использовать их исключительно.

Теги могут быть размещены следующим образом:

$ git push origin v1.0.4
Подсчет объектов: 12, готово.
Дельта-сжатие с использованием до 4 потоков.
Сжатие объектов: 100% (4/4), выполнено.
Запись объектов: 100% (12/12), 902 байта | 150,00 КиБ/с, готово.
Всего 12 (дельта 0), повторно 0 (дельта 0)
To/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://softwareengineering.stackexchange.com/ questions/165725/git-branching-and-tagging-best-практика
  • https://www.atlassian.com/git/tutorials/inspecting-a-repository/git-tag
  • https://en.wikipedia.org/wiki/Software_versioning
  • https://www.techopedia.com/definition/25977/software-versioning
Оцените статью
nanomode.ru
Добавить комментарий