4.2 Creating Repositories with Templates and Branches

Why creation and templates are a Domain 2 skill

After the key files, GH-900 asks you to identify how to create, organize, and maintain repositories using templates and branches. Domain 1 already taught what a repository and a branch are. This bullet is the product workflow: where you click, what gets copied, which history you inherit, and which branch GitHub treats as the production baseline.

Creating a repository at github.com/new

The canonical create URL is https://github.com/new. The + menu in the header also has New repository. You can use gh repo create from GitHub CLI. On the form:

1. Owner — your user account or an organization where you have permission to create repositories. Organization owners can restrict who may create repos.
2. Name — at most 100 characters, ASCII letters, digits, and ., -, _ only.
3. Visibility — public (anyone on the internet) or private (you plus people you grant). Organizations on GitHub Enterprise Cloud that sit in an enterprise account also get internal visibility: visible to enterprise members without being public on the internet. Internal is an Enterprise capability, not a Free/Pro/Team trick.
4. Initialize — optional README, language .gitignore, and LICENSE. Skip these if you are about to import an existing Git history; initializing a README on a non-empty import is a classic merge-conflict setup.
5. Optionally pick a template from Choose a template, include all branches, attach Marketplace apps, or (where enabled) prompt Copilot cloud agent to open a draft pull request after create.

You can pre-fill the form with query parameters (name, description, visibility, owner, template_owner, template_name). Invalid parameters are ignored; a URL that is too long returns 414.

Empty repositories are valid. The first push still has to name a default branch—today GitHub’s default name for new repositories is main, and user, organization, and enterprise settings can change the name used for new repos going forward.

Template repositories vs forks

Two GitHub features copy someone else’s tree. They are not interchangeable, and GH-900 will mix them with clone and branch.

A template repository is an ordinary repo whose owner turned on Settings → Template repository. Anyone with access sees Use this template. Creating from a template copies the directory structure and files. By default you get the default branch only; Include all branches copies the others. The new repository starts with a single commit. There is no upstream relationship. Commits you make do count on your contributions graph. Use a template when you are starting a new project from a boilerplate (service skeleton, homework starter, InnerSource cookie-cutter).

A fork is a new repository that shares code and visibility with the original upstream repository and keeps the parent history. Forks exist so you can propose changes back. Commits on a fork do not appear on your contributions graph the way template-based work does. Domain 7 covers discovery and contributing-via-fork in more depth; Domain 2 only needs the discriminator: template = new project, new history; fork = contribute to an existing project, keep the link.

A clone is a local copy of a remote, not a second GitHub repository. A branch is a parallel line of commits inside one repository. Creating a branch is how you organize work after the repo exists; it is not a substitute for template or fork.

Two template limits are exam favorites. Template repositories cannot include files stored in Git LFS. If the boilerplate needs large binaries, do not mark that repo as a template—or strip LFS first. Branches created from a template have unrelated histories. You cannot open a pull request or merge between those copied branches just because they shared names in the template. Each generated repository is a new island.

On github.com/new you can choose a template you own, one from an organization you belong to, or one you used before. From the template repo itself, Use this template → Create a new repository (or open the template in a codespace and publish later). GitHub Classroom can also assign from a template repository; GH-900 only needs you to recognize that classroom starters are the same template mechanism.

The public .github repository is not a template repository

Candidates mash together two features that both use the word “template.”

• Template repository: Settings checkbox on any project. Use this template generates a new repository with copied files. This is how you duplicate a codebase shape.
• .github repository: a public repo whose name is .github, owned by a user or organization. It holds default community health files and issue/pull request templates for other repos the account owns. It does not clone an application. LICENSE still cannot live only there.

If an exam story says “every new service should start with the same src/ layout, CI workflow, and README,” that is a template repository. If it says “every repo in the org should show the same CONTRIBUTING.md and issue forms unless it overrides them,” that is the public .github repo. An organization can use both: a service template for the code skeleton, and .github for the human process files.

Default issue templates from .github apply only when the consuming repository has no files in its own .github/ISSUE_TEMPLATE folder. One local template file turns the org defaults off for issues in that repo.

Default branch and organizing with branches

The default branch is the base for pull requests and new commits in the GitHub UI. GitHub has used main as the default name for new repositories since 2020; the name is configurable. A repository admin changes it under Settings → Default branch (the repo must already have more than one branch). Users and organizations can set the default name for newly created repositories; enterprises can enforce that policy. Organizational or enterprise rulesets that target branches can require an org or enterprise admin to change the default.

GitHub Flow (Domain 1) is how you maintain the repository after creation: create a branch from default, commit, open a pull request, review, merge to default, delete the branch. The default branch should stay shippable. Creating a repository is not permission to commit experimental work straight to main on a shared project.

You can create branches from the web (branch switcher), GitHub CLI, GitHub Desktop, git switch -c / git checkout -b after a clone, or github.dev (press ., then use the status-bar branch picker). Feature branches belong inside the repository you own or can write to. If you do not have write access, you fork first, then branch on the fork—not “template, then open a PR back,” because a template has no upstream.

Exam scenarios and traps

• Template vs fork vs clone vs branch. Four different nouns. Template starts a new history. Fork keeps upstream. Clone is local. Branch is in-repo.
• “Include all branches” copies extra branches from a template, but those branches are unrelated in the new repo. You cannot merge them to each other as if they still shared the template’s graph.
• Git LFS files cannot live in a template repository. A 4.3-sized binary in a cookie-cutter repo is a wrong answer for “mark this as a template.”
• Initializing README on import is how you manufacture a pointless first-commit conflict.
• Internal visibility is Enterprise, not “private but for the company” on Free.
• .github repo vs Template repository checkbox. Process defaults versus project scaffold.
• Default branch is not magically named main forever. New GitHub repos default to main; existing repos and renamed defaults can be master, develop, or anything an admin set. Pull requests target whatever the default is, not the string main.

Walk a GH-900 story to one verb: create, template, fork, or branch. If the story also mentions org-wide CONTRIBUTING, add the public .github repository as a second, separate control.