Creating releases from support branches

[dermojo]

Hi. I'm using the Gitflow workflow. Most use cases work as expected, but I'm trying to use the "release" branch type for 2 use cases:

1. Merge develop -> main and create a tag
2. Create a tag on a support branch

For case 2, I explicitly specify the support branch as parent on "git flow release start", but finishing the branch merges back to main, not support. The behavior of git-flow-avh was different in this case.

I can't find an option to tweak this. Also, configuring another branch type for the support-release case doesn't work, because the support branch name isn't fixed (e.g. support/1.0, support/2.4, ...).

Is this intended to be supported?

[dermojo]

I noticed a similar behavior for other branch types as well. E.g. creating a feature branch from a support branch (or another feature branch) works by passing the parent as additional argument, but finishing the branch always uses the branch specified in the config (develop in my case).

It would be very helpful to be able to select to finish to the parent branch.

[dermojo]

Looking through the other issues, this seems to be related to #36

[alexrinass]

@dermojo Thanks for reporting this! We'd like to understand your workflow a bit better before implementing a fix.

Could you walk us through the exact steps you take? For example, is your workflow something like this?

1. git flow support start 1.0 v1.0.0 — create a long-lived support/1.0 branch from a tag on main
2. (commit fixes/changes on support/1.0)
3. git flow release start 1.0.1 support/1.0 — create a release from the support branch
4. git flow release finish 1.0.1 — expecting this to merge back into support/1.0 and tag there

Is that the general idea? And do you also use hotfix branches from support branches in a similar way?

[bmcdonnell-fb]

I'm not sure I agree with this premise, to "Use the start point branch when finishing". At least not entirely - especially WRT #36.

In a Git Flow workflow, if have feature/1 branched off from develop, and I stack feature/2 on top of feature/1, I will generally want feature/2 to merge to develop (presumably after merging feature/1). I won't want to merge feature/2 to feature/1.

[alexrinass]

In any case, as this workflow was supported by git-flow-avh we plan to support it as well. There are two pieces to this:

1. Support branches as base branches: Support branches need to act as base branches (like main) that can serve as parents for releases and hotfixes. This means being able to create base branches dynamically based on a pattern (e.g., support/*).

2. Overriding the parent on start: Topic branches (releases, hotfixes, features) need the ability to merge back into a different parent than the one configured for their type.

We'll likely approach the parent override a bit differently than git-flow-avh though. In git-flow-avh, the base config stored on start served double duty as both the starting point and the merge target. In git-flow-next, we explicitly differentiate between the starting point (where a branch is created from) and the parent (where it merges back into), since the parent defines the branch hierarchy. So we'll probably keep base as a reference to the starting point and introduce an explicit --parent flag to make overriding the merge target more intentional.

/cc @bmcdonnell-fb

Side note: this is not related to stacked branches (#36), which is a different concept involving dependent feature branches with enforced rebase workflows.

[bmcdonnell-fb]

@alexrinass

Side note: this is not related to stacked branches (#36), which is a different concept involving dependent feature branches with enforced rebase workflows.

I would contend that it at least intersects with stacked branches, such as in the example I described. But it sounds like your solution proposed here (separate base and target) will handle that. 👍

[alexrinass]

@dermojo Regarding your first use case — git-flow-avh had a dedicated command for this: git flow release branch <version> [<name>], which merges a branch (defaulting to develop) directly into main and tags it, without creating an intermediate release branch.

We don't support this yet but we plan to cover it with a more generic promote command (#26) that merges any base branch into its parent, with optional tagging: git flow promote develop --tag v2.0.0.

[dermojo]

@alexrinass Thanks for looking into this.
You covered my/our workflow pretty well. Basically, we have long-lived support branches (created off main at some point) for older releases. We will create all kinds of topic branches from support branches, just as we do from develop - feature branches, bugfix branches, release branches (for tagging).

Creating releases from support branches means that we'll set the tag there, too. Example:

git flow bugfix start fix-1234 support/1.0
git flow bugfix finish fix-1234               # merge back to support/1.0 because that's the "parent"
git flow release start 1.0.9 support/1.0      # create a new release/tag on the support branch
git flow release finish 1.0.9                 # create tag 1.0.9 on support/1.0

We also plan to stack other branch types this way. Usually development for the next release is based on develop, but sometimes people are already way ahead working on release + 1, and for this purpose we configured an "integration" topic branch type, which is created from develop (git flow integration start integration/VERSION).
Feature branches etc. are then possibly created from this integration branch and shall be merge from this branch, too.

To sum this up, we always use parent == start point and merge back to this (possibly) "dynamic" parent.

[dermojo]

I can also imagine to have a config option telling "finish" to merge back to the stored base/start point, instead of the configured one.

[alexrinass]

@dermojo Quick follow-up question on your workflow: when you start a branch from a support branch (e.g., git flow bugfix start fix-1234 support/1.0), does anyone else on your team also work on that branch?

In git-flow-avh, the base config that tracks where a branch was started from is stored in the local Git config — meaning it doesn't travel with push/fetch/clone. So if Developer A starts a release from support/1.0 and Developer B tracks it, Developer B's local config wouldn't know the parent is support/1.0.

Is this something you've run into, or is it typically the same person who starts and finishes a branch?