git flow merge down/left continously

Question

Git flow ensures the following way that changes to master and release eventually end up in develop:

• hotfixes branch from master and merge back to develop. If there is an active release branch it merges there and only propagates to develop once release is merged to master and develop.

• changes to release are only merged to develop once the release is finished

I wonder why there is the delay until the release is completed. Wouldn't it be much easier to simply merge master to release and develop whenever a change to master occurs and release to develop when release changes?

This way I would get changes immediately reflected in all relevant branches and I would not need to think about what to merge where and when.

The only explanation I could think of is that git flow decided that having less frequent merges outweighs the benefit of having an up to date/synchronized codebase across branches.

Answer 1

Git Flow actually supports what you are asking. Fortunately one of your premises is flawed:

changes to release are only merged to develop once the release is finished

That's not actually true. You are allowed (and encouraged) to merge any changes on a release branch into develop as often as you need. In the branching strategy graphic, notice there are arrows from the green release commits back to develop prior to completion. There is also a comment bubble which states:

Bugfixes from rel. branch may be continuously merged back into develop.

At my organization our release branches live for about 7-10 days, and on average I'd say we merge release back into develop at least once prior to completion. So for hotfixes, as soon as they are merged into release, feel free to merge release back into develop when it makes sense to do so.

As a related side note, when completing release, I prefer to merge release into master and then master into develop. (Instead of release into develop.) This provides 2 benefits:

1. If you don't merge master into develop, then after you have many releases before a hotfix, when you finally create a hotfix, when merging it into develop you bring along with it a bunch of old merge commits that were sitting on master. This can add confusion.
2. At all times when a release branch exists, you want to be sure that everything in master is in release. If you don' t do this you might accidentally blow away a hotfix that someone completed into master but forgot to merge back into release. Perhaps the easiest way to automate this is to check that the HEAD of master is in release. But this can only be true if you merge master back to develop (or back to release if it exists and you just completed a hotfix).

Answer 2

The problem is what develop is for: an integration branch to test the features together.
Adding an active master (and its hotfix) would tamper with the integration.

That is why I prefer using gitworkflow (that I present here): you can rebase any feature branch on top of master (where an hotfix can be merged anytime).
By rebasing your feature branch, you are replaying your changes on top of the latest master (and its hotfix).

Later on, you can merge any feature branch you need to "next" (the develop branch)

Finally, when you know which feature branch you actually have selected for the next release, you merge (again) those feature branches to master.