You are describing a problem that we had when transitioning to GIT. The rule with Git-flow is that you **merge from your hotfix branch to develop and master** separately.
The problem we had when doing this was that both master and dev would get the 2 different code fixes separately, so when it came time to merge from develop to master, master would complain about have merge conflicts, because the files changed in both branches. You would think that it would figure out that they were the same changes in both, but the process isn't that sophisticated to looks at the commit text and realize it's the same thing.
We also had a problem with the code change from a hotfix branch not making it to the develop branch. Then we would develop without that change and when it was time to do a release, we were essentially rolling back because it didn't exist in the develop branch. Be prepared for lots of swearing and hunting to find that code change when the customer alerts you that it's not working any more after your next release!
So, to solve these issues we changed that rule to **always merge to develop first, then cherry-pick (or merge) from that PR to merge into master**. Now both branches are aware of the change and the merge ids are related from one branch to the next.
After this change to the rule, we no longer had to go hunt for rolled back code and because that PR has already been merged and related, no more merge problems when the code. At release time when the develop code is merged to master, there are no merge conflicts. The code is merged always going one direction through the branch hierarchy.
I hope this helps someone! Thanks!

You are describing a problem that we had when transitioning to GIT. The rule on Git-flow is that you **merge from your hotfix branch to develop and master** separately.
The problem we had when doing this was that both master and dev would get the 2 different code fixes separately, so when it came time to merge from develop to master, master would complain about have merge conflicts, because the files changed in both branches. You would think that it would figure out that they were the same changes in both, but the process isn't that sophisticated to looks at the commit text and realize it's the same thing.
We also had a problem with the code change from a hotfix branch not making it to the develop branch. Then we would develop without that change and when it was time to do a release, we were essentially rolling back because it didn't exist in the develop branch. Be prepared for lots of swearing and hunting to find that code change when the customer alerts you that it's not working any more after your next release!
So, to solve these issues we changed that rule to **always merge to develop first, then cherry-pick (or merge) from that PR to merge into master**. Now both branches are aware of the change and the merge ids are related from one branch to the next.
After this change to the rule, we no longer had to go hunt for rolled back code and because that PR has already been merged and related, no more merge problems when the code. At release time when the develop code is merged to master, there are no merge conflicts. The code is merged always going one direction through the branch hierarchy.
I hope this helps someone!
Thanks!