GitHub pull request workflow

A GitHub pull request workflow (GitHub Flow) is a flowchart of how one change reaches production: branch off main, commit and push, open a pull request, let CI run, get the diff reviewed, merge, and clean up behind you. The two rework loops — a check that fails, and a reviewer who asks for changes — both come back to the same place, another commit on the same branch, and that is where most of a pull request’s elapsed life is actually spent.

People draw this one to onboard a new engineer, to write down a branching policy the team has so far only followed by habit, or to settle an argument about where the process really stalls. What makes it worth drawing is its shape rather than its steps: the happy path is a straight line anyone could recite from memory, but the two rework loops rejoin at the same commit, and seeing them converge is what makes it obvious that a review comment and a red build cost the same lap.

GitHub pull request workflow main Create featurebranch Commit andpush Open pullrequest CI checks run Checkspass? Push a fix Review the diff Approved? Addresscomments Merge to main Deploy toproduction Delete branch No Yes Changesrequested Yes
Open in editor

Mermaid source

---
title: GitHub pull request workflow
---
flowchart LR
    Main([main]) --> Branch[Create feature branch]
    Branch --> Push[Commit and push]
    Push --> Open[Open pull request]
    Open --> Checks[CI checks run]
    Checks --> Green{Checks pass?}
    Green -->|No| FixBuild[Push a fix]
    FixBuild --> Push
    Green -->|Yes| Review[Review the diff]
    Review --> Approved{Approved?}
    Approved -->|Changes requested| Address[Address comments]
    Address --> Push
    Approved -->|Yes| Merge[Merge to main]
    Merge --> Deploy([Deploy to production])
    Merge --> Delete[Delete branch]

Stock Mermaid vs Line9 on this pull request workflow

Run the same source through the stock Mermaid engine and it often will not look as good. In some cases, Mermaid is able to deliver a usable graph, but not always. On this one:

The same pull request workflow through stock Mermaid — a band six times wider than it is tall, with the “No” branch label sitting on an unrelated return edge
Stock Mermaid · same source View full size ↗

Stock Mermaid lifts the two rework nodes – “Push a fix” and “Address comments” – to different levels so they seem less related — although the two play the same role. The stretched arrangement of nodes forces the return edges from each of these back to ‘Commit and push’ to be very long. The arrangement of nodes also forces the “No” edge from ‘Checks pass?’ to cross the ‘Address comments’ return edge. Making matters worse, the “No” label sits ambiguously on the line crossing point. The whole graph comes back six times wider than it is tall, which requires it to be scaled down to fit within a page horizontally so that labels are harder to read. Line9 lays out the same source at 1.8:1 across two bands, with both rework loops dropping to a single row, no edge crossing another, and every label on the edge it belongs to.

For a fuller product comparison — layout, export, CLI, and pricing — see Line9 vs mermaid.live.

Render your own

Paste any Mermaid flowchart into the free online editor — no account needed. Prefer the terminal? Install the line9 CLI (free for personal use).

More scenarios on the Mermaid examples hub.