When to use forking
- Templates: Create new projects from a starter template
- Experimentation: Test changes without affecting the original repository
- Snapshots: Capture a repository’s state at a specific commit or branch
- Isolation: Give each user or agent their own copy to work with
Quick start
Fork options
| Parameter | Type | Description |
|---|---|---|
id | Required | The repository ID (name) to fork from |
ref | Optional | Branch or tag name to fork from. Forks the tip of this ref. |
sha | Optional | Exact commit SHA to fork at. Overrides ref if both are provided. |
- If
shais provided, fork at that exact commit - If
refis provided, fork at the tip of that branch/tag - Otherwise, fork at the source repository’s HEAD
Default branch behavior
The forked repository inherits the default branch from the source:Use cases
Project templates
Create new projects from a starter template:Per-agent workspaces
Give each AI agent its own isolated copy:Point-in-time snapshots
Capture a repository’s state before making risky changes:Forking vs GitHub sync
| Feature | Forking | GitHub Sync |
|---|---|---|
| Source | Code Storage repositories | GitHub repositories |
| Connection | One-time copy | Continuous sync |
| Updates | Independent after fork | Automatically synced |
| Use case | Templates, snapshots, isolation | Mirror GitHub repos |
Limitations
- Same organization: You can only fork repositories within your own organization
- No relationship tracking: Forks are independent—there’s no “parent” reference after creation
- Full copy: Forks include all branches and history up to the fork point