Your Kanban board is lying to you (and Git knows it)

Look at your team's board right now.

How many tickets are in "In Review" that haven't been looked at in three days? How many are in "In QA" even though nobody's tested them? How many jumped straight from "In Progress" to "Done" without ever appearing in the intermediate columns?

If you're like most teams, the answer is "a lot." Your board is not reflecting reality. It's a fiction your team politely maintains.

Here's the uncomfortable truth: your Git repository knows the real state of every ticket. Your board just hasn't caught up.

This article is about bridging that gap.

The problem: columns designed by process people, not by engineers

Most boards are designed by someone who thinks about process, not about what actually happens in Git. That's why you end up with:

• "Ready for Development" — a holding pen for tickets nobody wants to admit aren't ready. If it's prioritized and has detail, it's "To Do." If it doesn't, it's still "Backlog."
• "Ready for QA" — this implies a manual handoff. If the code is merged and deployed to a place QA can access, it's in QA. The deployment is the handoff, not a ticket drag.
• "Deployed" as a column separate from "Done" — if the code is in production and verified, it's done. If it's deployed but not verified, it's still in QA (in production). A column between them means nobody is verifying production deployments. These columns feel orderly on a wiki diagram. In practice, they're fiction. Tickets skip them. Developers lie about their state. The board drifts from reality.

The test: can someone verify the column from Git alone?

Here's the rule that cuts through all the noise:

Every column must correspond to a state that someone can verify, independently of anyone else's memory.

"In Progress" passes this test — is there a branch with commits? Verifiable.

"Code Review" passes — is there an open PR? Does it have an approving review? Verifiable via gh pr view or the hosting platform's API.

"Ready for Testing" fails — ready according to whom? Tested where? This is a human statement, not a Git state.

If a column can't be verified from the repo, one of two things is happening:

1. The column represents a task-flow state, not a code-flow state. That's fine — but it needs to be a lateral exit, not part of the main flow. "Blocked" and "Needs Spec" are valid columns, but they're paused states, not progression states.
2. The column is fiction. Remove it, or fix the process so it becomes real. ## Two dimensions that most boards collapse into one

The biggest insight I had while designing boards with teams: there are two independent dimensions of ticket state, and teams keep smashing them into a single horizontal flow.

Code-flow columns (left to right): To Do → In Progress → In Review → In QA → Done. These map directly to Git states.

Task-flow columns (lateral exits): Blocked, On Hold, Needs Spec, Waiting for Client. These don't map to Git at all — they reflect the state of the work, not the state of the code.

A ticket in "Blocked" still has a Git branch open. It hasn't moved backward in the flow — it's paused. When you separate these two dimensions, you prevent the common mistake of adding "Blocked" as a column between "In Progress" and "In Review," which breaks the flow and confuses everyone.

The reality: columns that get skipped

On paper, tickets move through every column. In practice, developers skip half of them.

Tickets jump from "In Progress" directly to "Done" — skipping "In Review" and "In QA" entirely. Why? Because the developer merged the PR, verified it themselves in production, and dragged the ticket in one motion.

This isn't laziness. It's the board not matching reality. If the team doesn't have a dedicated QA person or a staging environment, the "In QA" column is fiction. Tickets skip it because the state it represents doesn't exist.

The rule: if a column is consistently skipped, remove it or fix the process. Either add the missing step (a real QA phase, a real staging environment) or remove the column that pretends it exists. A board with skipped columns is a board that lies.

The solution: let Git move the tickets

The best boards are updated by Git events, not by humans dragging cards. Most tracking systems support this natively:

• Opening a PR moves the ticket to "In Review" — automatically
• Review approval can move it to "Approved" — automatically
• Merging the PR moves it to "In QA" or "Done" — automatically
• Tagging a release can move it to "Done" — automatically Here's a GitHub Actions workflow that moves a GitHub Projects card when a PR is opened or merged:

# .github/workflows/board-automation.yml
name: Board automation
on:
  pull_request:
    types: [opened, closed]

