Git Flow Confusion On Release Branch

Your diagram is wrong. A squash merge is not a merge. It causes a new commit to appear out of thin air, with no record of how or why. If you do a squash merge to master and a squash merge to dev, master and dev are two totally independent commits, unrelated to each other and unrelated to the feature branch. So the arrows pointing from the end of the feature branch to the ends of master and dev are false and should be deleted.

If you wanted there to be some sort of relationship between these things, at the very least use real merges. And do not take shortcuts. Do this the normal way: PR to dev, merge to dev, then see about getting that (the merge commit on dev) onto master.

A release branch (which seems to be what you are asking about) is like a normal branch off of dev except (1) it stops all features from being merged into dev, and (2) as you rightly say, the goal here is to merge into master, though of course we must also merge back to dev. You might want to see the original document, https://nvie.com/posts/a-successful-git-branching-model/, which is much simpler and clearer than the atlassian page you cited.

How can I get same HEAD for master and dev after merge?

You can't. Well, technically you could, but you probably don't want to.

A branch in git points to a commit; that commit points to other commits, back through history. Each of those commits is identified by a unique hash; if two different commits had the same hash, everything would be horribly broken. That hash covers both the contents of the repository, and all the metadata of the commit, including what parents it has.

So if two different branches point at the same hash, those branches are identical - not just identical in their current content, but identical in their entire history.

The only way for that to happen is to always use "fast-forward" merges, everywhere, so that all your branches are actually just pointers in a single line of commits. In practice, that means rebasing things, a lot - for instance, every hotfix will probably require rebasing the whole of develop, and then rebasing all open feature branches onto that new develop.

That's a lot of work, and a lot of things that can go wrong, to avoid this:

I had to merge an empty commit with no diff.

Git was smart enough to recognise that no actual changes were needed, even though you'd merged two unrelated commits (remember: a squash merge throws away all history on the feature branch). That is it solving the problem for you.

The other solution, as pointed out in comments, is not to merge the feature to two places in the first place. Merge release to master, and then merge master to develop.