{% extends "docs/base.html" %} {% block docs_content %}
Guide: understand the pieces
Repositories bind Git data and collaboration records to a personal or team owner.
Code needs a durable owner, visibility policy, and merge boundary.
Use a thread for temporary discussion that does not need a new code or ownership boundary.
| Question | Personal repository | Team 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 use | Experiments, 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.
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
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"
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.