What would be the best approach in that case, merge the branch hotfix-1.0.1 in hotfix-1.1.1 (to avoid rework) and adapt the code according to the codebase?
Merging can be dangerous here, depending on what this branch contains. For example, if 1.0 has received certain updates that you don't want leaking into 1.1, then a hotfix branch made from the current state of 1.0 should not be merged into 1.1 as it will apply more changes than just the hotfix itself.
The easiest but surefire approach depends on a lot of factors that I can't account for here.
- Sometimes, you can just merge a branch. It's the easiest, but there are cases where it shouldn't be done.
- Sometimes, a cherrypick solves the problem that you'd encounter in the above bullet point. I don't like cherrypicking but I've seen devs who don't mind and manage to make it work.
- Sometimes, the "same fix" requires making actually different changes to two versions (e.g. because of heavy refactoring that took place between those versions). In this case, it's way easier to just develop two individual hotfixes.
There's more than one way to do this and your question is way too broad to provide a specific answer.
Additionally, it depends on how complex you're willing to make your branching strategy. I personally steer clear from git's more difficult and granular strategies, but others jumped in the deep end and confidently rewrite commit histories without breaking a sweat. There's a lot of considerations at play here: risk vs reward, your developer's git skill level, the complexity of your codebase, ...
The last consideration I want to add here is that hotfixes tend to be simple changes made to the codebase. They're usually not substantial or complex. You're probably overthinking this approach. Reusability is nice when you can have it but you have to remember that the effort (and risk) doesn't start outweighing the benefit. Sometimes, redoing a trivial fix is the better way if it completely avoids side effects that you'd otherwise be risking.
Do patches need to reflect the same fixes? E.g. patch 1.0.1 needs to necessarily have the same fixes of patch 1.1.1?
The name "patch" really just means "release of a small changeset". Releases can be scheduled however you see fit. Maybe the patch only contains this fix. Maybe you bundle a week's worth of fixes, which could mean that the 1.1 patch contains this 1.0.1 patch and some other things as well. There's no need to keep these kinds of patches equal across all versions. That's the whole point of semver, changes are scoped to the version that they are listed under.
There's also no way of knowing that the same patch number is available in both versions. If you've already developed several fixes in 1.1-specific code (that does not exist in 1.0), then 1.1 will be several patch numbers ahead of 1.0. This might mean that your patch 1.0.1 might end up being patch 1.1.25 for the other version.
Could Patch 1.1.1 have other fixes besides the fixes of Patch 1.0.1?
See above paragraph. Yes, it can contain whatever you want it to contain. It's completely your choice when you release a patch/update and how much it contains.
I frequently develop bugfixes and then don't bother doing an individual release for them, simply because there's no need for going through the motions. Instead, I just "throw it on the pile" and let the fix go out with whatever the next release will be.
While CI/CD does urge you to integrate and release frequently, frequency is a relative concept. For some, that means after every commit. For others, that can mean weekly. It's very contextual based on the work and effort involved.
E.g. A single patch that could be applied to release-1.0 and release-1.1.
1.0 and 1.1 are different in some way (otherwise there'd be no point to having a newer version 1.1). They are also similar in other ways (otherwise you wouldn't think of them as versions of the same codebase).
Whether or not a single patch can be applied to several releases depends on whether the included changeset focuses on the differences between these versions or their similarities.
Ideally, yes a patch could be reused when it fixes something that is the same in both versions. But you can't blindly guarantee that this will be the case, and when you can't guarantee it, it is very difficult (if not impossible) to automate.
I would suggest that you design your process in a way that maximizes the ability to reuse a patch, but to not actually commit said patch without a human reviewer confirming that this patch can be applied to a given version, on a case-by-case basis.
