web-dev-qa-db-ja.com

gitタグに標準の命名規則はありますか？

Gitのタグの命名規則としてv1.2.3を使用する多くのプロジェクトを見てきました。 1.2.3の使用もいくつか見ました。公式に承認されたスタイルはありますか、それとも使用するための適切な議論はありますか？

gitgit-tag
204
troelskn

Semantic Versioning のバージョン1.0.0は、GitHubの名声のTom Preston-Wernerによって サブ仕様 に対処していました。

タギング仕様（SemVerTag）

このサブ仕様は、バージョン管理システム（Git、Mercurial、SVNなど）を使用してコードを保存する場合に使用する必要があります。このシステムを使用すると、自動化されたツールでパッケージを検査し、SemVerコンプライアンスとリリースバージョンを確認できます。

  1. バージョン管理システムでリリースにタグを付ける場合、バージョンのタグは「vX.Y.Z」でなければなりません。 「v3.1.0」。

ただし、 discussion の後、これは削除され、 SemVer仕様の最新バージョン （執筆時点で2.0.0）には存在しなくなりました。 同じ場所にある後のディスカッションスレッド がさらに深くなり、新しいものになりました 「v1.2.3」はセマンティックバージョンですか？ は 追加 です= SemVerのmasterブランチのFAQへ。ただし、執筆時点（2年以上後）では、この変更は公式にリリースされた仕様では まだ存在しない です。

157
peritus

2つの支配的な規則があるようです（リリース自体に番号を付けるための合理的な標準も順守していると仮定します）。

  • v1.2.3
  • 1.2.3

v1.2.3の利点は、Gitのドキュメント（およびMercurialのドキュメントでも）がその例でそのフォーマットを使用していること、および Linuxカーネル および Git 自体が使用します。 （前述の Semantic Versioning 使用されていましたが、使用されなくなりました。）

1.2.3の利点は、gitwebまたはGitHubがpackagename-$tag.tar.gzの形式のtarballまたはZipダウンロードを自動的に提供できることです（そしてtarballがpackage-v1.2.3.tar.gz）という名前を付けます。または、git describeを直接使用してtarballバージョン番号を生成できます。正式なリリースプロセスのない軽量プロジェクトの場合、これらの可能性は非常に便利です。また、セマンティックバージョニングは、バージョン番号付けのための唯一の、または広く受け入れられている標準ではないことに注意してください。また、GNOMEなどの注目すべきプロジェクトや他の無数のプロジェクトでは、1.2.3タグの命名が使用されています。

これらのポジションを統合するのはおそらく遅すぎると思います。いつものように、一貫性を持ち、理にかなっています。

更新： this コメントで述べたように、GitHubはタグから「v」を取り除いたtarball名を提供するようになりました。

101
Peter Eisentraut

先行する「v」の理由は歴史的です。古いSCCS（cvs、rcs）は、タグ識別子とリビジョン番号を区別できませんでした。タグ識別子は、リビジョン番号を検出できるように、数値で始まらないように制限されていました。

73
Bill Door

新しいパッケージマネージャーは、バージョン without prefix v（[ composer のようにPHPプロジェクト）にタグを付けるようにアドバイスします。 SemVer 2. は、タグの仕様については何もありません。競合を避けるために意図的に行われています。ただし、ドキュメントおよびテキスト参照に接頭辞vを追加することは advisored です。例として、完全なv1.0.4またはversion 1.0.4の代わりにver. 1.0.4の形式で十分に冗長でエレガントなドキュメントです。

10
vitalii

リリース固有の作業にはブランチとタグを使用し、その後に実際のリリースが続きます。

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

すべての開発者は、コミットしようとしている作業をマスターだけに適用できるのか、それともブランチにも関連するのかについて、精神的な決定を下します。ブランチに加えられた変更はマスターにマージされますが、マスターの一部の変更はブランチに反映されないことがわかります（つまり、この例では1.6リリース用ではありません）。

リリースの準備ができたら、タグを付け、最後にもう一度マージし、ブランチと同じ名前でタグに名前を付けますが、特定のバージョンに関する追加の識別子を付けます。 「1.6-release」または「1.6-beta」または「1.6-rc2」など。

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release
6
John Feminella

私は標準を知りません。タグを付けられるようにタグ名を選択するだけです

VERSION = `git describe --tags`

私のビルドスクリプトで。したがって、タグの命名規則は、実際にはプロジェクトのバージョンの命名規則に依存します。

6
Jörg W Mittag

私が知っているベストプラクティスはありませんoneリンクは次のとおりです。

一般に、バージョニング（0.0.1、v0.2.1、...）は、何らかの問題追跡と密接に関連している可能性があります。 （..私は通常v-接頭辞付きタグ名を使用しますが.. @VonC回答も参照してください）

1
miku