jobs:
  move-card:
    runs-on: ubuntu-latest
    steps:
      - name: Move to In Review when PR opens
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        with:
          script: |
            // Move the linked issue to "In Review" column
            // Uses GitHub Projects V2 API
            const query = `mutation($projectId: ID!, $itemId: ID!, $fieldId: ID!, $value: String!) {
              updateProjectV2ItemFieldValue(input: {
                projectId: $projectId, itemId: $itemId,
                fieldId: $fieldId,
                value: { singleSelectOptionId: $value }
              }) { projectV2Item { id } }
            }`;
            // projectId, fieldId, and optionId come from your project's
            // settings — query them once with the GraphQL explorer

      - name: Move to In QA when PR merges
        if: github.event.action == 'closed' && github.event.pull_request.merged
        uses: actions/github-script@v7
        with:
          script: |
            // Same mutation, different singleSelectOptionId
            // pointing to the "In QA" column

For Jira, it's even simpler — built-in automation rules handle this:

Rule 1: Trigger: Pull request created. Condition: Issue status is 'In Progress'. Action: Transition to 'In Review'.

Rule 2: Trigger: Pull request merged. Condition: Issue status is 'In Review'. Action: Transition to 'In QA'.

Linear, Shortcut, and Azure DevOps have similar integrations. The specifics differ, but the pattern is universal: Git event → webhook → board transition.

What you need to make this work

The automation is trivial. The discipline it requires is the hard part:

1. Branch names must include ticket IDs.

# Good — automation can match on this
git checkout -b feature/PROJ-247-search-filters

# Bad — automation has nothing to match
git checkout -b sam/search-thing

2. PR descriptions must reference the ticket.

gh pr create --title "feat(search): add filters" \
             --body "Closes PROJ-247"

3. Accept that some transitions stay manual.

"In Progress" is manual — and that's fine. When a developer picks up a ticket, they drag it and create a local branch. Nobody else knows about the branch until they push. Moving the ticket is faster than pushing a WIP commit just to trigger automation, and it avoids polluting Git history with empty commits.

The goal isn't 100% automation. The goal is that the board reflects reality, even when nobody has time to update it.

Reading the board from Git (when you don't trust the board)

Once you accept that Git is the source of truth, you can answer board questions without even looking at the board.

"What's actually in progress right now?" Remote branches ahead of main with no open PR:

git fetch --prune
for branch in $(git for-each-ref --format='%(refname:short)' refs/remotes/origin/ \
                | grep -v 'origin/main$' | grep -v 'origin/HEAD'); do
  ahead=$(git rev-list --count origin/main.."$branch" 2>/dev/null)
  [ "$ahead" -gt 0 ] || continue
  has_pr=$(gh pr list --head "${branch#origin/}" --state open --json number --jq 'length')
  [ "$has_pr" = "0" ] && echo "In Progress: $branch ($ahead commits ahead)"
done

"What's in review?" Open PRs — simplest query, most useful:

gh pr list --state open \
  --json number,title,author,reviewDecision,createdAt \
  --jq '.[] | "\(.number)\t\(.author.login)\t\(.reviewDecision // "PENDING")\t\(.title)"'

"What's merged but not deployed?" Commits on main since the last production tag — the invisible column most teams don't track:

# What's on main that hasn't been tagged yet?
git log --oneline $(git describe --tags --abbrev=0)..origin/main

# Extract ticket IDs — these are "done but undelivered"
git log --pretty=%s $(git describe --tags --abbrev=0)..origin/main \
  | grep -oE '[A-Z]+-[0-9]+' | sort -u

"What's actually in production right now?" Tickets referenced by commits reachable from the production tag:

CURRENT_PROD_TAG=$(git describe --tags --abbrev=0 --match 'v*')
git log --pretty=%s ${CURRENT_PROD_TAG} \
  | grep -oE '[A-Z]+-[0-9]+' | sort -u

Run these for a week. Compare against what the board shows. If they disagree, the board is lying — and now you have the data to fix either the board or the process.

The mindset shift

The board isn't the truth. It's a summary of the truth that drifts whenever someone forgets to drag a ticket.

Git is the truth. Every branch, every PR, every merge is a real event with a real timestamp. You can't forget to tell Git — it records everything automatically, as a side effect of doing the work.

Teams that embrace this get three wins:

1. The board starts matching reality (because Git drives it, not human memory)
2. "Where is this ticket?" gets one answer, not three
3. Standup meetings stop being ticket-hunting exercises and start being real conversations about blockers That's what a good board does. That's what yours could be doing, if you let Git update it.

This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book covering Git the way it's actually used in real engineering teams — including a full chapter on aligning board columns with Git states.

Related: What actually happens when you git merge --no-ff.

See all my articles on Git and engineering practice: dev.to/matutetandil.