Question: Support for git worktree

[gcapnias]

This is more than just a question. git-flow-next supports well-known Git workflows, but a new approach is emerging — one used by coding agents working in parallel.

Instead of keeping branches in the same folder within the file system, coding agents use different paths for each branch through git worktree.

Could git-flow-next be adapted to support a workflow that relies on worktrees rather than branches in a single path?

I think it’s exciting to imagine a tool that guides the workflow rather than leaving it up to the coding agent.

What are your thoughts?

[alexrinass]

Thanks @gcapnias — this is something we're actively thinking about, and the AI-agent angle is exactly one of the use cases driving it.

A quick clarification first: git-flow-next already works inside a worktree today. If you (or an agent) run git worktree add ../feat-foo -b feature/foo and then run git flow feature finish from that worktree, everything works correctly — config is read from the shared repo, merge state is stored per-worktree (so two agents running feature finish in parallel don't collide), and hooks resolve properly. We have explicit tests for this. So at the basic level, worktrees + git-flow-next already compose.

What you're describing is the next step: having git-flow-next guide the worktree lifecycle alongside the branch lifecycle, so the agent (or human) doesn't have to manage the two separately. That's on the roadmap and is being discussed in #45. The rough shape:

• Opt-in config like gitflow.feature.worktreeBase = ~/Dev/myproj-worktrees/{branch} so git flow feature start foo creates the branch and a worktree in one step.
• git flow feature checkout foo switches into the worktree directory instead of running git checkout in place.
• A status view of all managed worktrees, showing which can be safely pruned after a finish.
• Detection of submodules and other known-tricky cases, with a clean warning rather than a silent failure.

It stays fully opt-in — nothing changes for users who don't enable it — but for parallel/agent workflows it removes the need to script worktree management around git-flow.

Would love your input on #45, especially on the AI-agent side: what does the agent need from the tool to keep things deterministic? E.g. predictable worktree paths, a way to query "which worktree holds branch X", post-finish cleanup behaviour, that sort of thing. The more concrete the use case, the better the design.