15.3 Forks, Templates, and Discoverable Repositories

Why GH-900 pairs forks, templates, and discovery

Domain 7 asks you to recognize when to use forks, templates, and discoverable repositories to promote collaboration. Domain 2 already taught you that templates and branches are how you create and organize repositories. This section is the collaboration decision: when should you fork, when should you Use this template, when is a clone or a branch enough, and how do topics, Explore, Trending, and visibility make a repository findable?

The exam will not grade you on memorizing git remote add upstream flags. It will grade you on picking the model that matches the goal. Contributing to someone else's project is a fork. Starting a new service from a blessed layout is a template. Working on your laptop is a clone. Isolating work you can already push is a branch.

Fork: a copy with an upstream link

A fork is a new repository that starts as a copy of another repository, called the upstream repository. A fork has its own settings and permissions but stays connected to upstream. On GitHub, the upstream name appears under the fork's title so you can see the relationship.

Forks exist so you can propose changes without affecting upstream until maintainers accept a pull request. That workflow is the fork-and-pull model used across public open source and, with policy, inside companies:

1. Click Fork on the upstream repository.
2. Choose an owner (your user account, or an organization where you can create repositories). Optionally rename the fork and choose Copy the DEFAULT branch only—enough for many open-source contributions.
3. Clone your fork (not the upstream) so origin points at a repository you can push to.
4. Add upstream as a Git remote if you will sync (git remote add upstream <upstream-url>).
5. Create a branch, commit, push to your fork, and open a pull request from the fork into upstream.

You can fork any public repository to your personal account or to an organization where you may create repositories. If you have access to a private repository and the owner permits forking, you can fork it to your personal account or to an organization on GitHub Team. You cannot fork a private repository to an organization using GitHub Free. Repository, organization, and enterprise forking policies can block forks entirely. Enterprise Managed Users face extra limits on what they can fork.

A fork is not a branch. A branch is a parallel line of history inside one repository. A fork is a separate repository with its own issues, pull requests, Actions, and collaborators. You cannot "fork a branch" as a GitHub noun; you fork a repository, then you branch inside the fork.

A fork is not a clone. A clone downloads a full copy of a repository onto your computer, including history. Cloning does not create a second repository on GitHub. If you clone a repository you cannot push to, GitHub Desktop may offer to create a fork when you try to publish a branch—that prompt exists because a clone alone cannot give you a push target on GitHub.

Visibility of forks is tied to the repository network. Public forks stay public; private forks stay private. You cannot flip a fork's visibility by itself. Internal repositories on GitHub Enterprise support a single level of forking; you cannot fork a private fork of an internal repository. If a person's access to a private repository is removed, GitHub deletes their private forks of that repository. Public-network behavior is different: deleting a public upstream can leave an active public fork as the new parent. Those network rules are why companies often disable forking of private IP.

Template: a new project that starts fresh

A template repository is a repository an admin has marked Template repository in Settings. Anyone with access can click Use this template and Create a new repository with the same directory structure, files, and—optionally—all branches. GitHub CLI can do the same with gh repo create.

Creating from a template looks like forking and is not forking. GitHub documents three differences you should be able to quote:

• A new fork includes the entire commit history of the parent. A repository created from a template starts with a single commit.
• Commits to a fork do not appear on your contributions graph. Commits to a repository created from a template do appear on your contributions graph.
• A fork is often a temporary way to contribute to an existing project. A template starts a new project quickly.

Branches copied from a template have unrelated histories, so you cannot open pull requests or merge between those copied branches as if they shared a parent. Templates also cannot include Git LFS files. After you create the new repository, it does not keep an upstream contribution link the way a fork does. That is the feature: the new service is not supposed to send pull requests back into the starter kit unless you add a remote yourself.

Use a template when a platform team wants every microservice, homework assignment, or GitHub Classroom starter to look the same. Use a fork when the goal is to send work back to the original maintainers.

Fork versus template versus clone versus branch

If you can already push to the repository, GitHub Flow says: create a branch, not a fork. Forks are for the case where upstream will not (or should not) give you write access. Templates are for duplication without contribution. Clones are local, not a collaboration model of their own.

Discoverable repositories

