I think I have a peculiar scenario. We follow standard git flow in our organisation. Except, the release branch takes a bit long to be ready to be merged back into master and develop.
We used to block all feature branch merges to develop until the release branch is merged back into master and develop. However, when the team size grew, this has become understandably unacceptable. So we want to allow developers to carry on merging their feature branches back to develop even before the release branch is merged.
Now the issue arises when it is finally the time to merge the release branch. Say features f1 and f2 were on develop before the release r1 was cut. Since then, f3 and f4 were merged back into develop. Now, if we merge the release branch r1, the develop's timeline looks like this:
Merge commit of r1
Merge commit of f4
Merge commit of f3
Merge commit of f2
Merge commit of f1
This means when the next release r2 is cut, the commit history will include r1, f4 and f3. Something tells me this isn't right.
However, if we blocked merges to develop whilst the release branch was active, it would look a bit more organised with the release commit appearing exactly where it should be:
Merge commit of f4
Merge commit of f3
Merge commit of r1
Merge commit of f2
Merge commit of f1
What are my options here? I don't want to do an interactive rebase of develop with last x commits so that I can re-order the commits as that will make me do a force push to the develop branch (scary!).
One of the main purposes of Git Flow release branches is so you don't need a code freeze on the develop branch. In fact, I might go as far as saying that when you used to enforce code freezes that Git Flow probably was overly complex for that situation. That being said, now that you are doing simultaneous development, the resulting timeline of continuing work on develop as you presented is completely normal and expected. Note that the history of develop doesn't represent the timeline of releases to production, but instead it's the actual simultaneous development on two separate "paths". Similarly, the first-parent history of master (or main), which does represent the timeline of releases to production might end up looking like:
Merge commit of r3
Merge commit of hotfix2.1
Merge commit of r2
Merge commit of r1
and that also is completely normal and expected for the master or main branch.
I don't think you need to change a thing.
Side Notes:
release branches to sometimes get merged back into develop prior to them being released to production. Normally this happens when a bug fix is important enough that you want all new and in-flight work on develop to be able to access the changes immediately. When you do this you'll have at least 2 merges of any specific release back into develop, and oftentimes more. Some tools even make it easy to automate a backflow so that every completed PR into a release branch automatically (if possible without conflicts) merges it back down to develop. Personally, I prefer not to have additional merge commits for "Merge release into develop", so I only do an extra manually merge when the team deems it necessary.release into master (or main), I prefer to then merge master into develop instead of release into develop. The reason is simply to get that extra merge commit on master back into develop now so they don't build up over time and get brought back into develop all at once when you finally have a hotfix. It also makes it a little easier to see that develop, and consequently any release branch, is fully up to date with master since the tip of master is always reachable by develop (or at least the existing release branch). Then you know you don't need to worry about blowing away a hotfix on master that someone forgot to merge back down.