以前のバージョンをサポートする場合のビルド番号
私は自分の仕事で社内で使用されるWebベースのアプリケーションを開発および保守しています。私は唯一の開発者なので、実際にはブランチを使用していません。すべてがトランクで起こります。 Gitで日付と時刻を使用してタグをリリースし、日付/時刻の代わりにビルド番号を使用するように移行し始めています。
アプリの本番インスタンス（トランク上の単なるタグ）で、できるだけ早く修正する必要があるバグが発見されました。その間、私は新しい機能を開発してきましたが、それらを配布する準備ができていません。
バグの修正は簡単です。タグを新しいブランチにチェックアウトし、修正して公開します。ただし、このような状況では、修正のビルド番号はどうあるべきですか？
シリアル番号をインクリメントする既存のビルド戦略に従うと、ビルド番号は次のようになります。
1234: production
1235: development (with new features)
1236: production fix (doesn't have new features)
これは意味がないようです。あるいは、プロダクションタグのビルド番号を増やすと、たとえば、.
1234: production
1235: development (new features)
1235: production fix
これはビルド番号の目的を無効にします（特定のビルドを一意に識別します）。
GitのリビジョンIDを使用することも別のオプションですが、正確に読み取ることはできません。
Semantic Versioning を使用するだけでなく、 Gitワークフロー に従うこともできます。現在の開発作業を機能ブランチに移動し、新しい機能の開発を行う前にマスターをコミットに戻し、準備ができたときにのみ新しい機能をマスターにマージできます（つまり、すべてのテストをクリアし、QAをクリアします）。そうすれば、バグ修正をマスターに直接適用できます。
Gitワークフローに従うことで、現在の状況と同様の状況を回避でき、今後の推奨アプローチとなります。