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


346

В прошлом году я переключился с Subversion на Git в качестве повседневной системы управления версиями и все еще пытаюсь понять тонкости «Git-think».

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

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

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

РЕДАКТИРОВАТЬ

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


Вы нашли хороший ответ для своего продолжения? Что-то вроде? git log --pretty=oneline master..HEAD | git tag -a -F - $BRANCH.$BUILD_NUMBER
Далор

Обобщение журнала коммитов, так как предыдущий тег кажется мне отличной стратегией для сообщений тега.
Роби

К вашему сведению (1.) Для отображения тега LIGHTWEIGHT по дате перейдите сюда . (2.) Чтобы просмотреть помеченный тег по дате, перейдите сюда .
Тревор Бойд Смит

Ответы:


272

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

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

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

Редактировать:

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

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


4
просто для сравнения с SVN, так как OP поступает из этой системы: аннотированные метаданные тега эквивалентны действительному изменению SVN, делает ветвь тега, которая в SVN имеет своего автора и сообщение. И, возможно, существуют отдельные ограничения на то, кто может сделать тег, в отличие от того, кто может регистрировать изменения - различие, которое не имеет значения, если вы просто используете систему для своих собственных вещей.
araqnid

10
Ах-ха! Похоже, мое понимание здесь было затруднено тем фактом, что все мои проекты Git до сих пор были сольными. Мне никогда не нужно было знать, кто в чем-то виноват (это всегда я!), Поэтому я не заметил, что легкие теги не отслеживают теггер.
Бен Бланк

5
git help logТеперь подытожим это следующим образом: «Аннотированные теги предназначены для выпуска, в то время как облегченные теги предназначены для меток частных или временных объектов».
Джон Гьенсет

1
@javabrett Хотя это хорошая часть ответа на вопрос «в чем различия между аннотированными и легковесными тегами», вопрос здесь заключался в том, почему люди хотят хранить дополнительную информацию и, таким образом, использовать аннотированные теги. (И я не думаю, что я мог бы серьезно сказать, что «это создает большой двоичный объект» - это обратная сторона - вы делаете то, что вам нужно, чтобы хранить информацию, которую вы хотите сохранить, и, если это важная информация, для этого потребуется большой двоичный объект. )
Каскабель

1
@ Крис, да, как говорится в ответе: «Большой плюс аннотированного тега в том, что вы знаете, кто его создал». Вы всегда можете сами попробовать что-то выяснить:git tag -a -m 'my message' my-tag; git show my-tag
Каскабель

64

Мой личный, немного другой взгляд на эту тему:

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

4
Это также упоминается на человек , ГИТ-теге: «Аннотированные теги предназначены для выпуска в то время как легкие метки предназначены для частных или временных объектов этикеток.»: Stackoverflow.com/a/35059291/895245
Чиро Сантилли郝海东冠状病六四事件法轮功

28

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

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


1
git push --follow-tagsэто еще одна команда, которая обрабатывает оба по-разному: stackoverflow.com/a/26438076/895245
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

1
Спасибо за подсказку о git describe. Я использую его в системе непрерывной интеграции, и пару раз строка с версией не соответствовала моим ожиданиям.
jjmontes

9

Подписание тега - это простой способ подтвердить подлинность релиза.

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

Если бы не подпись, я бы не увидел особого смысла в аннотированных тегах.


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

9

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

Определенные поведения 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
    

    печатает так же, как 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 <your@mail.com> 1411478848 +0200
    
    msg
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (GNU/Linux)
    
    <YOUR PGP SIGNATURE>
    -----END PGP SIGNAT
    

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

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

Бонусы


6

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

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

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

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


Хотя сегодня я узнал, что GitHub прекратил отмечать для меня даты тегов (как для легких, так и для аннотированных тегов). Он просто игнорирует дату при публикации релиза и вместо этого запоминает дату и время, когда я нажал кнопку «Опубликовать» для релиза.
evilkos

Да, я также наткнулся на этот беспорядок о GitHub и аннотированных тегах. Я не
понял,

1

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


0

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

git tag -a v1.0.0

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

git tag v1.0.0

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


0

Для меня важным отличием является то, что легкий тег не имеет отметки времени. Допустим, вы добавили несколько легких тегов:

git tag v1
git tag v2
git tag v3

а затем, возможно, позже, вы хотите получить последний добавленный легкий тег. Нет способа сделать это. Ни «git description», ни «git tag» не дадут вам хронологически последний легкий тег. «git tag -l» может вернуть их все или отсортировать в лексическом порядке, но не по дате / времени. «git description --tags» вернет «v1», который определенно не является последним добавленным тегом.

С другой стороны, если вы добавите аннотированные теги:

git tag v1 -m v1
git tag v2 -m v1
git tag v3 -m v1

вы всегда можете получить метку времени каждого тега, и «git description» обязательно вернет «v3», который является последним добавленным тегом.


Вы должны использовать -a для аннотирования.
Алекс
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.