This issue indicates that:
From my understanding placing the tag on the release branch before merging (and not on the master branch) is in fact the correct thing to do so it can be found by git describe --tags from the develop branch, too. See #374
while another post:
I accidentally installed the 0.4.2-pre version via homebrew today and was confused by the way the tagging works in that version. Previously (version 0.4.1) the tag was created on the master branch, after the release branch has been merged into it. Now it seems that the tag is created on the last commit of the release branch, which seems not to be a good idea for me. Especially if you have a build-system that relies on git tags and creates a release version if HEAD is a tagged commit and a development version if its one of the following commits. Could someone explain the logic behind this change to me? And with respect to semantic versioning I don't would consider this to be a version bump in the patch-level!
In our team we have and had multiple discussions about this. Some indicate that a tag needs to be created from the master branch while others prefer the release branch. According to the gitflow picture:
it looks like that the tag is placed on the master.