Creating Repositories, Templates, Settings, Visibility, Topics, and Default Branches: Configuration, Design Choices, and Tradeoffs

1. Configuration choices are contracts with future automation

Creation settings become assumptions. A CI workflow may target main, deployment rules may reference the default branch, documentation may embed OWNER/REPO, and a template may seed hundreds of projects. The correct choice is therefore the one whose semantics your team can maintain—not the one that makes today’s creation form shortest.

A useful design review asks six questions: Who owns the asset? Who may see it? Where does initial history come from? What lineage must remain visible? Which branch is operationally default? Which merge histories will the repository accept? Then verify whether your account type, plan, and policies permit those choices.

2. Initialize on GitHub or push existing local history?

The principle is single intentional genesis. If the remote and local sides both create their own first commit, Git correctly sees two unrelated histories. That is not corruption; it is evidence that two independent histories were created.

3. Template versus starter repository versus fork

At scale, explicit semantics beat naming conventions. If “starter” really means reusable scaffolding, convert the source to a template and document how updates are propagated—often through separate automation, not an assumed upstream merge relationship.

4. Personal versus organization ownership

For a company service, organization ownership generally gives the right continuity boundary. The Git data is not “more enterprise” because of the owner; the governance surrounding that data is.

5. Visibility: optimize for the intended trust boundary

Public/private/internal is not a maturity ladder. It is a visibility decision. Public is appropriate for intentionally public source. Private is appropriate when access must be explicit. Internal supports enterprise-wide innersource in eligible Enterprise Cloud organizations. Choose the narrowest boundary that still serves the collaboration model, then apply security controls inside that boundary.

6. Default branch naming: convention, policy, and compatibility

GitHub currently defaults new content-bearing repositories to main, but personal, organization, and enterprise settings can define a different default name for new repositories. Existing repositories can also select another existing branch as default, subject to permissions and rules.

The branch name itself matters because tooling may hard-code it. Before standardizing a different name, search CI configuration, deployment manifests, scripts, documentation, branch rules, Pages sources, and external integrations. A consistent default reduces ambiguity, but changing a mature estate has migration cost.

7. Merge feature settings are GitHub policy with Git history consequences

GitHub can allow merge commits, squash merging, and rebase merging for pull requests. These are repository settings controlling which merge operations GitHub offers. The resulting commits are still ordinary Git history, but the policy deciding which shapes are permitted is hosted state.

Do not enable or disable a method only because it is fashionable. Consider rollback strategy, release-note generation, bisectability, authorship/audit expectations, and rules such as “require linear history.” Chapter 09 goes deeper into merge methods and merge queue behavior.

8. Read the effective design from GitHub CLI

gh repo view OWNER/REPO \
  --json nameWithOwner,visibility,defaultBranchRef,mergeCommitAllowed,squashMergeAllowed,rebaseMergeAllowed,isTemplate,isFork,viewerPermission \
  --jq '{nameWithOwner,visibility,defaultBranch:.defaultBranchRef.name,mergeCommitAllowed,squashMergeAllowed,rebaseMergeAllowed,isTemplate,isFork,viewerPermission}'

This is the preferred starting point for a design review because it turns UI settings into structured evidence. If the settings differ from your intended policy, first ask whether you have admin permission and whether organization/enterprise policy constrains the repository. “I cannot see the toggle” is not enough diagnosis.

9. Worked design decision: Atlas service repository

Assume a five-person DevOps team is creating a new internal service, but the course learner only has GitHub Free. The production recommendation and the free lab can differ while teaching the same reasoning.

The lesson is not that one row is universally correct. The lesson is that every choice has an explicit reason and a free-compatible way to practice the underlying model.

10. Product boundaries: Git, GitHub, Actions, and external systems

11. Common design anti-patterns

• Create first, decide owner later: creates avoidable transfer work and policy drift.
• Initialize both remote and local: creates two intentional but unrelated histories that then need reconciliation.
• Use a fork as a template: keeps an upstream/network relationship that an independent service may not want.
• Call any copied repo a template: hides the absence of explicit platform provenance.
• Change default branch before dependency inventory: breaks hard-coded automation even though GitHub setting itself succeeds.
• Enable every merge method: pushes governance decisions onto individual PR authors and makes history less predictable.

12. Design exercise before mutation

Write a one-page repository provisioning decision for a fictional service. Include: intended owner, visibility, initialization source, template/fork rationale, default branch, merge methods, README/license/.gitignore policy, topics, lifecycle owner, and the exact free-course simulation. Then use gh repo view against one disposable repository to compare declared versus effective settings.

13. Verification checklist

• Your initialization choice creates only one intentional first history.
• Your template/fork/starter decision matches required provenance and future synchronization.
• Ownership matches the administrative continuity model.
• Visibility matches the actual trust boundary and plan/deployment availability.
• Default branch name is verified rather than assumed and dependencies are identified before changing it.
• Merge methods are justified by history/reliability/audit needs rather than convenience.
• The mandatory learning path works without Team/Enterprise/paid security products.

Knowledge check

14. Summary

Repository design is a set of explicit contracts: ownership defines administrative continuity; visibility defines who may read; initialization defines history genesis; template/fork semantics define lineage; the default branch guides hosted operations; merge settings constrain allowed PR history shapes.

The production pattern is declare → verify availability/policy → provision → inspect effective state. The next lesson applies the same discipline when creation goes wrong or repository identity changes.

Authoritative references

• Creating a new repository
• Creating a template repository
• Creating a repository from a template
• Forks
• About repositories — GitHub Enterprise Cloud
• Setting repository visibility
• Changing the default branch
• Managing the default branch name for your repositories
• Configuring pull request merges
• Pull request merges
• Repository roles for an organization
• gh repo edit