Почему я должен заботиться о легком и аннотированном тегах?

Я переключился с Subversion на Git в качестве своего ежедневного VCS в прошлом году, и я все еще пытаюсь понять тонкости "Git -think".

То, что меня беспокоило в последнее время, - "легкий" и аннотированный или подписанный теги. Кажется довольно общепринятым, что аннотированные теги превосходят легкие теги для всех реальных целей, но объяснения, которые я нашел для того, почему этот случай всегда, кажется, сводятся к ", потому что лучше всего практики" или "потому что они разные" . К сожалению, это очень неудовлетворительные аргументы, не зная, почему это лучшие практики или как эти различия имеют отношение к моему использованию Git.

Когда я впервые переключился на Git, легкие теги казались лучшими, поскольку нарезанный хлеб; Я мог бы просто указать на фиксацию и сказать "что было 1.0". У меня возникли проблемы с пониманием того, как тег может когда-либо быть больше, но я, конечно же, не могу поверить, что эксперты Git мира предпочитают аннотировать теги произвольно! Итак, о чем все шумихи?

(Бонусные баллы: зачем мне когда-либо нужно подписывать тег?)

ИЗМЕНИТЬ

Я был успешно убежден, что аннотированные теги - это хорошая вещь - знание того, кто отметил и когда это важно! Как продолжение, какие-либо рекомендации по хорошим аннотациям тегов? И git tag -am "tagging 1.0" 1.0, и попытка суммировать журнал фиксации, поскольку предыдущий тег похож на потерю стратегий.

Ответы

Ответ 1

Большой плюс аннотированного тега заключается в том, что вы знаете, кто его создал. Как и в случае с фиксациями, иногда приятно знать, кто это сделал. Если вы разработчик, и вы видите, что v1.7.4 был помечен (объявлен готовым), и вы не уверены, с кем вы разговариваете? Человек, чье имя находится в аннотированном теге! (Если вы живете в недоверчивом мире, это также заставляет людей уходить с тегами вещи, которые они не должны.) Если вы потребитель, это имя является авторитетом: это Юнио Хамано говорит эту версию git настоящим освобождается.

Другие метаданные также могут быть полезны - иногда приятно знать, когда была выпущена эта версия, а не только когда была сделана окончательная фиксация. И иногда сообщение может быть даже полезно. Возможно, это помогает объяснить цель этого конкретного тега. Возможно, тег для кандидата на выпуск содержит бит списка дел/дел.

Подписывающие теги в значительной степени похожи на подписание чего-либо другого - он обеспечивает еще один уровень безопасности для параноида. Большинство из нас никогда не собираются его использовать, но если вы действительно хотите проверить все, прежде чем ставить это программное обеспечение на свой компьютер, вам может понадобиться его.

Edit:

Что касается того, что писать в аннотации тега, вы правы - не всегда полезно сказать много. Для тега номера версии он неявно понимал, что он отмечает эту версию, и если вы довольны своими изменениями в других местах, там нет необходимости размещать их. В этом случае это действительно теггер и дата, которые являются наиболее важными. Единственное, что я могу придумать, это какой-то знак одобрения из набора тестов. Взгляните на теги git.git: все они просто говорят что-то вроде "Git 1.7.3 rc1"; все, что мы действительно заботимся, это имя Юнио Хамано на них.

Однако для менее явно названных тегов сообщение может стать гораздо более важным. Я мог представить себе тегирование специальной специальной версии для отдельного пользователя/клиента, важной важной вехи не-версии или (как упоминалось выше) кандидата на выпуск с дополнительной информацией. Сообщение тогда гораздо более полезно.

Ответ 2

Мое личное, немного другое мнение по этой теме:

  • Аннотированные теги - это те теги, которые должны быть опубликованы для других разработчиков, скорее всего, новые версии (которые также должны быть подписаны). Не только увидеть, кто отмечен и когда он был помечен, но и почему (обычно это журнал изменений).
  • Легкий вес более подходит для частного использования, это означает, что теги специальные коммиты, чтобы найти их снова. Можете ли они просмотреть их, проверить их, чтобы проверить что-то или что-то еще.

Ответ 3

