merge - Why Git Flow suggests that merging feature branches to dev branch instead of release branch

Question

We want to switch to Git flow but i have some concerns because there are two different teams using same repository. team A want to use dev branch for committing however team B creates feature branches and works there.Team A should make live deployments almost every days of week, in other hand team B prepares weekly release packages for deployments.

in this case it may be hard for us that merging feature branches to both dev and release branches. Thats why i want to merge the feature branches to the release branches directly. Also we may want to park the release branches for a while on demands.However git flow does not suggest merging feature branches to the release branch. According to flow we should merge our feature branches to dev branch, after that we may create/update release branch from dev.

Long story short i will need to update the dev and release branches with each other just before deployment, or something like that. it seems doesn't make sense.

so, what the best way to manage this situation on git flow.

question from:https://stackoverflow.com/questions/65877563/why-git-flow-suggests-that-merging-feature-branches-to-dev-branch-instead-of-rel

Answer 1

The answer is quite simple:

• Team A does not want to use feature branches → they want to use a branching & merging model different from Git Flow.
• Team B wants to merge feature branches directly to the release branch because of team A → they want to use a branching & merging model different from Git Flow.

Conclusion: Don't use Git Flow, just use Git.

I am saying this, assuming everyone is trained in using plain vanilla Git and not just an abstraction layer like Git Flow. Actually, Git Flow is not a product but a branching & merging model, like I said before. The Git add-on with the same name or several IDE integrations of the Git Flow model are just syntactic sugar. If you want to deviate, don't use it.

---

Somewhat unrelated technically, just thinking aloud as a seasoned (~15 years) agile coach: It says something about team culture and collaboration of two teams contributing to the same product and committing to the same repository that they cannot find a common strategy with regard to SCM and release cycles.