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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Edit:

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

Вставка аннотированных тегов, сохранение легкого локального

Некоторые поведения 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
  

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

  • объект, на который он указывает
  • тип объекта, на который он указывает.Да, объекты тега могут указывать на любой другой тип объекта, например BLOB-объекты, а не только на .
  • имя тега
  • идентификатор тега и метка времени
  • сообщение.Обратите внимание, что подпись PGP только что добавлена ​​к сообщению

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

Бонусы

• Определите, помечен ли тег:

  git cat-file -t tag
  

  Выходы commit для облегченных, tag для аннотированных.

• Список только облегченных тегов: Как мне перечислить все облегченные теги?

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

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», который является последним добавленным тегом.

Answer 9

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

git tag -a v1.0.0

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

git tag v1.0.0

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