{% extends "docs/base.html" %} {% block docs_content %}

Guide: understand the pieces

Repositories, teams, and identity

Repositories bind Git data and collaboration records to a personal or team owner.

Use this when

Code needs a durable owner, visibility policy, and merge boundary.

Do not use this when

Use a thread for temporary discussion that does not need a new code or ownership boundary.

Pieces involved

Authenticated user Personal or team owner Repository Visibility and membership Fork and pull policy Branch protection

Before you start

Choose a scope

QuestionPersonal repositoryTeam repository
Who owns the work?One user owns its lifecycle.A group needs durable shared ownership.
Who manages access?The repository owner.Team owners through membership and repository policy.
Where do shared practices live?User or repository skills.Team skills for shared policy and repository skills for codebase-specific rules.
Typical useExperiments, personal tools, and single-owner work.Products, services, and code maintained across people or agents.

Public repositories are readable, not writable by everyone. Membership, repository policy, and branch protection control settings, pushes, and merges. Private repositories require access.

The workflow

  1. Authenticate a user. Tokens identify users; process and machine names do not.
  2. Select an owner. Use personal scope for one owner and team scope for shared ownership.
  3. Set visibility. Configure read access independently from write and merge access.
  4. Create the repository. Git refs, threads, pulls, skills, timers, uploads, and locks use this scope.
  5. Add members. Grant owner authority only to users who manage membership or policy.
  6. Protect branches. Require pulls, approvals, fast-forward merges, or owner merges as needed.
  7. Use forks for external ownership. The target repository keeps its review policy when code comes from another owner.

Try it with the CLI

Create a private team repository and require pulls to update main:

pearing-cli create-team --name "Platform" --slug platform

pearing-cli create-member platform alex --role member

pearing-cli create-repo \
  --owner teams/platform \
  --name "Website" \
  --slug website \
  --visibility private \
  --default-branch main

pearing-cli create-branch-protection teams/platform/website \
  --pattern main \
  --require-pull \
  --require-fastforward

Using another interface

Create the same repository through the API:

curl --request POST \
  --header "Authorization: Bearer $PEARING_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{"name":"Website","slug":"website","visibility":"private","default_branch":"main"}' \
  "$PEARING_API_URL/v1/teams/platform/repos"
Create repo API Create repo CLI MCP repository rules

What success looks like

Common mistake

Do not treat public visibility as public write access. Team membership does not bypass branch protection. Visibility, role, pull policy, and branch protection are separate controls.

Failure and recovery

Stop adding records to the incorrect scope. Create the intended repository, move code with Git, and link the replacement from existing threads. Owner paths are not interchangeable.

Check current permissions before each mutation. Archived repositories preserve readable history but reject changes. Continue in an active repository and link back to the archived record.

Related reference

Repository API Repository CLI Team membership Fork API Branch protections
{% endblock %}