Repositories on GitHub

A GitHub repository is a hosted Git repo plus its settings — visibility, default branch, access, and automation. The Git part is the history you already understand; the settings part is where most of the decisions that bite you later actually get made.

The pattern to internalize is that the settings tab governs behavior the code never reveals. A repo can look identical in two organizations and behave completely differently because one allows force-pushes to main and the other does not, so reading the settings is part of reading the repo.

Visibility

A repository is public, private, or — for organizations owned by a GitHub Enterprise Cloud account — internal, which means readable by every member of the enterprise (across all its organizations) but no one outside it. Public exposes the full history to the world; private restricts it to people you grant access; internal is the enterprise-wide middle ground.

Flipping a private repo to public is effectively irreversible in its consequences. The entire commit history becomes world-readable the instant you switch, including any secret ever committed, and crawlers and forks can capture it before you switch back. Treat the toggle as a one-way door.

The Default Branch

main is more than the branch you see first. It is the base for new pull requests, the branch a fresh git clone checks out, and the target that branch protection rules attach to. Change it and several of those bindings move with it — but only if you update everything that named the old branch.

Renaming the default branch through the settings tab updates open PR bases and redirects, but it does not update your CI config files, external integrations, or branch protection rules that pin a branch name. Those have to be edited by hand, or protection silently stops applying to the new default.

Repository Settings That Matter

The settings that shape day-to-day work are the merge button options (which of merge commit, squash, and rebase are allowed), automatic deletion of head branches after merge, whether force-push to protected branches is permitted, and the archive switch that freezes a repo read-only.

Leaving all three merge methods enabled with no team agreement is how a history becomes an unreadable mix of merge commits, squashes, and rebases. Restricting the button to one method keeps the log uniform enough to reason about.

Templates and Generation

A template repository lets anyone generate a new repo pre-seeded with its files, and the .github/ directory holds special files — issue templates, CODEOWNERS, workflows — that GitHub reads automatically. Cloning with --template copies the tree but strips the history, giving a clean starting point.

Generating from a template is not forking. There is no upstream link, no shared history, and no way to pull later template changes — the new repo is fully independent from the moment it is created.

Forking and Mirroring Settings

Repository settings also control who may fork. For private and internal repos this matters because a fork is a server-side copy outside the original's access controls, and internal visibility specifically governs whether org members can fork into their own namespace. Decide the fork policy before granting broad access, not after a copy already exists.