Creating Repositories, Templates, Settings, Visibility, Topics, and Default Branches: Concepts, Architecture, and Mental Model

1. The practical problem: “New repository” creates more than an empty remote

The Git course taught that a Git repository is a database of objects and references. GitHub adds a hosted resource around that Git state. The moment you create OWNER/REPOSITORY, you also choose an owner namespace, a visibility boundary, an initial default-branch situation, and a place where Issues, pull requests, Actions, security controls, releases, packages, webhooks, Pages, and policy can later attach.

Those choices are operational. A service repository accidentally created under a developer’s personal account may later require transfer. A public repository cannot safely contain private configuration merely because nobody has linked to it yet. Initializing a remote with a README when you already have an unrelated local history can create an avoidable history collision. Repository creation is therefore architecture and governance, not only form completion.

2. Mental model: Git state inside a larger GitHub resource

flowchart TD
  A[Owner: user or organization] --> R[GitHub repository resource OWNER/NAME]
  R --> G[(Git objects + refs)]
  R --> M[Hosted metadata: description / topics / social preview]
  R --> P[Hosted policy: visibility / default branch / merge settings]
  R --> C[Collaboration: Issues / PRs / access]
  R --> X[Automation/security: Actions / webhooks / alerts]
  G --> D[Local clones exchange objects + ref updates]
  P -. constrains hosted operations .-> C
  P -. constrains hosted operations .-> X

The owner arrow means the repository belongs to one account namespace. The Git database is the part cloned and fetched by Git. Metadata and policy live on GitHub and are not reproduced merely by git clone. Collaboration and automation also belong to the hosted resource. This distinction explains why a perfect Git backup does not automatically recreate Issues, Actions settings, packages, webhooks, or organization policy.

The dashed arrows show that hosted policy can constrain GitHub-mediated work without becoming a Git object. For example, the default branch influences the branch GitHub presents and uses as the default pull-request base, but the label “default branch” itself is GitHub repository metadata.

3. Repository identity: owner/name is not a commit hash

Repository identity on GitHub is primarily the owner namespace plus repository name, such as learner-example/atlas-service. A commit OID such as 8f3… identifies a Git object. Renaming or transferring a repository can change the hosted coordinate while leaving the underlying commit OIDs unchanged.

4. Ownership is an administrative boundary

A personal repository is owned by one user account. An organization repository is owned by the organization and is administered through organization roles, teams, repository roles, and organization/enterprise policy. An organization is not a shared login; humans still authenticate as their own user accounts, as Chapter 01 established.

Ownership affects who can administer settings, how access is delegated, which policies apply, where billing/enterprise controls attach, and what happens if a maintainer leaves. For a production team, the durable default is generally organization ownership when the repository is a shared organizational asset—not because organization repositories use different Git objects, but because governance lives at the owner boundary.

5. Visibility is an access boundary, not a discoverability toggle

Visibility changes are security-sensitive lifecycle changes. They can alter fork networks and feature availability, so this chapter does not use visibility changes as a casual toggle. Choose correctly at creation for the disposable lab; later lessons will treat changes as controlled migrations with explicit consequences.

6. Initialization choices create Git history

When GitHub creates an otherwise empty repository, it may have no branch because no commit exists yet. If you ask GitHub to add a README, license, or .gitignore, GitHub creates content and an initial commit, which in turn creates the first branch/default branch. This is why the initialization checkbox is not cosmetic.

If you already have a local repository with its own first commit, avoid remote initialization unless you intentionally want to reconcile two histories. GitHub’s creation guidance explicitly warns that pre-populating a repository while importing existing history can introduce merge conflicts.

7. Templates, forks, and “starter repositories” are different ideas

A template repository is a repository whose admin has enabled template status. A learner with read access can generate a new repository from it. GitHub copies the template’s file/directory structure (and optionally all branches), but the generated repository starts a new, unrelated history rather than becoming a fork in the template’s repository network.

A fork belongs to a repository network and is designed around contributing or developing relative to an upstream repository. Its visibility is tied to the network. GitHub can represent parent/upstream relationships for forks.

A starter repository is often informal team language for “a repository containing starter code.” In standard GitHub repository semantics it is not a third provenance relationship. If the team wants repeatable project generation, mark it as a template; if the team wants upstream contribution lineage, use a fork. Calling an ordinary clone/copy a “starter repo” does not create platform provenance automatically.

8. Repository metadata: content, discovery, and governance signals

Metadata belongs in the design because automation and humans consume it later. A README can document build commands, a security policy can route vulnerability reports, topics improve catalog search, and a license changes what reuse is legally permitted. Yet only some of these are Git-versioned. Know which layer you are changing.

