Feature request: git-style branching, merging & approval gates for Prompt Management

Context

We run Langfuse Prompt Management in production for a multi-prompt LLM application (tracing + prompts together). For us prompts are engineering artifacts coupled to structured-output schemas and tool contracts, so iterating on them is a first-class activity — done by engineers and non-engineers side by side. The linear version + label model serves incremental iteration well; this request is about what it can't express.

The gaps we hits

1. No branching for parallel experimentation

When a prompt needs a fundamentally different approach (restructured instructions, different strategy — not a tweak), we want 2–4 competing rewrites evaluated side by side against the same dataset. Today the only options are:

• linear versions — serial, cluttering the one lineage with dead ends, or
• separate prompt names (task--attempt-b) with manual copy-back — loses the relationship and history.

What we'd want: fork any version into a branch, iterate in the branch, run experiments per branch, merge the winner back — with the losing branches kept inspectable. This is the same ask as #11997 (I know it's closed as not planned — hoping a more detailed pain picture and a concrete shape can reopen the conversation).

2. Promotion has a record, not a gate

Version history tells you what changed; nothing prevents a bad version from reaching the production label. On small teams the same person edits, evaluates, and promotes — i.e., pure self-review, at exactly the layer where behavior regressions are most common for us (prompt changes, not code). A lightweight gate — "open change request / PR analogue → approval required before a label can move to the merged version" — would close this.

3. The GitHub integrations are one-way

Repository Dispatch and the sync-server pattern give git visibility into prompt changes, but nothing flows back, so git can't serve as the review/audit surface. Teams that want PR-style review end up building bespoke CLIs (fetch → local edit → diff → push → promote). We built that loop ourselves; it works, but it's homegrown glue that every team in this thread seems to rebuild.

Why we don't "just use git"

We evaluated file-in-git backends. What keeps us on Langfuse is the trace ↔ prompt-version join: going from a bad generation → exact prompt version → all affected traces is our daily RCA loop, and externalizing the store to a git repo breaks that join.

So the ask is git semantics inside the existing model, not a git backend:

• branch on a prompt: cheap forks from any version
• cross-branch diff in the UI
• merge with a simple policy (prompts are single artifacts — no line-conflict machinery needed) and branch lineage preserved
• optional approval gate before a branch can merge into a protected label (e.g. production)
• API parity so experiments can pin get(name, branch=...)

Prior art

• PromptHub ships per-prompt commits, pull requests, merge, and review approvals as its core differentiator.
• LangWatch stores prompts as YAML in git with bidirectional CLI sync.

Both suggest real demand for this shape. We'd much rather stay on Langfuse — tracing, evals, and prompt management in one place — which is why we're raising this here instead of migrating.

Happy to discuss design trade-offs; we'd adopt branch-first iteration immediately if it landed.