По умолчанию Git рассматривает только аннотированные теги в качестве базовой линии для команд типа git describe. Подумайте о аннотированных тегах в качестве указателей, которые имеют непреходящее значение для вас самих и для других, в то время как легкие теги больше похожи на закладки для вашего более позднего самоуправления. Следовательно, аннотированные теги заслуживают использования в качестве ссылки, в то время как легкие теги не должны быть.

Подписание тега - это удостоверение личности подписывающего лица. Он позволяет пользователям, например, проверить, что код ядра Linux, который они выбрали, - это тот же код, который фактически выпустил Линус Торвальдс. Подпись может также быть утверждением, что подписывающее лицо ручается за качество и целостность программного обеспечения при этом фиксации.

Ответ 4

Подписание тега - простой способ утвердить подлинность выпуска.

Это особенно полезно в DVCS, поскольку каждый может клонировать репозиторий и изменять историю (например, через git -filter-branch). Если тег подписан, подпись не сможет выдержать операцию git -filter-branch, поэтому, если у вас есть политика, в которой каждая релиз помечена тегом и подписывается коммиттером, можно обнаружить тег фиктивного релиза в репозитории.

Если бы это не было для подписания, я бы тоже не заметил много комментариев в аннотированных тегах.

Ответ 5

Я нашел одно хорошее применение для облегченных тегов - создание релиза в GitHub в ретроспективе.

Мы выпустили наше программное обеспечение, и у нас были необходимые коммиты, мы просто не потрудились поддерживать раздел "Release" на GitHub. И когда мы немного обратили на это внимание, мы поняли, что хотим добавить некоторые предыдущие выпуски с правильными датами их выпуска.

Если бы мы просто создали аннотированный тег для старого коммита, GitHub возьмет дату выпуска из объекта тега. Напротив, когда мы создали легкий тег для этого старого коммита, релиз начал показывать правильную (старую) дату. Источник @GitHub help, "О выпуске"

Кажется, что также можно указать желаемую дату аннотированного фиксации, но для меня это выглядит не так просто: https://www.kernel.org/pub/software/scm/git/docs/git-tag. HTML # _on_backdating_tags

Ответ 6

Нажимайте аннотированные теги, сохраняйте

Определенные поведения Git различают между собой таким образом, что эта рекомендация полезна, например:

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

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

  • git push -follow-tags будут только толкать аннотированные теги
  • git describe без параметров командной строки только видит аннотированные теги

man git-tag говорит:

Аннотированные теги предназначены для выпуска, а легкие теги предназначены для ярлыков частных или временных объектов.

Внутренние различия

  • как легкие, так и аннотированные теги - это файл под .git/refs/tags который содержит SHA-1

  • для облегченных тегов SHA-1 указывает прямо на фиксацию:

    git tag light
cat .git/refs/tags/light

    печатает то же, что и HEAD SHA-1.

    Поэтому неудивительно, что они не могут содержать никаких других метаданных.

  • аннотированные теги указывают на объект тега в базе данных объектов.

    git tag -as -m msg annot
cat .git/refs/tags/annot

    содержит SHA объекта аннотированных тегов:

    c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef

    и затем мы можем получить его содержание:

    git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef

    выход образца:

    object 4284c41353e51a07e4ed4192ad2e9eaada9c059f
type commit
tag annot
tagger Ciro Santilli <[email protected]> 1411478848 +0200

msg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

<YOUR PGP SIGNATURE>
-----END PGP SIGNAT

    Вот как он содержит дополнительные метаданные. Как видно из вывода, поля метаданных:

    Более подробный анализ формата присутствует в: Каков формат объекта тега git и как рассчитать его SHA?

Бонусы

Ответ 7

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

Ответ 8

Аннотированные теги хранят дополнительные метаданные, такие как имя автора, заметки о выпуске, тег-сообщение и дату как полные объекты в базе данных Git. Все эти данные важны для публичного выпуска вашего проекта.

git tag -a v1.0.0

Легкие теги - это самый простой способ добавить тег в ваш репозиторий git, потому что они хранят только хеш коммита, на который они ссылаются. Они могут действовать как "закладки" для фиксации, поэтому они отлично подходят для частного использования.

git tag v1.0.0

Вы можете сортировать, списывать, удалять, показывать и редактировать старые теги. Все эти функции помогут вам определить конкретные версии вашего кода. Я нашел эту статью, которая поможет вам лучше понять, что могут делать теги.