9. The default branch is a hosted choice pointing at a real Git branch

GitHub’s default branch is the branch shown first, used as the default base for pull requests and many repository operations. When GitHub creates a repository with content, its first branch becomes the default. GitHub currently names new repository default branches main by default unless a personal, organization, or enterprise default-branch-name policy says otherwise.

Changing the repository default branch requires an existing alternate branch and admin access; organization/enterprise rules can add further constraints. The hosted setting changes which branch GitHub considers default. It does not rename every developer’s local branch, rewrite commit history, or automatically change every integration that hard-codes a branch name.

10. Repository settings are hosted policy layered around refs and objects

Repository settings include feature toggles, pull-request merge methods, default branch, visibility, template status, webhooks, security/Actions settings, and lifecycle operations. Some settings affect how GitHub accepts or presents operations against Git refs, but the settings themselves are not ordinary files in the Git object database.

11. Rename, transfer, archive, delete: four different lifecycle operations

The key distinction is intent. Archive preserves a referenceable read-only resource. Transfer preserves the repository while moving administrative ownership. Rename changes its coordinate. Delete removes the hosted resource. A production runbook must not use these words interchangeably.

12. Inspect first: prove current hosted state without mutation

Use machine-readable CLI/API output so you can compare before and after. Replace OWNER/REPO with a repository you are authorized to inspect.

gh auth status --active --hostname github.com
gh repo view OWNER/REPO \
  --json nameWithOwner,visibility,isPrivate,isFork,isTemplate,templateRepository,defaultBranchRef,description,repositoryTopics,viewerPermission \
  --jq '{nameWithOwner,visibility,isFork,isTemplate,templateRepository,defaultBranch: .defaultBranchRef.name,description,topics: [.repositoryTopics[].name],viewerPermission}'

gh api -H "X-GitHub-Api-Version: 2026-03-10" \
  /repos/OWNER/REPO \
  --jq '{full_name,visibility,private,default_branch,archived,is_template,permissions}'

gh repo view --json reads GraphQL-backed structured repository fields. gh api reads the documented REST repository resource. Neither command changes repository state. The REST example explicitly selects the current supported API version used throughout this course generation run.

13. Why this matters in DevOps

Repository defaults become inputs to delivery systems. CI workflows trigger from repository events, branch policies target names or patterns, releases point at refs, packages and Pages can bind to repository identity, and integrations store repository coordinates. A rushed creation decision can therefore become a production dependency before anyone notices.

A mature platform team treats repository creation as provisioning: owner, visibility, initialization source, default branch, metadata, merge behavior, access model, and lifecycle owner are declared and then verified. Later chapters will automate more of this, but the operating model starts here.

14. Mini lab: classify an existing repository without changing it

1. Choose one public repository you own or a public repository you are allowed to inspect.
2. Use gh repo view ... --json to record owner/name, visibility, default branch, template/fork status, description, topics, and your viewer permission.
3. Run git ls-remote https://github.com/OWNER/REPO.git HEAD refs/heads/* and compare Git refs with the hosted default-branch field.
4. Write two columns: “Git state I could clone/fetch” and “GitHub-hosted state I would need to recreate separately.”
5. Identify one repository-creation choice that would be expensive to correct after production integrations exist.

15. Verification checklist

• You can explain why repository owner/name and commit OID are different kinds of identity.
• You can distinguish personal versus organization ownership without treating an organization as a login account.
• You can state why internal visibility is not part of the mandatory free path.
• You can explain why a remote README creates history and may collide with existing local history.
• You can distinguish a template-derived repository from a fork and from an ordinary “starter” repository.
• You know which common metadata is Git-versioned and which remains hosted metadata.
• You can explain why changing the default branch does not rename local branches.
• You can distinguish rename, transfer, archive, and delete by operational consequence.

Knowledge check

16. Summary

A GitHub repository is a hosted resource around Git state. Ownership, visibility, initialization, default branch, metadata, templates, collaboration settings, and lifecycle controls determine who governs that resource and how later automation will interpret it.

The safe sequence is now explicit: choose the intended owner/visibility/init model, inspect permissions and defaults, create only disposable state while learning, verify through structured hosted and Git evidence, and treat rename/transfer/visibility/delete as lifecycle operations rather than convenience toggles.

Authoritative references

• About repositories
• About repositories — GitHub Enterprise Cloud
• Creating a new repository
• Creating a template repository
• Creating a repository from a template
• Forks
• Changing the default branch
• Setting repository visibility
• Customizing your repository
• Renaming a repository
• Transferring a repository
• Archiving repositories
• Deleting a repository
• Restoring a deleted repository
• gh repo view
• REST API endpoints for repositories
• REST API versions