A repository only promotes collaboration if people can find it. GitHub's discovery tools work on repositories they are allowed to see.

Topics classify a repository by purpose, subject, community, or language. They appear on the repository's main page. Click a topic to see related repositories. Browse featured topics at github.com/topics/ and a specific topic at github.com/topics/<topic>—for example github.com/topics/machine-learning. Topic rules: lowercase letters, numbers, and hyphens; 50 characters or fewer; no more than 20 topics. GitHub can suggest topics by analyzing public repository content; private repository content is not analyzed. Topic names are always public, even if you add the topic on a private repository. Private repositories can have topics, but topic search only shows private repositories you already can access.

Explore GitHub (github.com/explore) helps you browse popular repositories and topics. If you have been active, Explore can show personalized recommendations based on contributions, stars, and other activity. Trending (github.com/trending) lists popular repositories of the day. Search finds a language, framework, or topic you already know. Stars save what you want to revisit. Following, from section 15.1, keeps people and orgs on your dashboard so their new public work shows up.

Once you land on a project, maintainer-friendly labels make first contributions discoverable. Many communities mark good first issue and help wanted. Copilot Chat can even search for public repositories that use those labels. Insights Pulse is how you check whether a project is still maintained before you invest a weekend. Non-code work—docs, tests, reproducing bugs—counts as contributing; the discovery labels are how newcomers find a door.

Public, internal, and private: who can discover what

Visibility is the real discoverability switch.

• Public repositories are accessible to everyone on the internet. They appear in Explore, Trending, topic pages, unauthenticated search, and search engines. They are how open source is discovered. They are also visible to attackers; security features and a SECURITY.md still matter.
• Private repositories are accessible to you, people you explicitly share with, and, in organizations, members who have been granted access (plus org owners, who can see every org repository). A private repo is not listed for the whole company just because it sits in the org. It will not show up on public Trending. Teammates without permission cannot stumble onto it through github.com/topics.
• Internal repositories exist for organizations owned by a GitHub Enterprise account. Every enterprise member can see them, including people who are not members of the owning organization. People outside the enterprise, including outside collaborators on other org repos, cannot. Internal is the visibility GitHub documents for InnerSource: open-source-style collaboration inside the company without publishing proprietary code to the internet. Internal is the default for new repositories in an enterprise-owned organization. Domain 7.5 covers InnerSource culture; this bullet is the discovery mechanism—internal makes the repo findable enterprise-wide.

Managed user accounts generally cannot create public repositories. That is an EMU constraint from Domain 6, and it means those users cannot use public Explore the way a personal account can.

Exam scenarios

You cannot push to octocat/Spoon-Knife, but you want a typo fix merged. You fork, clone your fork, branch, and open a pull request to upstream. Use this template would start a disconnected project and would not send the fix back. Cloning upstream without a fork leaves you with no GitHub push target.

A platform team maintains acme/service-template with a Dockerfile and CI workflow. Product teams should not send pull requests into that kit for their business logic. An admin checks Template repository. Each team clicks Use this template. Their commits count on the contributions graph. Forking the kit would keep history and an upstream link they do not want.

A company wants every engineer to find the shared authentication library without making it public. They use an internal repository on GitHub Enterprise, add topics such as auth and innersource, and let enterprise search surface it. A private library would stay invisible to people not granted access. A public library would leak onto the internet.

Traps GH-900 will set

• Fork versus template. History, contributions graph, and upstream link are the three differences. "I need a copy" is not enough—ask whether work should return to the parent.
• Fork versus clone versus branch. Clone is local. Branch is same repo. Fork is another GitHub repository.
• Use this template versus Fork. The buttons are neighbors. Template creates a new project; Fork keeps the contribution path.
• Private is not org-wide discovery. Internal is. Do not say private InnerSource is automatically visible to every org member.
• Public topics on private repos. The topic name is public even when the repository is not.
• Star is not discovery for other people. Star helps you find the repo later and feeds rankings; topics and public/internal visibility help others find it.
• good first issue is a label, not a visibility setting. It only helps people who can already see the repository.

If you remember only one sentence: Fork to contribute back, template to start fresh, clone to work locally, branch inside a repo you can push to—and only public or internal visibility makes a repository broadly discoverable.