Workflows
gtl review creates an isolated worktree, allocates resources, runs setup, and boots the server—all from a PR number. Requires the gh CLI for PR fetching; everything else is built in.
Product owner asks to see PR #42. Here's what happens.
$ gh pr checkout 42
$ git worktree add ../pr-42 add-oauth-login
$ cd ../pr-42
$ cp ../.env.local .env.local
$ vim .env.local # change PORT, DATABASE_URL…
$ createdb myapp_dev_pr42
$ rails db:schema:load
$ bundle install
$ bin/dev
# 8 commands. 10 minutes. Hope you didn't miss a step.
Next PR? Do it all again. And don't forget to tear everything down when you're done.
One command replaces all of that
named URL via gtl serve
Done reviewing? gtl release --drop-db --remove-worktree frees the allocated port, drops the cloned database, cleans up the env file, and removes the worktree directory in one step.
Workflows tie isolation and networking together: one command should stand up a branch with resources, a URL, and a running process—and another command should tear it down cleanly. That is the bar this page documents end to end; Isolation and Networking explain the underlying pieces.
gtl review <PR> --start gives stakeholders a running checkout without asking them to clone, install dependencies, or edit env files. Pair with gtl serve for a named HTTPS URL per branch so redirects and demos match what engineers see—no throwaway staging deploy required for a first look.
Multiple PRs means multiple allocations: distinct ports, databases, and URLs. Test flows in parallel instead of serially reconfiguring one machine. When a branch is merged or obsolete, gtl release --drop-db (or gtl prune --merged) reclaims disk and registry entries explicitly.
Humans use gtl start in a terminal; scripts and agents use gtl restart / gtl stop over the Unix socket—no PID files or signals to guess. Optional hooks in .treeline.yml still bracket setup and teardown the same way for everyone.
Your terminal
$ gtl start
Starting server on port 3010…
[HMR] Listening on ws://localhost:3010
GET / 200 in 23ms
GET /api/auth 200 in 8ms
Restarting…
Starting server on port 3010…
GET / 200 in 12ms
Meanwhile — agent or CI
$ gtl restart
Server restarted.
$ gtl stop
Server stopped.
gtl start boots your commands.start and streams logs to your terminal. You see the output in real time. The supervisor injects allocated env vars directly into the child process.
gtl restart and gtl stop send commands over a Unix socket. No PID files, no signal guessing. Agents or scripts control the server without needing the foreground terminal.
Automation hooks live in .treeline.yml. Everything else is CLI for speed.
pre_setup, post_setup, pre_release, and post_release run around allocation and teardown. Pre-hooks abort the operation on failure; post-hooks log and continue. Setup: allocate → env → database → pre_setup → commands.setup → editor → post_setup. Release: confirm → pre_release → free/drop → post_release.
gtl clone <repo-url> runs git clone, detects the framework, creates .treeline.yml if missing, and runs gtl setup. It does not start the dev server—cloning an untrusted repo and executing arbitrary start commands is a trust boundary.
gtl open opens the app in a browser—HTTPS on {project}-{branch}.prt.dev when gtl serve is running, otherwise http://localhost:{port}. gtl start --await blocks until something listens on the allocated port (use --await-timeout for scripts and CI).
Run gtl dashboard (or gtl dash / gtl ui) for a full-screen terminal dashboard: all projects and worktrees in one place, refreshed every couple of seconds. Move with j/k; s start/stop, o open browser, d release (confirm), / filter.
Requires gh CLI for PR fetching. Everything else is built in.
gtl review 42 --start