軽量タグと注釈付きタグを気にする必要があるのはなぜですか？
私は昨年、日々のVCSとしてSubversionからGitに切り替えましたが、「Git-think」の細かい点を把握しようとしています。
最近私を悩ませているのは、「軽量」対注釈付きタグ対署名済みタグです。注釈付きタグは、実際のすべての用途で軽量タグよりも優れていることはかなり一般的に受け入れられているようですが、なぜそうなっているのかについて私が見つけた説明は、常に "ベストプラクティス" または 「それらが異なるため」 。残念ながら、それらはベストプラクティスであるwhyか、それらの違いが私のGitの使用に関連するであるかを知らない非常に不満な引数です。
私が最初にGitに切り替えたとき、軽量タグはパンをスライスして以来最高のものであるように見えました。コミットを指して「1.0だった」と言うことができます。タグがそれ以上になる必要があることを把握するのに苦労していますが、世界中のGitの専門家が注釈付きタグをprefer意的に好むとは信じられません！それで、すべての騒ぎは何ですか？
（ボーナスポイント：タグに署名する必要があるのはなぜですか？）
編集
私は 成功していると確信しています 注釈付きタグは良いことだと思いました-誰がタグを付けたのか、いつ重要なのかを知っていますフォローアップとして、適切なタグ注釈に関するアドバイスはありますか？ git tag -am "tagging 1.0" 1.0と、以前のタグは戦略を失ったように感じるので、コミットログを要約しようとしています。
注釈付きタグの大きな利点は、作成者がわかることです。コミットの場合と同じように、誰がそれを行ったかを知るのはいいことです。あなたが開発者であり、v1.7.4にタグが付けられている（準備ができていると宣言されている）ことがわかり、よくわからない場合は、誰と話しますか？名前が注釈付きタグにある人！ （もしあなたが不信な世界に住んでいるなら、これは人々が彼らがすべきでないタグ付けで逃げることを防ぎます。）あなたが消費者なら、その名前は権威の印です：それはこのバージョンのgitはここにあると言いますリリース。
他のメタデータも役立つ場合があります。最終的なコミットが行われたときだけでなく、そのバージョンがいつリリースされたかを知っておくと便利な場合があります。また、時にはメッセージが役立つことさえあります。その特定のタグの目的を説明するのに役立つかもしれません。リリース候補のタグには、ステータス/ To Doリストが少し含まれている可能性があります。
タグに署名することは、他の何かに署名することとほとんど同じです-妄想にもう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のコメント：
注釈付きタグはリリース用、軽量タグはプライベートまたは一時的なオブジェクトラベル用です。
内部の違い
軽量タグと注釈付きタグの両方は、SHA-1を含む
.git/refs/tagsの下のファイルです軽量タグの場合、SHA-1はコミットを直接指します。
git tag light cat .git/refs/tags/lighthEADの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そして、これが追加のメタデータを含む方法です。出力からわかるように、メタデータフィールドは次のとおりです。
- それが指すオブジェクト
- 指すオブジェクトのタイプ。はい、 タグオブジェクトは、コミットだけでなく、ブロブなどの他のタイプのオブジェクトを指すことができます 。
- タグの名前
- タガーIDとタイムスタンプ
- メッセージ。 PGP署名がメッセージにどのように追加されるかに注意してください
形式のより詳細な分析は、次の場所にあります。 gitタグオブジェクトの形式とそのSHAの計算方法
ボーナス
タグに注釈が付けられているかどうかを判断します。
git cat-file -t tag出力
commitは軽量、tagは注釈付きです。軽量タグのみをリスト： すべての軽量タグをリストするにはどうすればよいですか？
私は軽量タグの良い使用法を見つけました-GitHubで回顧的にリリースを作成します。
ソフトウェアをリリースし、必要なコミットを行いました。GitHubの「Release」セクションを維持することはありませんでした。それに少し注意を払ったとき、以前のリリースもいくつか追加し、それらの正しい古いリリース日を追加したいと思いました。
古いコミットで注釈付きタグを作成する場合、GitHubはタグオブジェクトからリリースの日付を取得します。対照的に、この古いコミット用の軽量タグを作成すると、リリースは正しい（古い）日付を表示し始めました。 ソース@ GitHubヘルプ、「リリースについて」
注釈付きコミットに希望する日付を指定することも可能ですが、私にはそれほど単純に見えません： https://www.kernel.org/pub/software/scm/git/docs/ git-tag.html＃_on_backdating_tags
私のオフィスでは、リリースWebページのアドレスをタグ本文に入れます。リリースWebページには、前回のリリース以降のすべてのさまざまな新機能と修正の詳細が記載されています。経営陣はgitリポジトリを調べてどのような変更が発生したかを調べることはありません。そのリリースに含まれる内容の簡潔なリストがあると便利です。
注釈付きタグは、作成者名、リリースノート、タグメッセージ、日付などの追加のメタデータをGitデータベースの完全なオブジェクトとして保存します。このデータはすべて、プロジェクトの公開リリースにとって重要です。
gitタグ-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」を返します。