軽量タグと注釈付きタグを気にする必要があるのはなぜですか？

私は去年の毎日のVCSとしてSubversionからGitに切り替えましたが、それでも「Git-think」の細かい点を把握しようとしています。

最近私を悩ませているのは、「軽量」タグ、注釈付きタグ、署名付きタグです。注釈付きタグは実際のすべての用途で軽量タグよりも優れていることはかなり一般的に受け入れられているようですが、なぜそうなるのかについて私が見つけた説明は、常に「ベストプラクティスのため」または「それらが異なるため」に煮詰められているようです。。残念ながら、これらはなぜベストプラクティスなのか、またはそれらの違いが私のGitの使用にどのように関連するのかを知らずに、非常に満足のいく議論ではありません。

私が最初にGitに切り替えたとき、軽量タグはスライスされたパン以来の最高のもののようでした。コミットを指して「それは1.0だった」と言うだけです。タグがこれ以上必要になる可能性があることを理解するのに苦労していますが、世界中のGitエキスパートが注釈付きタグを恣意的に好むとは信じられません！それで、すべての騒ぎは何ですか？

（ボーナスポイント：なぜタグに署名する必要があるのですか？）

編集

注釈付きタグは良いことだと私は確信しています。誰がいつタグ付けしたかを知ることが重要です！フォローアップとして、適切なタグ注釈に関するアドバイスはありますか？両方git tag -am "tagging 1.0" 1.0と、前のタグ以降のコミットログを要約しようとすると、戦略を失うような気がします。

注釈付きタグの大きなプラスは、誰がそれを作成したかを知っていることです。コミットの場合と同様に、だれがそれを実行したかを知っておくとよい場合があります。あなたが開発者であり、v1.7.4がタグ付けされている（準備ができていると宣言されている）とわかり、確信がない場合、誰と話しますか？名前が注釈付きタグにある人！（あなたが不信感のある世界に住んでいる場合、これは人々が彼らがしてはいけないものにタグを付けることから逃れることも防ぎます。）あなたが消費者であるなら、その名前は権威の証です：それはgitのこのバージョンがここにあると言っている浜野純夫ですリリースされました。

他のメタデータも役に立ちます。ときどき、最終コミットが行われたときだけでなく、そのバージョンがいつリリースされたのかを知っておくと便利です。また、メッセージが役立つ場合もあります。多分それはその特定のタグの目的を説明するのに役立ちます。たぶん、リリース候補のタグには、ステータス/やることリストのビットが含まれています。

タグに署名することは、他の何かに署名することに非常に似ています-パラノイアに1レベルのセキュリティを提供します。ほとんどの人はこれを使うつもりはありませんが、ソフトウェアをコンピューターに置く前にすべてを本当に確認したい場合は、それを必要とするかもしれません。

編集：

タグ注釈に何を書くかについては、あなたの言うとおりです-言いたいことが常に役立つとは限りません。バージョン番号タグの場合、それがそのバージョンをマークしていることが暗黙に理解されており、他の場所の変更ログに満足している場合は、そこに配置する必要はありません。この場合、最も重要なのは実際にはタガーと日付です。私が考えることができる他の唯一のものは、テストスイートからの承認のある種のスタンプです。git.gitのタグを見てください。これらはすべて「Git 1.7.3 rc1」のようなものです。私たちが本当に気にしているのは、浜野淳夫の名前だけです。

ただし、あまり明確に名前が付けられていないタグの場合、メッセージはより重要になる可能性があります。単一のユーザー/クライアントの特定の特別な目的のバージョン、いくつかの重要な非バージョンマイルストーン、または（上記のように）リリース候補に追加情報をタグ付けすることを想定できます。メッセージははるかに有用です。

そのトピックに関する私の個人的な、少し異なる見解：

• 注釈付きタグは、他の開発者向けに公開されることを意図したタグであり、おそらく新しいバージョン（署名も必要）です。誰がタグ付けされたか、いつタグ付けされたかを確認するだけでなく、その理由（通常は変更ログ）も確認します。
• 軽量の方がプライベートな使用に適しています。つまり、特別なコミットにタグを付けて、それらを再び見つけられるようにするということです。それらを確認し、何かをテストするためにそれらをチェックアウトすることになるかもしれません。

デフォルトでは、Gitはのようなコマンドのベースラインとして注釈付きタグのみを調べますgit describe。注釈付きのタグは、自分や他の人にとって永続的な意味を持つ道標であると考えてください。一方、軽量のタグは、後で自分が見つけられるブックマークのようなものです。したがって、注釈付きタグは参照として使用する価値がありますが、軽量タグはそうすべきではありません。

タグへの署名は、署名者の身元の保証です。これにより、たとえば、ユーザーが取得したLinuxカーネルコードが、Linus Torvaldsが実際にリリースしたコードと同じであることを確認できます。署名は、そのコミット時に署名者がソフトウェアの品質と整合性を保証していることの表明でもあります。

タグに署名することは、リリースの信頼性を主張する簡単な方法です。

