@Abser786
That’s a great question—you’re pointing at one of the classic trade-offs with GitFlow when multiple projects share the same develop branch.

You’re right that if both teams are merging into develop, then cutting a release branch from develop will naturally pick up all merged changes—even those not production-ready. This can cause the conflict you mentioned.

There are a few common ways teams handle this:

• Feature toggles / flags: Teams merge regularly into develop, but production-incomplete features are hidden behind flags so they don’t affect the release branch.

• Project-scoped release branches: Instead of treating develop as a single integration branch for everyone, teams can maintain separate “integration” branches per project and only merge into the shared develop once both projects are production-ready.

• Release branch directly from feature branch (exception case): For urgent or isolated production releases, you can branch directly from the feature branch (or a hotfix branch) instead of from develop.

• Trunk-based alternative: Some teams sidestep this problem by using trunk-based development and releasing from main with very short-lived branches.

Regarding your suggestion to merge release branches directly into main: that is a valid simplification if your team is comfortable treating develop purely as a staging/integration branch and using main as the only stable production branch. The trade-off is that you lose some of the isolation GitFlow’s release branch model provides for parallel stabilization.

In practice, the right approach depends on your team’s release cadence and whether features can be safely toggled off if they’re not ready.