GitHub Fundamentals

7 min readGitHub Engineering · GitHub Fundamentals

Almost everything on GitHub hangs off a repository. Issues belong to one. Pull requests compare branches within one. Releases attach to its tags. Pages serves from it. Permissions, policy and automation are configured per repository.

So the useful way to learn GitHub’s fundamentals is not as a list of features, but as a question: what does GitHub attach to a Git repository, and when should you use each attachment?

That framing matters because most of these features overlap. Issues and Discussions can both hold a conversation. Wikis, /docs and Pages can all hold documentation. Forks and clones both make copies. Choosing badly is easy, and some of those choices are awkward to reverse.

Start with Lesson 1

What this cluster covers

The ten lessons fall into three groups.

Getting set up properly — your account and the repositories themselves. This sounds like the boring part, and it is where the expensive mistakes happen: an account without recovery, a repository whose visibility was chosen without thinking about what is in its history, a default branch renamed after twenty people cloned it.

Copying and collaborating — forks and stars. Both are widely misunderstood. A fork is a server-side relationship, not a copy command. A star is an attention signal, not a quality ranking.

The collaboration surfaces — Issues, Discussions, Wikis, Releases and Pages. Five features that attach to a repository, each with a job it does well and jobs it does badly.

Prerequisites

This cluster assumes you can already work with Git locally. Specifically:

You should be able to	Covered in
Initialise a repository and commit to it	Your First Git Repository
Explain what a commit, branch and tag are	Git Objects Explained
Add a remote and push to it	Git Repository Structure
Say what `.git/` contains	How Git Actually Works

If you have never used Git at all, start with Git Fundamentals instead. This cluster is about what GitHub adds, and that only makes sense once you know what it is adding to.

Learning objectives

By the end of this cluster you should be able to:

Secure a GitHub account properly, and explain the difference between your Git identity and your GitHub identity.
Create repositories deliberately — visibility, default branch, licence and ignore rules chosen rather than accepted.
Explain what repository visibility does and does not protect, and why “private” is not a secret management strategy.
Describe a fork as a tracked server-side relationship, and know when it is the right tool.
Choose correctly between an Issue and a Discussion, and between a Wiki, a /docs directory and a Pages site.
Publish a Release that is genuinely useful — tag, notes and assets — and explain how it differs from the Git tag underneath it.
Decide whether GitHub Pages is the right host for a given site, including when it is not.

The learning path

How the pieces fit together

It helps to see the whole cluster as one picture before starting on the parts.

A repository holds your Git objects and carries GitHub’s settings. Its visibility determines who can read it, which in turn constrains almost every other feature — some are unavailable on private repositories under certain plans, and some behave differently.

A fork is another repository that GitHub records as derived from yours. That recorded relationship is what allows a pull request to cross from one repository to another, which is what makes drive-by open-source contribution possible at all.

Issues track work on the repository. Discussions hold conversation that is not work. Wikis hold documentation that is not versioned alongside the code. Releases mark points in history worth distributing, and attach the artefacts people actually download. Pages publishes static content from the repository to the web.

None of these are load-bearing rules, and teams reasonably deviate from all of them. But defaulting to them costs nothing and avoids the two most common outcomes: an Issue tracker full of open-ended conversations that never close, and a Wiki that quietly contradicts the code.

Difficulty and pacing

The cluster is ordered so that each lesson can assume the previous ones, but the difficulty is not uniform. Most of it is beginner material; two lessons are meaningfully harder.

Lessons	Level	Why
Account Setup through Wikis	Beginner	Concepts are simple; the care is in the decisions
Releases	Beginner → Intermediate	Introduces release engineering and semantic versioning
GitHub Pages	Beginner → Intermediate	Touches DNS, HTTPS, build pipelines and hosting trade-offs

If you are already using GitHub daily, Account Setup and Creating Repositories will be mostly review — though the security checklist in the first and the visibility discussion in the third are worth reading even so, because they are the two places where experienced users most often have a gap they are unaware of.

Mistakes this cluster is designed to prevent

Every lesson has a mistakes section, but a few are worth flagging up front because they are expensive and common.

Committing a secret to a private repository and assuming it is contained. It is in history, in every clone, and in every fork made before you noticed. Rotating the credential is the fix; deleting the commit is not.

Choosing a repository name you will want to change. Renaming works and GitHub redirects the old URL, but package registries, CI configuration, documentation links and other people’s remotes do not all follow. Spending two minutes on the name is cheap.

Forking when you meant to clone. A fork creates a permanent, publicly visible relationship between two repositories and an extra copy you now have to keep current. If you just want the code locally, clone it.

Using Issues as a discussion forum. Issues that cannot close accumulate, and an Issue tracker where half the entries will never close stops being a useful signal of outstanding work.

Treating a Wiki as documentation of record. A Wiki lives in a separate Git repository that your code changes never touch, so it drifts silently. Documentation that must match the code belongs beside the code.

Publishing a Release with no notes and no assets. At that point you have made a tag with extra steps. The value of a Release is the notes and the artefacts.

Exercise: build one repository properly

Do this once, deliberately, before starting the lessons. It takes about twenty minutes and gives you a repository to experiment with for the rest of the pillar. Use a throwaway name — you will delete it later.

Create a repository with a README, a licence and a .gitignore chosen for a real language.
Clone it and make two commits on a branch.
Open an Issue describing something you intend to change.
Push the branch and note that GitHub offers to open a pull request — do not open it yet; that is the next cluster.
Tag a commit and publish a Release from that tag, with notes.
Enable Discussions and post one question.

Then answer, from what you can see: which of those six artefacts survive a fresh git clone? That question is the whole of the Git/GitHub boundary in practical form, and having done it once makes the rest of this pillar concrete rather than abstract.

Keep the repository. Later clusters will operate on it with the CLI and then with the API, and having a repository you are entirely free to break is genuinely useful.

What this cluster deliberately does not cover

GitHub Projects. Issues integrate with Projects, and the Issues lesson mentions the connection, but planning and portfolio management is a different subject with a different audience. Treating Issues as a Projects tutorial is a common way to lose the thread.

GitHub Actions. Releases and Pages both integrate with Actions, and both lessons say so, but CI and CD get their own pillar. Here they appear only as far as necessary to explain the feature under discussion.

Organisations and enterprise administration. Organisation-owned repositories and organisation policy come up throughout, because they change what is available, but administering an organisation is out of scope.

Then what?

The next cluster is where GitHub stops being a place to put code and becomes a way for a team to change it together.

Once you can create a repository and open an Issue, the natural next question is how a proposed change gets discussed, reviewed and accepted — which is the Pull Requests cluster, the largest in this pillar.

Begin: GitHub Account Setup