Git merging hotfix to multiple branches

Really, your answer is dependant on if you want your trees to be based on the same history... For example, 4.0 is based on the latest 3.X + all of the changes in 4.0...

Personally, I don't recommend it once you decide to start a new branch(s) for a new version(s). At a give point of time, the software is taking a different direction, so your branches should also.

This leaves git cherry-pick as your ideal solution. Make the change in whatever branch makes the most sense, and then cherry pick it to the older versions. This is the same as if you had checked out the old branch and manually applied the same change, and made a new commit. It keeps it clean and to the point.

Git merge or rebase are going to try to integrate the branches history together, each in their own way, which I suspect you don't want when backporting bug fixes, etc...

If you wanted to get super-technical about it, you could create the hotfix from a common ancestor:

git merge-base v3 master
git checkout -b hotfix <whatever you got from merge-base>
# make your fix
git checkout v3 && git merge --no-ff hotfix
git checkout master && git merge --no-ff hotfix

        v3--------v3 (hotfixed)
       /         /
ancestor----hotfix
       \         \
        master----master (hotfixed)

The --no-ff flag is there to highlight that Git will create a merge commit, keeping the hotfix branch label at the hotfix tip, instead of pulling the label to v3 or master. (You can omit the flag and get the same behavior, since the hotfix branch has one commit that isn't in master or v3. More info in the docs.)

Personally, I think that's overkill. I'd go with gahooa: make the hotfix on the branch that makes sense, then merge or cherry-pick depending on how you want the branches to relate to each other.