∴ Integration · GitHub
Your experimentation backlog, delivered as pull requests.
Trevo reads a repository through its GitHub App, writes only to trevo/* branches, and hands every experiment to your existing review process. The code and the decision history stay where engineers already work.
#1482 exp: quote tax before the payment step trevo/experiment/tax-upfront · checks passing#1479 exp: progressive signup disclosure merged 3 days ago · running#1474 cleanup: remove losing hero variant flag deleted · code restored to winner
How does Trevo integrate with GitHub?
Trevo installs as a GitHub App scoped to the repositories you choose. It reads your code to write experiment proposals with evidence cited, and when you approve one, it opens a pull request on a trevo/* branch — never on your default branch — containing the variant behind a feature flag. Your code review and CI are the only gates; nothing runs until a human merges. When an experiment concludes, Trevo opens a cleanup pull request that removes the losing variant and the flag, so the repository stays as clean as if the experiment had never run — except now you know the answer.
How it works
Install once, and experiments become a kind of pull request your team reviews.
Install the GitHub App
Choose “only select repositories” and pick the repo you experiment on. Read access to code; write access exercised only on trevo/* branches.
The scan becomes proposals
Trevo maps routes, components, and server logic, then writes experiment proposals citing the files it read — before any SDK is installed.
Approval opens a pull request
The hypothesis is the PR description; the variant is real code behind a flag with the test file included. CI runs like on any branch.
Merge to run, merge to clean up
Merging starts the experiment. When it concludes, a cleanup PR removes the loser and the flag — flag debt never accumulates.
Guardrails engineering teams actually accept
Nobody wants a bot with push access to main. Trevo’s footprint is deliberately narrow: branch-scoped writes, PRs as the only delivery vehicle, your review as the only trigger, and a temporary clone that is discarded after each read.
- ✓Writes only to trevo/* branches — never your default branch
- ✓Reads from a temporary clone, then discards it
- ✓Never used to train AI models
read code, on the repos you selectwrite trevo/* branches onlymerge never — that is your reviewdeploy never — your pipeline, your call
The experiment log your team will actually read
Every hypothesis, variant, and decision lives in pull requests — searchable, diffable, and attached to the code it changed. Six months later, “did we ever test that?” is a git log away, not an archaeology project in a dashboard.
- ✓Hypothesis and evidence in the PR description
- ✓Winners merge like any other change
- ✓Cleanup PRs close the story of every loser
const variant = useExperiment(HERO_OFFER); if (variant === "brand-line") { return <HeroBrand />; } // winner: concrete offer (merged #1461) return <HeroOffer />;
What this looks like in practice
What arrives in your repo — illustrative shapes of the pull requests Trevo opens.
Δ trevo/experiment/*
Experiment PR
The variant behind a flag, exposure wired, test file included, hypothesis and cited evidence in the description.
measures → your review → merge → running
Δ trevo/setup
Setup PR
The SDK installation written for your stack, so measurement starts with a review instead of a sprint.
measures → merge → events flowing
Δ trevo/cleanup/*
Cleanup PR
Removes the losing variant and its flag once the experiment concludes; the winner stays as plain code.
measures → merge → zero flag debt
Frequently asked questions
What permissions does the Trevo GitHub App need?
Read access to the repositories you select, and the ability to open branches and pull requests. It writes only to trevo/* branches, cannot merge, and cannot touch your default branch. Scope it to a single repository with GitHub’s “only select repositories” option.
Does Trevo ever push to main or deploy?
Never. Delivery is a pull request; your review merges it and your pipeline deploys it. Trevo has no path to production that does not pass through a human on your team.
What happens to our code after Trevo reads it?
Reads happen in a temporary clone that is discarded afterward, and your code is never used to train AI models. The durable artifacts are the ones you can see: proposals in the dashboard and pull requests in your repo.
Will experiment PRs pass our CI and review standards?
They are ordinary branches, so your CI runs exactly as it does for a teammate. Variants ship with the test file included, and anything your review rejects goes back — rejection costs nothing but the review itself.
What about monorepos and multiple repositories?
Trevo scopes experiments to the app you choose inside a monorepo, and additional repositories — a backend API, a mobile app — can be attached read-only as context so full-stack proposals understand the whole system. Experiment PRs open only in your main repo.
Keep reading: PostHog + Trevo · Trevo for growth teams · Trevo for startups · A/B testing AI products · Trevo vs LaunchDarkly
Bring Trevo one real funnel problem.
Connect the repo and the first proposals arrive in under fifteen minutes, each one naming the exact files a full-stack experiment would change. Not ready? A free scan previews the ideas on your domain first.