Use cases

Someone needs to see PR #42 in a browser

Product and QA should not need your README, a staging deploy, or a screen share of your laptop. They need a URL that shows the branch under review, and you need a straight path to create and destroy that environment so it does not linger.

The flow

1. gtl review 42 --start (from the main repo) fetches the PR with gh, creates a worktree, allocates ports and database, runs setup, and boots the app.
2. gtl open opens the right URL in the browser: HTTPS on {project}-{branch}.prt.dev when gtl serve is installed; otherwise http://localhost:{port}.
3. If they are off your machine, gtl share exposes a time-bounded public or tailnet URL—different tradeoffs than gtl tunnel, which is built for stable routes you register with providers.
4. When review ends, gtl release frees the allocation; add --drop-db when the cloned database should go too.

Hooks in .treeline.yml (pre_setup, post_setup, etc.) let you run team-specific steps—notifications, fixtures—without forking Treeline.

Read next

• Workflows
• Networking (share vs tunnel)

All use cases