gitタグの標準の命名規則はありますか？[閉まっている]

229

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

git git-tag

— troelskn
ソース

19

43の賛成票と数え上げで、この非常に貴重な質問を書き直して再開できるかどうか疑問に思っています。いくつかの回答は、すべてのポイントを素敵な要約に統合し、トップにいますか？@PeterEisentrautが最も完全なようです。一方、受け入れられた回答ATMは少し誤解を招くようです。 （私はすべてのポイントを読んだ後、自分でタグにv1.2.3を使用することになると思います。）

— HostileForkは、SEを信頼しないと言い

1

SOはコードを修正するためのものです。ベストプラクティスは、softwareengineering.stackexchange.comまたはcodereview.stackexchange.com

— Cees Timmerman

覗いてくださいsemver.orgあなたにいくつかのアイデアを与える必要があります（セマンティックバージョニング）を、。

— フォンブランド、

私の経験では、少し異なるスキームを使用するように言われています。1.サブディレクトリ：Gitタグはv/、名前空間のタグをグループ化するため、少なくともで始まる必要があります。2.理想的には、タグにはアプリを一意に識別する頭字語も含める必要があります。例えばv/myapp/1.0。これにより、gitリポジトリのマージが容易になります。アプリがマージされる場合、タグはタグの名前空間で衝突しません。

— axd '10 / 10/28

166

GitHub名声のトムプレストンヴェルナーによるセマンティックバージョニングのバージョン1.0.0には、これに対応する次の仕様があります。

タグ付け仕様（SemVerTag）

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

バージョン管理システムでリリースにタグを付ける場合、バージョンのタグは "vX.YZ"でなければなりません（例： "v3.1.0"）。

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

— ペリタス
ソース

9

ありがとう-非常に近いです。私は彼がなぜvそこにあるべきであるかを修飾したかったのに。

— troelskn

3

@troelskn @mojombo ==トムプレストンヴェルナー

— peritus 2010年

4

更新されたリンク：github.com/mojombo/semver.org/issues/1

— Josh Lee

41

セマンティックバージョニング1.0.0は「v1.2.3」形式を使用します。セマンティックバージョニング2.0.0-rc.1は、おそらくフォーマット「1.2.3」を使用します。タギング仕様（SemVerTag）の記事が仕様から削除されました。詳細：semver.org

— petrnohejl

9

この答えは、古いサーバー（バージョン1.0）が存在したときに行われます。現在、接頭辞「v」はsemver v2.0から削除されています。詳細については、以下の投稿を参照してください。

— vitalii

111

2つの支配的な慣習があるように見えます（リリース自体に番号を付けるためのいくつかの合理的な基準も遵守している場合）：

v1.2.3
1.2.3

の利点 v1.2.3、Gitのドキュメント（およびMercurialのドキュメント）がその例でその形式を使用していること、およびLinuxカーネルやGit自体などのいくつかの「権限」がそれを使用していることです。（前述のセマンティックバージョニングは以前はそれを使用していましたが、もう使用していません。）

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

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

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

— ピーター・アイゼントラウト
ソース

13

GitHubとtarballの生成に関して：これはもう関係ありません。タグから「v」を取り除きます。

— Hermann Bier

6

接頭辞「v」は、タグをアルファベット順にソートする場合にも非常に役立ちます。他のタグも存在する可能性があります。正式にマスターリポジトリにあるか、開発者の作業をローカルで追跡するか。接頭辞が「v」の場合、リリースタグは残りのネームスペース全体に散らばるのではなく、独自のグループを形成します。

— Robie Basak

1

回答を更新して、SemVerで使用されなくなったことを反映しましたv。

— アダムスパイアーズ2018年

80

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

— ビル・ドア
ソース

5

+1：良い最初の答えと私の好きな本の名前:-)おそらく次の答えはもっと最近の質問にあるでしょう。

— Johnsyweb

1

...しかし、これが古い SVCSにのみ当てはまる場合、この回答のポイントが最新のGitに関する質問に当てはまる場合はどうでしょうか。

— MestreLion 2012年

3

これはgitでも引き続き有用であるため、バージョンタグを他のタイプのタグと簡単に区別できます（タグは他の多くの目的に役立ちます）

— Benja

19

私が知っていることではありません。
ただし、Gitはタグと同じ名前のブランチを同時に許可しません。そのため1.1、1.1作品用のブランチ " " がある場合は、タグ " 1.1"を使用せず、たとえば " v1.1"を使用してください

— VonC
ソース

8

ブランチ1.1.xに使用します。それでおしまい。

— vitalii 2015年

1

いいキャッチ、ありがとう。

— RY

10

新しいパッケージマネージャーは、プレフィックスのないバージョンにタグを付けるvようアドバイスします（PHPプロジェクトのcomposerなど）。 SemVer 2.0はタグの指定について何も持っていません。競合を回避するために意図的に行われます。ただし、ドキュメントとテキスト参照にプレフィックスを追加することをお勧めしvます。v1.0.4完全ではなく例の形式として、version 1.0.4またはver. 1.0.4ドキュメントで十分かつ冗長でエレガントです。

— Vitalii
ソース

22

「それは…に助言される」誰からの助言で、どこでその助言を元の文脈で見ることができるか？

— bignose、2015

8

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

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

— ジョン・フェミネラ
ソース

ありがとうございます。これは、分岐を行う方法を説明するのに適した回答ですが、実際には、gitで特定の命名規則を使用する特定の（技術的な）理由があるかどうかを示しています。それでも、すばらしいダイアグラムに

— 賛成票を投じ

ああ、おっと！あなたの質問を誤解して申し訳ありません。いいえ、人間のコミュニケーション以外に、特定の名前を使用する特定の技術的な理由はありません。ブランチとタグには、好きな名前を付けることができます。

— John Feminella、2010年

リリース1.6ブランチの名前は「1.6ブランチ」ですか？ブランチ名ではスペースはサポートされていないと思いました。

— Cees Timmerman 2017年

8

基準は知りません。貼り付けることができるようなタグ名を選択するだけです

VERSION = `git describe --tags`

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

— ヨルグWミッタッグ
ソース

1

git describe --tags：>

— ダミアンキャロル

1

何もありません1つの私の知る最善の方法は。ここにいくつかのリンクがあります：

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

— ミク
ソース