誰でもリポジトリを複製して履歴を変更できるため（たとえば、git-filter-branchを介して）、これはDVCSで特に役立ちます。タグが署名されている場合、署名はgit-filter-branch操作を通過できません。そのため、すべてのリリースにコミッターによってタグが付けられ、署名されるというポリシーがある場合、リポジトリで偽のリリースタグを検出することができます。

署名がなければ、注釈付きタグにもあまり意味がありません。

注釈付きタグをプッシュし、軽量ローカルを維持する

特定のGitの動作は、この推奨事項が役立つ方法でそれらを区別します。例：

• 注釈付きタグには、メッセージ、作成者、およびそれらが指すコミットとは異なる日付を含めることができます。したがって、リリースコミットを行わずに、それらを使用してリリースを説明できます。

  軽量のタグには追加の情報はなく、開発に自分で使用するだけなので、それを必要としません。

• git push --follow-tagsは注釈付きタグのみをプッシュします
• git describe コマンドラインオプションがないと、注釈付きのタグのみが表示されます

man git-tag 言う：

注釈付きタグはリリース用であり、軽量タグはプライベートまたは一時的なオブジェクトラベル用です。

内部の違い

• 軽量タグと注釈付きタグの両方が.git/refs/tagsSHA-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 <your@mail.com> 1411478848 +0200
  
  msg
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.11 (GNU/Linux)
  
  <YOUR PGP SIGNATURE>
  -----END PGP SIGNAT
  

  これが追加のメタデータを含む方法です。出力からわかるように、メタデータフィールドは次のとおりです。

  • それが指すオブジェクト
  • それが指すオブジェクトのタイプ。はい、タグオブジェクトは、コミットだけでなく、ブロブなどの他のタイプのオブジェクトを指すことができます。
  • タグの名前
  • タガーのIDとタイムスタンプ
  • メッセージ。PGP署名がメッセージに追加される方法に注意してください

  形式のより詳細な分析は次の場所にあります：gitタグオブジェクトの形式とそのSHAの計算方法

ボーナス

• タグに注釈が付けられているかどうかを確認します。

  git cat-file -t tag
  

  注釈付きのcommit軽量の出力tag。

• 軽量タグのみを一覧表示する：すべての軽量タグを一覧表示するにはどうすればよいですか？

軽量タグの1つの良い使用法を見つけました-GitHubでのリリースを振り返って作成します。

ソフトウェアをリリースし、必要なコミットを行いました。GitHubの「リリース」セクションを維持する手間を省きました。そして、少し注意を払ったところ、以前のリリースもいくつか追加し、それらの正しい古いリリース日を追加したいと考えました。

古いコミットで注釈付きタグを作成するだけの場合、GitHubはリリースの日付をタグオブジェクトから取得します。対照的に、この古いコミットの軽量タグを作成すると、リリースは正しい（古い）日付を表示し始めました。 ソース@ GitHubヘルプ、「リリースについて」

注釈付きコミットに希望の日付を指定することも可能のようですが、私にはそれほど簡単には見えません：https : //www.kernel.org/pub/software/scm/git/docs/git-tag。 html＃_on_backdating_tags

私のオフィスでは、リリースWebページのアドレスをタグ本文に挿入します。リリースWebページには、前回のリリース以降のさまざまな新機能と修正の詳細が記載されています。管理者はgitリポジトリを調べて、発生した変更を確認することはありません。そのリリースの内容の簡潔なリストがあると便利です。

注釈付きタグには、作成者名、リリースノート、タグメッセージ、日付などの追加のメタデータが完全なオブジェクトとしてGitデータベースに格納されます。このすべてのデータは、プロジェクトの公開リリースにとって重要です。

git tag -a v1.0.0

軽量タグは、参照するコミットのハッシュのみを保存するため、gitリポジトリにタグを追加する最も簡単な方法です。コミットに対して「ブックマーク」のように振る舞うことができるため、プライベートでの使用に最適です。

gitタグv1.0.0

古いタグを並べ替え、一覧表示、削除、表示、編集できます。これらすべての関数は、コードの特定のリリースバージョンを識別するのに役立ちます。私が見つかりました。この記事あなたはタグが何ができるか、より良いアイデアを得るために助けることができます。

私にとって重要な違いは、軽量タグにはタイムスタンプがないことです。いくつかの軽量タグを追加したとしましょう：

git tag v1
git tag v2
git tag v3

そして、おそらく後で、最後に追加された軽量タグを取得する必要があります。それを行う方法はありません。「git describe」も「git tag」も、年代順に最後の軽量タグを提供しません。"git tag -l"はそれらすべてを返すか、それらをlex順でソートできますが、日付/時刻ではソートできません。「git describe --tags」は、最後に追加されたタグではない「v1」を返します。

一方、注釈付きタグを追加する場合：

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

すべてのタグのタイムスタンプをいつでも取得でき、「git describe」は実際に最後に追加されたタグである「v3」を確実に返します。