TILLFORGE · PULL REQUESTS

Reviews, a real merge gate, honest correlation.

Open a PR, get it reviewed, and merge behind a gate that enforces required approvals of the current head and required status checks — no green-then-sneak-a-push. External CI gates merges through the checks API, CODEOWNERS routes reviewers, and every shipped release is correlated with the crashes it caused.

01Pull requests

Open, review, merge

A PR proposes merging a source ref into a target. Review states are approved, changes_requested, and commented. Merge with merge, squash, or rebase.

bash

# Open a PR, review it, merge behind the gate.
tilldev forge pr create acme-api --title "Add rate limiter" \
  --source feat/rate-limit --target main
tilldev forge pr ls acme-api --state open
tilldev forge pr get acme-api 42
tilldev forge pr review acme-api 42 --state approved   # or changes_requested | commented
tilldev forge pr merge acme-api 42 --strategy squash   # merge | squash | rebase

The merge itself is performed without a server-side working tree — the node computes the merged tree and commit directly, and a conflict is reported without mutating anything. Nothing is auto-checked-out on the server, which is also why a malicious tree can’t escape a checkout (there isn’t one).

02The gate

The merge gate enforces the branch policy

Merge is not a rubber stamp. The control plane re-checks the branch policy at merge time and refuses if it isn’t satisfied:

Requirement	What it enforces
Required approvals	Enough approving reviews of the current head — an approval is invalidated by a new push, so you can’t approve then quietly change the diff.
Required checks	Every named status check on the head commit is green.
Signed / linear	If the branch requires signed commits or linear history, the merge honors it.

03Checks API

External CI gates merges

TillForge ships the checks / status API so your existing CI can gate merges today. Post a state for a commit and context; the merge gate reads it. Reports are idempotent per repo + commit + context, and the --url back-link is SSRF-validated — it is stored and shown, never fetched by us.

bash

# Report a status check from your CI (idempotent per repo+sha+context).
tilldev forge check acme-api --sha <commit-sha> \
  --context ci --state success --url https://ci.example.com/run/123
tilldev forge checks acme-api --sha <commit-sha>       # read the status set

Our own CI runner is a later phase

TillForge does not run your CI yet — the checks API is the seam so external CI gates merges. An in-house sandboxed runner is a deliberate later phase, because a build runner is the single largest remote-code-execution surface in a code host and we won’t ship it before its isolation is right.

04CODEOWNERS

CODEOWNERS routes reviewers

A CODEOWNERS file (gitignore-style globs, last match wins) maps paths to owners. TillForge diffs a PR, finds the owners of the changed files, and routes the review request to them — so the right people see the change without anyone remembering to add them.

bash

# Who owns the files a PR changes → reviewer routing.
tilldev forge codeowners acme-api --rev main           # the CODEOWNERS map

05Correlation

Which release caused which crash

Because the commit and PR graph is local, TillForge correlates the code you shipped with the crashes it caused — natively, no external webhook. It joins a repo’s recent commits to your TillPulse releases by commit_sha and reports a crash-free percentage and an A–F grade per release.

bash

tilldev forge correlation acme-api --rev main

Honest granularity

Attribution is clean at release granularity — the crash-free delta versus the prior release. TillForge attributes to a specific PR only under continuous deploy (one PR ≈ one release) or via ranking; it never claims “PR X did it” when a release bundles many PRs.

The branch policy behind the gate is in Branch protection; every command here is in the CLI reference. Back to the TillForge overview.