gitflowを使用する場合、リリースブランチまたはマスターブランチにタグを付ける必要がありますか？
この問題 は以下を示します：
マージの前に（masterブランチではなく）releaseブランチにタグを配置することが私の理解から実際には正しいことなので、gitブランチで開発タグを見つけることもできます-開発ブランチからのタグ。 ＃374を参照
while 別の投稿 ：
今日、0.4.2-preバージョンをhomebrew経由で誤ってインストールしましたが、そのバージョンでのタグ付けのしくみに混乱しました。以前（バージョン0.4.1）、リリースブランチがマージされた後、タグはマスターブランチに作成されました。タグはリリースブランチの最後のコミットで作成されているようですが、これは私には良い考えではないようです。特に、HEADがタグ付きコミットの場合、リリースバージョンを作成し、次のいずれかのコミットの場合、開発バージョンである場合、gitタグに依存し、リリースバージョンを作成するビルドシステムがある場合。誰かがロジックを説明できますか。この変更の背後には？セマンティックバージョニングに関しては、これをパッチレベルのバージョンバンプとは見なしません！
私たちのチームでは、これについて複数の議論がありました。タグはマスターブランチから作成する必要があることを示すものもあれば、リリースブランチを好むものもあります。 gitflowの画像によると：
タグがマスターに配置されているようです。
まず、ブランチにタグを付けることはできません。タグを付けることができるのはコミットのみです。
実際にリリースするコミットにタグを付ける必要があります。これがバージョンタグ付けコミットのポイントです。ある環境（本番環境など）でソフトウェアに問題がある場合は、そのリリースが由来するコミットによって問題が引き起こされたと確信を持って言うことができます。
（これが人々が「再現可能なビルド」について話している理由です：彼らは彼らのリリースプロセスがプレビュー/ステージング環境に存在しなかった新しいバグを導入していないこと、そして彼らが本番環境に同じバグを持っている場合、同じであることを確信することができます彼らがそれをデバッグしようとするとき、バイナリは彼らのマシンで走っています。
下から2番目の緑のコミット（「バグ修正のみ！」とマークされたコミットの緑の子）を「v1.0」としてタグ付けする意味はありません。あなたはマスターでコミットをリリースしました。 git flowで「タグ1.0」とマークされていることもわかります。
覚えておいてください、タグには目的があります：コミットを簡単に見つけることです。コミットに「v1.0」というタグを付けると、バージョン1.0としてリリースしたものを簡単に見つけることができます。実際にリリースしたコミットの近くの漠然としたコミットツリーのどこかに「v1.0」タグを付けるために、タグを付けません。
開発ブランチからタグを見つけるのに問題がある場合、それは完全に別の問題です。タグの検索に使用するツールを修正します。または、まだ良い：git-flowを使用しないでください。素敵な色のドットときれいにレイアウトされた線があるため、この図では見栄えがしますが、実際には、色付きの線とドットのめちゃくちゃ乱雑な網のように見えます。