Git Activity in LinearB helps you understand how work is progressing at the branch and PR level: which branches are active, which PRs are at risk, and how work moved through an iteration or release. This article consolidates the key Git Activity states and filters into one place.
TL;DR – What you can see here
- Branch & PR states – how LinearB classifies branches and pull requests.
- Iteration filters – Done, Carryover, Updated, and Merged in a given iteration.
- Risk & quality filters – High Rework, High Risk, Lightning PRs, Long Living PRs, etc.
- WIP & hanging work – what’s currently in progress and where reviews are stuck.
- Releases view – how release data is presented and filterable.
Branch & Pull Request States
Branch State
LinearB classifies each branch into one of five states:
- Active – At least one non-merge commit in the last 7 days.
- Stale – No non-merge commits in the last 7 days.
- Merged – Branch was merged into its base branch (or another branch), via PR or direct merge.
- Deployed – Branch appears in a release tag as one of the branches included in that release.
- Deleted – Branch has been deleted.
Learn more about branch states in LinearB's Metrics Glossary.
WIP (Work in Progress)
The WIP filter in Git Activity shows engineering tasks (branches) that are currently in progress – typically branches that are in an Active state and have not yet been merged or deleted.
Use this view to sanity-check what the team is working on right now:
- Confirm most active branches are tied to the iteration’s planned work.
- See if the team is spread too thin across many concurrent branches.
- Spot branches that have stayed “active” for a long time and may be stuck.
Note: The WIP filter is about branch state, not the native Draft flag on pull requests in GitHub or GitLab. Draft/WIP pull requests are handled separately (see Draft pull requests below).
Pull Request State
In Git Activity, LinearB reflects your Git provider’s native pull request state and review activity. At a high level:
- Open – PR is open and not merged (may be Draft or Ready for review).
- In Review – Open PR where at least one reviewer has started a review and left comments.
- Merged – PR has been merged into a base branch.
- Closed – PR has been closed without merging.
Draft / WIP PR behavior (how it affects cycle time and alerts) is covered in the Draft pull requests section below.
Draft pull requests
Draft pull requests are a way to signal that work is not yet ready for review or merge. They let developers push code, run CI, and request early feedback without affecting review metrics or triggering review alerts.
How LinearB treats draft PRs
- Cycle Time – Draft PRs are excluded from cycle time calculations.
- Stage time – Time while a PR is in draft is counted as Coding Time, not Pickup / Review time.
- Notifications – Draft PRs do not trigger “Review Request Hanging” or “Review Too Long” alerts until they are marked ready for review.
- WorkerB – Team and personal review alerts ignore draft PRs until they leave draft status.
Important: For GitHub and GitLab, LinearB relies on the repository’s native Draft flag. You only need the advanced naming-pattern settings described below if:
- You use Azure Repos or Bitbucket and depend on title/label conventions to mark work-in-progress PRs, or
- Your GitHub/GitLab teams choose not to use the native Draft flag and instead rely on title prefixes like [WIP] or Draft:.
Configuring draft PR detection
LinearB automatically detects draft PRs using the Git provider’s native draft status (where available). If your team uses naming cues instead of the native status, you can also configure title-based detection.
Global naming patterns (all repos)
- In LinearB, go to Settings → Company Settings → Advanced.
- Scroll to the Draft Pull Requests section.
- Add regular expressions for patterns that should be treated as draft (for example:
^\[WIP\],^Draft:,DO NOT MERGE). - Click Save.
Any PR whose title matches these patterns is treated as draft, even if the git provider doesn’t support a native Draft flag.
Per-repository patterns
- Go to Settings → Company Settings → Git.
- Click the gear icon next to the repository you want to configure.
- Scroll to the Draft Pull Requests section.
- Add the regular expressions for patterns that should mark PRs as draft in that specific repo.
- Click Save.
Use per-repo patterns when only certain repositories follow a specific WIP/Draft naming convention.
Why it matters
- Keeps cycle time and review metrics clean by excluding work that isn’t truly ready.
- Prevents false “review hanging” alerts for intentionally-draft PRs.
- Encourages consistent use of draft status, so metrics better reflect how work really flows.
Point in History
Branches are mutable: their state changes over time (Active → Stale → Merged → Active, etc.). The Point in History capability lets you see a snapshot of branch states on a specific past date.
When you select a date in the past, LinearB shows:
- The state each branch had on that date.
- The number of commits and changes up to that date.
- Work breakdown and last update time as of that date.
The current state of a branch may be very different from what you see at that historical snapshot.
Iteration Filters (Done, Carryover, Updated, Merged)
Done in Iteration
Done in <Iteration> shows all tasks (branches) that were completed during the iteration.
This view includes branches that were either:
- Merged
- Deployed
Typical filter logic:
- State: Merged OR Deployed
- Last Update: <First day of the iteration> – <Last day of the iteration>
Use this to see what the team finished in the iteration and compare to the planned scope.
Carryover from Iteration
Carryover from <Iteration> shows tasks that were not completed in the iteration and were still active after it ended.
Typical filter logic:
- Point in History: last day of the iteration
- State: Active
- Last Update: <First day of the iteration> – <Last day of the iteration>
Use this to understand what slipped and why iteration goals were missed.
Merged in Iteration
Merged in <Iteration> shows all PRs that were merged during the selected iteration.
Typical filter logic:
- PR State: Merged
- Merged between: <First day of the iteration> – <Last day of the iteration>
Updated in Iteration
Updated in <Iteration> shows all PRs that had activity during the iteration. “Update” includes things like:
- New reviews
- New comments
- Additional commits
- Merge events
- Close events
Typical filter logic:
- PR State: All
- Last Update: <First day of the iteration> – <Last day of the iteration>
Risk & Quality–Related Filters
High Interaction Pull Requests
High interaction PRs are PRs with a large number of comments in the review cycle. This can indicate:
- Low code quality or approaches that generate many review comments.
- Fundamental disagreements between author and reviewer that may need escalation.
Typical filter logic:
- Comment Count: Large (around 10+ comments per PR).
High Rework
High Rework refers to branches with a high volume of code changes and a large portion of those changes touching recently-added code.
Rework is driven by both:
- Total code changes introduced in the branch.
- Changes to code that was added in roughly the last three weeks.
More changes – especially to recent code – increase rework and can be an early signal of instability or unclear requirements.
Typical filter logic:
- State: Active (updated within the last 7 days)
- Rework: flagged as High (e.g., > ~30% of changes)
- Changes: flagged as Large (e.g., > ~300 lines of code)
High Risk
High Risk work highlights branches where risk is elevated due to both how much code changed and how much of it is touching existing logic (rather than new files).
Use this to surface branches that may need extra review or testing.
Typical filter logic:
- State: Active (updated within the last 7 days)
- New Work: relatively small share (e.g., < ~50% of changes)
- Changes: flagged as Large (e.g., > ~300 lines of code)
Lightning Pull Requests
Lightning PRs are PRs that were merged very quickly after review began. Speed can be good, but extremely fast reviews can also indicate superficial review and potential quality risk.
Typical filter logic:
- PR State: Merged
- Review Time: roughly 0–20 minutes
Long Living Pull Requests
Long living PRs are PRs that were created a long time ago and still haven’t been merged. They often point to work waiting too long for review or a slow review cycle.
Typical filter logic:
- PR State: Initiated or In Review
- Created before: roughly 30 days ago
These PRs should be prioritized to avoid stalled work and excessive cycle time.
Merged Without Review
Merged without review refers to PRs that were merged either:
- With no review at all, or
- With only self-review by the author.
This significantly increases the risk of bugs or regressions. Teams should aim to reduce this pattern as much as possible.
Review Request Hanging
Review request hanging highlights PRs where a review was requested but not started within a reasonable time.
These PRs slow down cycle time and can become bottlenecks in the delivery pipeline.
Typical behavior:
- PR was created more than ~3 days ago.
- No review has started (no review comments yet).
Releases View
Releases report
The Releases report is available from the Activity tab by selecting Releases, or by clicking a data point in the Deploy Frequency graph.
By default, the view shows releases from the last 30 days. You can adjust the range using the Event Dates filter.
Release filters
You can filter releases by:
- Team – via the team dropdown or filter menu.
- Contributors – only releases that include branches where selected developers contributed code.
- Repositories – releases for a specific repo (click a repo name to filter).
- Services – if you’ve configured services in LinearB.
- Stages – release stages (e.g., Release, or additional stages when multi-stage detection is configured).
- Event Dates – date the release occurred.
Release columns & data
Common columns in the Releases table:
- Releases – release name.
- Reference – git reference (SHA / branch / tag). Clicking copies it.
- Repositories – repo name (click to filter by that repo).
- Published At – date and time of the release.
- Stage – deployment stage; click to filter by stage.
- Connected branches – number of branches bound to this release (hover to see names; click to view in LinearB).
- Services – related service name, if configured.
- Release Detection – how the release was detected (for example deployment API, tag, or merge-commit based detection).
It’s normal for the total number of releases listed here to be higher than what you see in the Deploy Frequency report, since some releases may not be linked to reportable branches or may be on repos excluded from reporting.
Squash merges
Some repositories use squash merges, where all work in a branch is combined into a single commit when the pull request is merged.
How LinearB treats squash merges
- A pull request that is merged via squash is still treated as a completed PR/branch in LinearB.
- For branch and PR states (for example Merged or Done views), squash merges behave the same as regular merges.
Why commit counts may look smaller
With squash merges, the original series of commits is collapsed into a single new commit on the base branch. LinearB reflects this:
- The branch/PR is still counted as completed.
- The commit count for that merged work will typically show one new commit (the squashed commit), rather than the original number of commits created on the feature branch.
This is expected: squash merges reduce the number of visible commits while keeping the underlying work represented in your Git Activity and metrics.
Comments
0 comments
Article is closed for comments.