EVERYDAY DEVELOPMENT, WITH FEWER DETOURS
Your work has branches.
Your workspace should, too.
A review arrives halfway through a feature. A hotfix interrupts a migration. An agent needs a clean place to work. Keep those tasks separate without losing track of them.
PR REVIEWS
Run the review.
Leave your feature alone.
Reading the diff is one thing. Running the change is another. Give the review branch its own worktree so you can try it without taking over your current checkout.
A practical review loop
- Fetch the review branch into your local repository.
- Create a worktree from that branch in Canopod.
- Run its configured setup and start its services.
- Open its local port and try the behavior you’re reviewing.
Your feature can stay checked out and running in its own worktree.
Create your first worktreeHOTFIXES
The urgent fix
gets its own space.
You shouldn’t need to tidy up half-written code just to investigate a bug. Start a separate worktree from the right base and return to your feature when the fix is done.
Keep the interruption contained
- Choose the base branch or tag for the fix.
- Create a named hotfix worktree and run its setup.
- Start its services with the assigned ports.
- Make and verify the fix, then return to your original worktree.
Canopod manages the environment. Keep using your usual Git and review workflow to ship the change.
Managing branches and worktreesCODING AGENTS
Give each task
the right context.
An agent needs more than a branch name. Give it a task, the correct worktree, and the runtime details that go with it. Keep separate tasks from sharing the same checkout.
Work alongside your agent
- Create a worktree for the task you want to delegate.
- Add the brief and useful references to its context.
- Launch your configured coding-agent CLI in that worktree.
- Use Canopod MCP when the agent needs to inspect or manage the workspace.
You can read service logs beside the agent session and keep another branch open for your own work.
Connect your agent with MCPDATABASE CHANGES
Test the schema
without sharing the fallout.
Two branches may expect different database schemas. Configure an independent Postgres database per worktree and keep a snapshot before trying a migration.
Make the experiment repeatable
- Configure a worktree-specific database and connection settings.
- Take a snapshot of the data you want to preserve.
- Run the branch’s configured migration and test the change.
- Restore the snapshot when you need a clean retry.
These tools require local Postgres and client binaries that match the server’s major version.
Snapshot and restore a databaseStart with the branch you’re on.
Add your repository today. Make room for the next task when it arrives.