Work with GitHub Repositories Study Guide — GH-900

Working with GitHub Repositories

This domain accounts for 20% of the GitHub Foundations exam and tests your ability to create, configure, and manage repositories across their full lifecycle. Questions cover repository settings and visibility options, the mechanics of branching and committing, how tags and releases relate, the role of GitHub Codespaces, and tooling for repository insights. Expect scenario-based questions that ask you to choose the right action given a specific constraint (e.g., enterprise tier, open-source workflow, protected branch).

Creating Repositories

Core Concepts

A repository (repo) is the fundamental unit of storage on GitHub, containing files, history, branches, and metadata. When creating a repository you make several foundational decisions that are easier to set correctly from the start than to change later.

Initializing with a README creates the first commit automatically. Without it, the repo is empty and you must push an initial commit before branching or cloning produces anything useful.

.gitignore templates are pre-built patterns curated by GitHub for dozens of languages and frameworks (Node, Python, Java, etc.). They prevent accidental commits of build artifacts, secrets, and OS-specific files.

Common Traps

• Choosing "Initialize with README" when you already have local code to push — this creates a divergent history requiring a force push or merge of unrelated histories.
• Confusing .gitignore with .gitkeep — .gitkeep is a convention for tracking empty directories, not a GitHub-provided template.
• Assuming all repository creation options can be set after creation — visibility can be changed later, but some choices (like template status) affect discoverability immediately.

Repository Visibility: Public, Private, and Internal

Visibility Tiers

Internal repositories are exclusive to GitHub Enterprise. They behave like private repos to outsiders but are visible to all members of the enterprise organization — useful for inner-source workflows where code should be shared across teams without being publicly exposed.

Forking behavior by visibility:

• Public repos can be forked by anyone.
• Private repos can only be forked within the same organization (if org policy allows).
• Internal repos can be forked by enterprise members into other organizations within the same enterprise.

Common Traps

• Treating "internal" as a synonym for "private" — internal is a distinct third option only on Enterprise plans.
• Assuming private repositories are free for all users — they are, but some advanced features (e.g., protected branches on private repos) may require paid plans on older account types.
• Forgetting that changing visibility from public to private does not delete forks already created.