Hotfix branches are similar in behavior to release branches, where QA is the main focus. Whenever an issue is reported by QA, feature branches are created to resolve them.
Where hotfixes differ to releases is in how they are created, finished and in their purpose.
A hotfix has the function of providing urgent fixes to existing releases, hence it is created directly from the release tag and, conditionally, merged into develop.
When the hotfix has been finished and approved by QA, a tag will be created, to mark the version. If the hotfix is done on the most recent release, then the hotfix also needs to be merged into develop to ensure that the fix is also included in the next release.
In case of a fix on an older release, the branch is simply deleted without any merge as the fix might not be relevant at all to more recent releases, for whom, hotfixes can also be created, if required.

When a hotfix is finished only the patch value can be increased.

git fetch --tags --force

git checkout -b <HOTFIX> <SOURCE>

git push origin <HOTFIX>

------------
<HOTFIX> -	hotfix branch that will be created (hotfix/x.y.z)

<SOURCE> -	source branch for the hotfix (x.y)

# get latest version of the release

git fetch
git checkout <HOTFIX>
git pull
# create version tag and push it to remote

git tag <VERSION>

git push origin <VERSION>

# update maintenance tag and push it to remote
git tag --force <MAINTENANCE>
git push --force origin <MAINTENANCE>

# if it is a hotfix to the latest release, 
# then merge into development branch

git checkout <TARGET>
git pull

git merge <HOTFIX>

git push origin <TARGET>

------------
<HOTFIX>      -	hotfix branch that will be closed (hotfix/x.y.z)
<VERSION>     -	version of the hotfix, also included in the hotfix branch name (x.y.z)

<MAINTENANCE> - partial version of the hotfix (x.y)
<TARGET>      -	target branch for the release (develop, lts/x, lts/x.y)