gitflowを使用する場合、リリースブランチまたはマスターブランチにタグを付ける必要がありますか？

この問題は次のことを示しています。

私の理解では、マージする前にリリースブランチに（マスターブランチではなく）タグを配置するのが正しいので、実際にはgit describe --devsブランチからタグを見つけることができます。＃374を参照

一方、別の投稿：

今日、誤って0.4.2-preバージョンをhomebrew経由でインストールしましたが、そのバージョンでのタグ付けの仕組みに混乱しました。以前（バージョン0.4.1）は、リリースブランチがマージされた後、マスターブランチでタグが作成されました。今では、リリースブランチの最後のコミットでタグが作成されているようですが、これは私にとっては良い考えではないようです。特に、gitタグに依存し、HEADがタグ付きコミットの場合はリリースバージョンを作成し、次のいずれかのコミットの場合は開発バージョンを作成するビルドシステムがある場合。誰かがこの変更の背後にある論理を私に説明できますか？また、セマンティックバージョニングに関しては、これがパッチレベルのバージョンバンプであるとは考えません。

私たちのチームでは、これについて複数の議論を行いました。タグをmasterブランチから作成する必要があることを示すものもあれば、releaseブランチを好むものもあります。gitflow画像によると：

タグがマスターに配置されているように見えます。

まず、ブランチにタグを付けることはできません。コミットにのみタグを付けることができます。

実際にリリースするコミットにタグを付ける必要があります。これが、バージョンタグ付きコミットのポイントです。ある環境（本番環境またはそれ以外）でソフトウェアに問題がある場合、そのリリースが由来したコミットによって問題が発生したと自信を持って言うことができます。

（これが人々が「再現可能なビルド」について話す理由です：プレビュー/ステージング環境に存在していなかった新しいバグをリリースプロセスが導入していないこと、そして本番環境に同じバグがある場合、デバッグに行くとき、バイナリはマシン上で実行されています。）

下から2番目の緑色のコミット（「唯一のバグ修正！」とマークされた緑色のコミットの子）を「v1.0」としてタグ付けしても意味がありません。マスターでコミットをリリースしました。gitフローがそれを 'Tag 1.0'としてマークしていることさえ確認できます。

タグには目的があることを忘れないでください。コミットを簡単に見つけることができます。バージョン1.0としてリリースしたものを簡単に見つけることができるように、コミットに「v1.0」のタグを付けます。コミットツリーのどこかに、実際にリリースしたコミットの近くに「v1.0」タグを付けるためにタグを付けません。

開発ブランチからタグを見つけるのに問題がある場合、それはまったく別の問題です。タグの検索に使用するツールを修正します。または、さらに良い：git-flowを使用しないでください。素敵な色のドットときれいにレイアウトされた線のおかげで、この図では見栄えがしますが、実際には色の付いた線とドットの非常に乱雑なウェブのように見えます。