Your median cycle time looks healthy, yet every release still ends in merge conflicts, rebases and big-bang reviews. Learn what engineering leaders on Reddit say about long-lived branches and the trunk-based vs GitFlow debate at enterprise scale, and how Keypup MCP uses pull request dates, target branches, commits, reviews and mergeability to measure branch lifetime, find where branches live longest and land aging work before it drifts into conflict.
TL;DR: In large engineering organizations, the median pull request merges in a day or two — but one in four branches lives for more than a week, and that tail is where merge conflicts, rebases, rework and oversized reviews come from. Median cycle time hides it completely. This is merge hell, and it's usually caused by the branching model rather than by the teams. The Keypup MCP Server reads every pull request's first commit, creation and merge dates, target branch, lines changed, review dates, mergeability, Keypup's recommended action and the commits it contains. Your AI assistant can then measure branch lifetime, track its percentiles over time, compare branching models across repositories, show what long-lived branches cost in rework, and land the aging pull requests that can still be saved.
Ask an engineering organization whether it does trunk-based development and most will say "mostly". Ask how long its branches actually live, and nobody knows — because no standard dashboard measures it.
In a team of eight, a long-lived branch is visible: everyone knows Sam has been on the payments refactor for three weeks. In an organization of 1,500 engineers across 200 repositories, long-lived branches are invisible for structural reasons:
main, others go through develop, others maintain release/* branches. Each model produces different branch lifetimes, but they are all averaged together.The result: organizations argue about trunk-based development vs GitFlow on principle, without data on how either is actually working for them.
Every day a branch lives, the base branch moves further away. The longer the gap, the more likely the branch has to pull the base branch back in, the more conflicts it hits, and the more likely those conflicts are resolved under release pressure.
Long-lived branches accumulate changes. They arrive as 1,000-line pull requests that are hard to review properly, get changes requested more often, and go through more rounds of rework after the first review.
Work on a long-lived branch is invisible until it merges. A feature that's "90% done" for three weeks is a roadmap risk that no status report shows — until it collides with three other features in the same release.
Long-lived branches and the trunk-based vs GitFlow debate are among the most recurring topics wherever staff engineers, engineering managers and directors at large organizations compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/devops, r/EngineeringManagers and r/cto.
"Every release week is the same. Five feature branches that have lived for a month all try to land on develop on the same day, and three senior engineers spend two days resolving conflicts in code they didn't write. Then we wonder why the release slipped."
"Leadership keeps asking us to 'adopt trunk-based development'. Half our repos already merge to main daily and the other half have develop, release and hotfix branches from 2016. I have no way to show which teams actually have a branch problem and which don't."
"Our cycle time dashboard says 1.9 days. It's been 1.9 days for a year. Meanwhile the number of 'rebase hell' messages in our team channels has doubled. The metric is technically right and completely useless."
The pattern holds: everyone feels the pain of long-lived branches, but nobody can show how long branches live, where, or what it costs — because the metrics they watch are averages over all the work.
The Keypup Model Context Protocol (MCP) Server gives your AI assistant structured access to the pull requests Keypup imports from GitHub, GitLab, Bitbucket and Azure DevOps. For every pull request, that includes its state (open, draft, merged or closed), repository, target (base) branch, first commit, creation and merge dates, last commit date, lines changed, review request, first review and changes-requested dates, mergeability (mergeable or conflicting), Keypup's recommended action, and the commits it contains, with their messages.
In the prompts below, branch lifetime is the number of business days from a pull request's first commit to its merge, and a long-lived branch is one that lived more than 5 business days. You can pick your own threshold; the important thing is to keep it consistent.
The first question is simple: how long do branches really live?
MCP Prompt:
For pull requests merged in the last 12 months, show how many there are, the median business days from first commit to merge, and the share whose branch lived more than 5 business days. Also count the open or draft pull requests that currently conflict with their base branch.
Output: Branch Lifetime Health Check — Last 12 Months
Key Insight: The median branch merges in under two days, but almost one merged pull request in four lived on its branch for more than a week — 11,180 of them. And 547 open pull requests already conflict with their base branch right now.
A median is one number. A histogram shows where the work actually sits — and how big it gets.
MCP Prompt:
Show a histogram of pull requests merged in the last 12 months by business days from first commit to merge, in buckets: under 1, 1–2, 3–5, 6–10, 11–20 and more than 20. Under each bucket, show the median lines changed.
Output: How Long Do Branches Really Live?
Key Insight: Branch lifetime and size grow together. A branch that lives more than 20 business days carries a median of 1,240 changed lines — 27 times more than one merged the same day. Long-lived branches aren't just late; they arrive as big-bang changes.
If the median is stable, is everything fine? Percentiles answer that.
MCP Prompt:
By quarter of merge over the last six quarters, plot the median, 75th percentile and 90th percentile business days from first commit to merge for merged pull requests, as three lines.
Output: The Tail Is Growing, Not the Median
Key Insight: The median barely moved, from 1.6 to 1.8 business days, while the 90th percentile went from 6.2 to 10.6. A dashboard showing median cycle time would report stable delivery while the slowest tenth of the work took 70% longer to integrate.
The trunk-based vs GitFlow debate is usually settled by opinion. The target branch of each pull request lets you settle it with data.
MCP Prompt:
For pull requests merged in the last 12 months in our six largest repositories, show a heatmap of the median business days from first commit to merge, by repository and by target branch grouped as main or master, develop, and release branches.
Output: Where Branches Live Longest
Key Insight: In every repository that uses both, pull requests targeting develop live three to four times longer than those targeting main. The branching model, not the team, is the strongest predictor of long-lived branches.
Branch lifetime only matters if it costs something. Comparing short-lived and long-lived branches side by side makes the cost visible.
MCP Prompt:
Compare merged pull requests from the last 12 months whose branch lived 5 business days or less with those that lived longer. For each group, show the share that contain a commit merging the base branch into the feature branch, received a changes-requested review, got new commits after the first review, and changed more than 500 lines.
Output: What Long-Lived Branches Cost
Key Insight: Nearly half of long-lived branches had to pull the base branch back in at least once — five times the rate of short-lived ones. They're also 2.6 times more likely to have changes requested and twice as likely to be reworked after review. Every extra day on a branch adds integration and review work.
Knowing the problem is useful. Unblocking the branches that are aging right now is better.
MCP Prompt:
For open or draft pull requests created more than 10 business days ago, group them by Keypup's recommended action and show the result as a donut chart.
Output: Which Aging Branches Can Still Be Landed?
Key Insight: A third of aging pull requests already conflict with their base branch and need a rebase before anything else can happen. Another 110 are approved and only need someone to merge them — the fastest win before they drift into conflict too.
The last step turns the analysis into something each repository owner can act on.
MCP Prompt:
For our six largest repositories, show for pull requests merged in the last 12 months: merged pull requests, median business days from first commit to merge, share of branches that lived more than 5 business days, share containing a merge of the base branch, and the target branch most pull requests use. Add the number of open pull requests conflicting with their base branch today.
Output: Branch Health Scorecard by Repository
| Repository | Merged PRs | Median Lifetime (bd) | Long-Lived | With Base Merges | Conflicting Now | Main Target Branch |
|---|---|---|---|---|---|---|
| erp-integration | 1,980 | 6.4 | 58% | 41% | 96 | develop |
| core-platform | 6,420 | 3.1 | 34% | 27% | 88 | develop |
| mobile-app | 4,050 | 2.9 | 31% | 18% | 47 | develop |
| data-pipeline | 3,140 | 2.6 | 29% | 22% | 61 | develop |
| payments-api | 3,860 | 1.7 | 17% | 11% | 29 | main |
| checkout-web | 5,210 | 0.9 | 7% | 4% | 12 | main |
Key Insight: The four repositories that integrate through develop have the four longest median branch lifetimes, and between them hold 292 of the 333 pull requests conflicting today. Checkout-web, which merges straight to main, merges 93% of its pull requests within 5 business days.
Every number above comes from pull request and commit data Keypup already imports. It helps to be precise about what that data is — and what it isn't.
Keypup records each pull request's first commit date and merge date, and can compute the business days between them, as well as medians and percentiles. Note that the first commit date is the earliest commit in the pull request: if authors rewrite history with an interactive rebase before opening it, the branch may look younger than it really was.
Each pull request carries its base branch — the branch it merges into — and its repository. Grouping base branch names into main/master, develop and release/* is done in the prompt with a pattern match, so it adapts to your own naming conventions.
Keypup imports the commits of each pull request, with their messages. A commit merging the base branch into the feature branch is detected from Git's default merge commit message, such as "Merge branch 'main' into feature-x". This depends on how your teams sync branches: teams that rebase instead of merging, or that edit merge commit messages, won't show up in this measure, so compare it across repositories that use the same practice.
A changes-requested review comes from the pull request's review rejection dates, and rework after review compares the last commit date with the first review submitted date. Both are recorded automatically by your Git platform.
Each open pull request has a mergeability state — mergeable, conflicting or unknown — reported by your Git platform, and a recommended action computed by Keypup from its review, approval, build and mergeability state: rebase, assign reviewer, review, fix build, merge and so on. Mergeability is a current state, not a history: to track how many pull requests conflict over time, run the prompt on a regular schedule and compare the results. That's what turns aging branches from a statistic into a to-do list.
Before Keypup MCP:
After Keypup MCP:
develop accounted for most long-lived branches"We were about to force trunk-based development on 170 repositories. The data showed a third of them were already there. We focused on the ones that weren't, and got the result in a fraction of the time."
Before Keypup MCP:
After Keypup MCP:
"Our median said everything was fine for a year. The 90th percentile told the real story. Now we report both, and nobody argues about whether we have a branch problem anymore."
Connect GitHub, GitLab, Bitbucket or Azure DevOps to Keypup. Pull requests, their dates, target branches, sizes, reviews, mergeability and commits are imported automatically.
Decide what branch lifetime means (first commit to merge, in business days) and what counts as long-lived (for example, more than 5 business days). Use the same definitions in every prompt so quarters and repositories stay comparable.
List the naming patterns your repositories use for trunk, integration and release branches — main, master, develop, release/*, hotfix/* — so the heatmap groups them correctly.
Follow the MCP documentation to connect Keypup to Claude, ChatGPT, Cursor or any MCP-compatible assistant.
Run the health check and percentile trend to set a baseline, and report the 75th or 90th percentile alongside the median. Use the heatmap and scorecard to decide which repositories to move closer to trunk-based development, and run the aging pull request triage every week.
A long-lived branch is a feature branch that stays open for days or weeks before being merged. There is no universal threshold, but many organizations consider anything over 3 to 5 business days long-lived, because the base branch has typically moved enough by then to cause conflicts.
Branch lifetime is usually measured from the first commit on the branch to the moment the pull request is merged. Measuring it in business days avoids weekends inflating the numbers, and reporting percentiles rather than only the median shows the long tail where the problems are.
For most teams shipping continuously, trunk-based development produces shorter-lived branches, smaller pull requests and fewer merge conflicts. GitFlow can still make sense for products with versioned releases. Comparing branch lifetime by target branch in your own repositories shows which model is actually working for each team.
Median cycle time describes the typical pull request. If most pull requests merge quickly, the median stays flat even when the slowest pull requests get much slower. The 75th and 90th percentiles reveal the long-lived branches that drive merge conflicts and release delays.
You can't fix merge hell by looking at averages. Keypup MCP shows how long branches really live, where, and what it costs:
✅ Measuring branch lifetime and the share of long-lived branches ✅ Seeing the distribution, and how size grows with lifetime ✅ Tracking the tail with percentiles, not just the median ✅ Comparing branching models across repositories by target branch ✅ Showing the cost in base branch merges, changes requested and rework ✅ Triaging aging pull requests by what they need to land ✅ Giving every repository a branch health scorecard to act on
Ready to find out how long your branches really live? Connect the Keypup MCP Server and ask your AI assistant.
Join teams already using AI to make data-driven decisions faster than ever.
Compare the 6 best engineering metrics tools for multi-team benchmarking in 2026 — Keypup, LinearB, Swarmia, Jellyfish, Faros and Appfire Flow — on cross-team benchmarking, org-level rollups, DORA Metrics, Git-to-ticketing linking, custom KPIs, AI capabilities and data security. See how to compare teams on equal terms and find where your delivery process is broken.
In large engineering organizations, thousands of pull requests are closed without merging or left to go stale every year, and nobody measures the cost. Learn what engineering leaders on Reddit say about abandoned pull requests, and how Keypup MCP uses pull request state, review, size, mergeability and Jira link data to size the PR graveyard, find where work dies, and triage stale pull requests before they are lost.
Enterprises hire hundreds of engineers a year, but almost none can say how long it takes them to ship at full speed, where they get stuck, or whether onboarding is improving. Learn what engineering leaders on Reddit say about the onboarding ramp-up tax, and how Keypup MCP uses pull request, review and Jira data to measure time to first merge, ramp-up curves, review friction and onboarding load.