A flexible, modern approach to the popular git-flow branching model. Download the CLI tool to get started with a better Git workflow: brew install git-flow-next
Hey Product Hunt 👋 I'm Bruno from the Tower team, and we also work on git-flow-next.
git-flow-next is the successor to the original git-flow, the branching model that has organized feature, release and hotfix branches for countless teams since 2010. We rebuilt it from scratch in Go, and it's fully compatible with your existing git-flow setups. It's free and open source, and it's endorsed by Vincent Driessen, the creator of git-flow, which means a lot to us.
Version 2.1 adds worktrees, the feature you've asked for most:
Start a feature in its own directory with --worktree, with no more stashing and switching
Jump between worktrees with one command (git flow feature checkout)
Make worktrees the default, so Claude Code, Codex or any other agent that starts a feature gets its own directory, letting them work in parallel without stepping on each other's toes
Finish a feature and its worktree is cleaned up for you
In the AI era, running several agents side by side is quickly becoming the norm, and worktrees are what make that safe.
Worktrees as the default is the change that makes the most sense to me right now. Running a few agents in parallel in one checkout always ends with someone stepping on a half-finished change, so giving each feature its own directory — and cleaning it up on finish — removes a lot of that friction. I'm curious how it handles a worktree when a feature branch already has uncommitted work elsewhere: does it refuse, move it, or leave that decision to the user?
@jcbuilds It never moves uncommitted work. Depending on the command, it either refuses or sends you to where the branch is checked out, and you decide what happens to the changes.
Replies
gitflow or tbd, that is the question.
Thanks so much for hunting us, @fmerian! 🙌
Hey Product Hunt 👋 I'm Bruno from the Tower team, and we also work on git-flow-next.
git-flow-next is the successor to the original git-flow, the branching model that has organized feature, release and hotfix branches for countless teams since 2010. We rebuilt it from scratch in Go, and it's fully compatible with your existing git-flow setups. It's free and open source, and it's endorsed by Vincent Driessen, the creator of git-flow, which means a lot to us.
Version 2.1 adds worktrees, the feature you've asked for most:
Start a feature in its own directory with --worktree, with no more stashing and switching
Jump between worktrees with one command (git flow feature checkout)
Make worktrees the default, so Claude Code, Codex or any other agent that starts a feature gets its own directory, letting them work in parallel without stepping on each other's toes
Finish a feature and its worktree is cleaned up for you
In the AI era, running several agents side by side is quickly becoming the norm, and worktrees are what make that safe.
Want to dig deeper?
Blog post 👉 https://git-flow.sh/blog/posts/hello-worktrees/
Video walkthrough (under 4 min) 👉 https://youtu.be/vAFvBLcnsG8
GitHub repo 👉 https://github.com/gittower/git-flow-next/
We'd love your feedback. Happy branching!
Worktrees as the default is the change that makes the most sense to me right now. Running a few agents in parallel in one checkout always ends with someone stepping on a half-finished change, so giving each feature its own directory — and cleaning it up on finish — removes a lot of that friction. I'm curious how it handles a worktree when a feature branch already has uncommitted work elsewhere: does it refuse, move it, or leave that decision to the user?
@jcbuilds It never moves uncommitted work. Depending on the command, it either refuses or sends you to where the branch is checked out, and you decide what happens to the changes.