Trylle Documentation

A repository owns Git history, collaboration settings, access grants, branch rules, webhooks, issues, and pull requests. It can belong to a personal account or an organization.

Create and clone

Create an initialized private repository with an explicit owner and default branch:

try repo create project-name \
  --owner OWNER \
  --private \
  --auto-init \
  --default-branch main \
  --description "Project description"

Then clone the server-created history:

try repo clone OWNER/project-name project-name
cd project-name
try repo context

Use --public instead of --private for a public repository. Leave out --auto-init when publishing an existing local project so you do not create a second root commit. See your first repository for both flows.

You can also fork an existing repository. A fork has its own branches, settings, issues, and pull requests while retaining its relationship to the source.

Repository access

Repository access can come from more than one place:

Grant	Available access
Direct collaborator	Read, write, or admin
Organization team	Permission granted when the team is attached to an organization repository
Organization ownership	Administrative authority inherited from the owning organization

Direct collaborator grants and team grants are separate. Removing one does not necessarily remove access supplied by the other. Review both before assuming a user no longer has repository access.

Repository administrators can manage direct collaborators. For organization repositories, authorized organization administrators can also attach teams. Transfers have a narrower authority boundary: the personal namespace owner or an organization owner must perform the transfer; repository admin access alone is not sufficient.

General and merge settings

Repository settings cover:

name, description, visibility, and default branch;
whether issues are enabled;
allowed merge commit, squash, and rebase strategies;
automatic head-branch deletion after merge;
whether maintainers may edit pull request branches;
whether rebase-based pull request branch updates are allowed.

Projects are not currently available as a repository feature.

For an organization-owned repository, the organization's default branch and merge or issue defaults apply when the repository is created through the dashboard. The organization's Initialize repositories default is an exception: dashboard creation currently creates the repository without an initial commit. Choose initialization explicitly when you need it.

Protect branches

Create branch protection rules under the repository's branch settings. A rule can target a branch name or glob pattern and combine these controls:

Control	Effect
Direct pushes	Allow or restrict pushes, optionally with a user or deploy-key allowlist
Required approvals	Require from 0 through 20 approving reviews
Review state	Block on rejected reviews or outstanding review requests
Stale approvals	Dismiss or restrict approvals after the branch changes
Status checks	Require named checks to pass
Up-to-date branch	Require the head branch to include the current base branch
Signed commits	Require valid commit signatures
File patterns	Apply protection behavior to configured path patterns
Include administrators	Apply the rule to repository administrators as well

Rules can overlap, so inspect every rule that matches the branch before diagnosing a blocked push or merge. Review requirements count submitted review decisions, not ordinary pull request comments. See code review for the distinction and GPG keys for commit signing.

Archive, transfer, or delete

Repository lifecycle actions are available from settings:

Archive makes the repository read-only until it is unarchived.
Transfer moves it to another eligible personal or organization namespace.
Delete permanently removes it after exact owner/repository confirmation.

Renaming and visibility changes are also supported. Re-check clone URLs, integrations, and access after a rename, visibility change, or transfer.

Deletion requires the exact repository path

Treat deletion as irreversible. Confirm the current owner, repository name, and backups before entering owner/repository in the confirmation field.

Configure webhooks

Repository webhooks can send selected events as JSON or form-encoded payloads. Each hook supports an active state, an optional branch filter, a signing secret, and an optional custom Authorization header.

Set the signing secret when creating the webhook. The saved value is hidden and preserved during later edits, but the current edit flow cannot rotate or clear it. Create a replacement webhook when the signing secret must change.

The custom Authorization header can be replaced or removed during editing, and the dashboard offers an undo action for that pending change. Test the receiver after changing payload format, event subscriptions, filters, or authentication.

Continue the workflow

Open a pull request for a branch, or connect the repository to continuous integration. For a repository that already lives on GitHub, compare writable sync and public mirrors.

Repositories