GitHub Foundations #3 Domain 2: Working with Repositories — Branches, Tags, Releases, and Gists

Domain 2 covers the basic unit of work on GitHub: the repository. Its scope is the full lifecycle — creating one, furnishing it with the right files, copying it, setting its visibility, and managing its lifespan. The concepts are not hard, but the exam asks precisely about features that look similar (fork vs clone, tag vs release), so this post is organized around those boundaries.

Creating a repository and its initialization options #

When you create a repository on the web with New repository, you decide three things: the name and description, the visibility, and the initialization options. The three initialization options each put one file into the first commit.

• README — The introduction document rendered on the repository’s front page.
• .gitignore — Lays down ignore rules up front, chosen from per-language templates (Python, Node, and so on).
• LICENSE — The license file stating the terms of use for the code. A point that sometimes gets tested: a public repository without a license is code that others legally cannot use.

Community files — special files with fixed names #

GitHub treats files with certain fixed names specially. The exam asks about this in the form “where does this information go”.

The profile README — a README in a repository named the same as your personal account, shown on your profile page — is another item mentioned in Domain 2.

The default branch — the repository’s reference branch #

Every repository has one reference branch. It is the branch checked out on a fresh clone and the default base when opening a PR. The current default name is main, and you can change it to another branch in the repository settings. Enforcement rules on branches are covered under Domain 6, so here it is enough to fix the name and the role.

Tags and releases — same point, different layers #

This is the signature distinction of Domain 2.

• Tag — A label attached to a specific commit, and a Git feature. Used to mark versions like v1.2.0.
• Release — A GitHub feature that publishes release notes and build artifacts (assets) on top of a tag. It creates a download page, and source code archives are attached automatically.

In other words, a release cannot exist without a tag (you can create a new tag while making one), while a tag exists fine without a release. The answer to “what do you use to distribute binary files to users?” is a release.

Gists — sharing code snippets lighter than a repository #

To share a snippet of a few files, use a gist instead of a repository. There are two kinds.

• Public gist — Exposed to search and the discover page.
• Secret gist — Not exposed to search, but anyone with the URL can view it. The exam point is that this is not access control like a private repository.

A gist is internally a Git repository too, so you can clone it and manage versions.

Fork, clone, template repository — three kinds of copying #

This is the most frequently tested distinction in Domain 2. All three look like “copying a repository”, but the direction and the connection differ.

These appear as scenario questions. “How do you propose a change to a project you cannot write to?” is fork then PR; “how do you start a new project from the team’s standard structure?” is a template repository. Also remember that a fork is a server-to-server copy — forking alone puts nothing on your computer, and to work on it you still have to clone your fork.

Repository visibility — public, private, internal #

• public — Anyone on the internet can read it. Writing is a separate permission.
• private — Only invited collaborators and teams with granted permissions have access.
• internal — Enterprise-only; visible to all members of the same enterprise. Used for internal sharing (InnerSource).

When the scenario is “open to everyone in the company, closed to the outside”, the answer is internal. That it is only available on the Enterprise plan is part of the same test point.

Topics, stars, watch — discovering and following repositories #

Finding and following repositories is also in Domain 2’s scope. The distinction between the three features is the test point.

• Topic — A classification keyword attached to a repository. Declaring subjects like machine-learning or hugo makes the repository discoverable via topic search. The name resembles a tag (a commit label) but it is a completely different feature.
• Star — A mark of interest and a bookmark. You can find the repository again in your starred list, and a repository’s star count reads as a popularity signal. Starring does not produce notifications.
• Watch — A notification subscription. Activity in a watched repository — Issues, PRs, releases — arrives as notifications, and you can choose the scope: all activity, releases only, or mentions only.

For the scenario “I only want news of a repository’s new releases”, the answer is watch (releases only), not star. One line settles it: a star is for remembering, a watch is for being notified.

Archive, delete, transfer — managing a repository’s lifespan #

• Archive — Switches the repository to read-only. Issues, PRs, and pushes all lock, and an archive notice appears on the front page. It is how you preserve a project whose maintenance has ended without deleting it, and it can be reversed at any time.
• Delete — Removes the repository. There is a short window for restoration right after deletion, but treat it as irreversible; if preservation is the goal, archiving is the intended answer.
• Transfer — Moves repository ownership to another account or Organization. After the move, access to the old URL redirects to the new location.

Wrapping up #

Three takeaways from this post.

• A repository builds its guidance system out of fixed-name community files — README, LICENSE, CONTRIBUTING — and keeps templates and configuration in the .github/ directory.
• A tag is a commit label (Git) and a release is a distribution page (GitHub); fork, clone, and template are distinguished by copy direction and the link to the original.
• Visibility has three levels — public, private, internal — and internal is Enterprise-only.

The next post, “GitHub Foundations #4 Domain 3-1: Collaboration — Issues, Labels, Milestones, and Templates”, enters the domain with the largest weight on the exam. We start with the Issue-centered work management features.