いくつか Git リポジトリを見たり、自分で管理していて便利だったタグのバージョンニングのルールを紹介します（既に何か名前付いているものだったごめんなさい）。
Git – タグ
基本はセマンティック バージョニングです。
セマンティック バージョニング 2.0.0 ｜ Semantic Versioning
セマンティック バージョニングでは メジャー.マイナー.パッチ と三つの数字を取り扱い、それぞれの番号を次の様に扱います。
- APIの変更に互換性のない場合はメジャーバージョンを、
- 後方互換性があり機能性を追加した場合はマイナーバージョンを、
- 後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。
ライブラリとして公開する場合、ライブラリのユーザは互換性を気にする必要があるので厳密にこれを守ることが期待されます（中には守らずにパッチバージョンでPHPの対応バージョンを変えるとんでももありますが）。後方互換性は古いバージョンを使っているプログラムが負荷なく新しいバージョンの恩恵（セキュリティ改善、速度改善、コードの拡張の容易化など）を受けるために重要ですが、ライブラリでない製品――webアプリケーションなどにはそれほど重要ではありません。そこで後方互換性を気にせずに次の様にメジャー.マイナー.パッチ と三つの数字を取り扱うと今、製品（納品している、外部公開サーバに上がっているなど）としているバージョンを管理しやすいです。
- リリース（納品）の場合はメジャーバージョンを、
- 開発中に機能性を追加してテストサーバ等にアップロードする場合はマイナーバージョンを、
- バグ修正をした場合はパッチバージョンを上げます。
こうすると後方互換性を気にする労力を割かず、今 Git に上がっているどのバージョンが製品なのか分かります。
このやり方が特に有効なのが一つのブランチで開発とデプロイの両方をしている時です。上述のバージョニングは複数ブランチによるサーバへのデプロイ管理を行う web アプリケーションの開発言い換えれば次の様にもなります。
- リリース用のブランチ（master or main）にマージするタイミングでメジャーバージョンを
- 機能追加の目的でテストサーバが見ているブランチ（テストサーバ、ステージングサーバ上で git pull する時に見ると決まっているブランチ）にマージするタイミングでマイナーバージョンを、
- バグ修正の目的でテストサーバが見ているブランチ（テストサーバ、ステージングサーバ上で git pull する時に見ると決まっているブランチ）にマージするタイミングでパッチバージョンを上げます。
このブランチとマージの代わりにタグを使うわけです。
