GitHub Foundations #2 Domain 1: Git and GitHub Basics — Version Control and Product Structure

Sunday, July 26, 2026

6 min read

Domain 1 is the foundation of the whole exam. The two distinctions you establish here — the boundary between Git and GitHub and the structure of accounts and plans — are the premise for every later domain. The proper way to learn the Git commands themselves is hands-on, through the series starting at this blog’s Git Basics #1, so this post distills only the points the exam asks about.

The Git the exam asks about — the essentials again #

A version control system records the history of file changes, lets you return to past points, and merges edits from multiple people safely. For Git, the exam checks understanding at the following level rather than deep internals.

Git is a distributed version control system. The entire repository, history included, exists on each person’s computer, and commits and lookups work without a network.
A commit is not a diff but a snapshot of the entire project at that point.
Files are recorded through three areas: the working directory, the staging area, and the repository.

For the basic commands, being able to state each one’s role in a single line is enough.

Command	Role
`git init`	Initialize the current directory as a repository
`git clone`	Copy a remote repository, history included
`git status`	Summarize the current state of the three areas
`git add`	Put changes for the next commit into the staging area
`git commit`	Record a snapshot from the staging area’s contents
`git branch` / `git switch`	List branches / switch branches
`git merge`	Combine another branch’s changes into the current branch
`git push` / `git pull`	Upload to the remote / fetch from the remote and merge

If this table looks unfamiliar, we recommend finishing the Git Basics series first and coming back. The Git questions in Domain 1 overlap almost entirely with that series.

Git and GitHub are different things #

This is the most frequently tested distinction in Domain 1. If you tend to use the two words interchangeably, draw the boundary clearly before the exam.

Git — A version control tool that runs on your computer. It is open source and not any company’s service. Commits, branches, and merges all belong to Git.
GitHub — A cloud hosting platform for Git repositories, with collaboration features (Issues, Pull Requests, reviews, Actions) layered on top.

So the answer to “Can you use Git without GitHub?” is “yes”. Conversely, GitHub’s Pull Request is a platform feature, not a Git command — there is no such command as git pull-request. It is also worth knowing that GitLab and Bitbucket are alternative platforms at the same layer.

Account structure — personal, Organization, Enterprise #

GitHub accounts come in three tiers.

Personal account — The account of one person. You create repositories you own and get invited to other repositories as a collaborator.
Organization — Not a person but a shared owner for multiple people. Repositories are owned in the organization’s name, and members are grouped into teams that receive per-repository permissions as a unit. This is the form companies and open source projects use.
Enterprise account — The top-level unit that groups multiple Organizations and manages policy (authentication methods, policy enforcement, billing) in one place.

On the exam, this appears as scenario questions: “multiple teams need to share repository permissions” points to Organization, and “manage policy across several Organizations” points to Enterprise.

Plans — Free, Team, Enterprise #

Questions about feature boundaries come up often in this area. The big picture is as follows.

Plan	Core
Free	Unlimited public and private repositories, core collaboration features, free usage allowances for Actions and Codespaces
Team	Everything in Free plus advanced collaboration features such as protected branches and code owners in private repositories, and larger allowances
Enterprise	Everything in Team plus enterprise authentication like SAML SSO, internal repositories, enhanced audit logging, and the GitHub Advanced Security add-on

Two boundaries are exam regulars.

Branch protection works on public repositories even on Free, but private repositories need Team or above. This is the staple behind “which of these is not available in a private repository on the Free plan” questions.
Internal repository visibility and SAML SSO are Enterprise-only. When a scenario involves company-wide scale, think Enterprise.

Note

Two exam pointers. First, decide whether a question is asking about a Git command or a GitHub feature. “The command that creates a branch” belongs to Git; “the feature that assigns a reviewer to a PR” belongs to GitHub. Second, plan-boundary questions usually ask “from which plan is this feature available”, so remembering the two boundaries in the table above (protected branches in private repos = Team, internal visibility and SSO = Enterprise) resolves most of them.

GitHub Flavored Markdown — the platform-wide writing language #

Domain 1 also includes Markdown basics, because every text input on GitHub — READMEs, Issues, PR descriptions, comments — is rendered as GitHub Flavored Markdown (GFM). The exam tests this at the level of looking at syntax and choosing the result, or the reverse.

Frequently tested GFM syntax

# Heading 1        ## Heading 2
**bold**           *italic*
- Unordered list
1. Ordered list
[link text](https://example.com)
![image alt text](image.png)
`inline code`
- [ ] Task list (checkbox)

The extensions GitHub adds on top of standard Markdown are their own test points.

Task lists — - [ ] and - [x] create checkboxes, and in Issues and PRs you can toggle them directly on screen.
Mentions — @username notifies that user. Team mentions (@org/team-name) work too.
References — Writing a number like #123 links to that Issue or PR. Commit hashes link the same way.
Language on code fences — Writing a language name after the three backticks applies syntax highlighting.

Four ways to access GitHub #

That the same GitHub is reachable through several channels is also part of Domain 1.

Web browser — The default channel. Most collaboration features (Issues, PRs, reviews) happen on the web.
GitHub Desktop — The official GUI client. It handles commits and pushes without a terminal, which makes it useful for non-developer roles.
gh CLI — The official command-line tool. It operates GitHub’s platform features from the terminal, as in gh pr create and gh issue list. The exam point is that it complements Git commands rather than replacing them.
GitHub Mobile — The official app for on-the-go work such as checking notifications, approving reviews, and replying to Issues.

Including editor integrations (such as the GitHub extensions for VS Code), if you can answer “yes” to “Can you use GitHub without a terminal?”, this section has done its job.

Wrapping up #

Three takeaways from this post.

Git is a distributed version control tool that runs locally; GitHub is the platform that hosts those repositories and layers collaboration features on top. This boundary is the heart of Domain 1.
Accounts come in three tiers — personal, Organization, Enterprise — and shared ownership with team permissions means Organization.
Plan questions mostly reduce to two boundaries: protected branches in private repositories start at Team, and internal repositories plus SSO start at Enterprise.
GFM is the platform-wide writing language, and GitHub’s extensions — task lists, mentions, #number references — are the test points.

The next post, “GitHub Foundations #3 Domain 2: Working with Repositories — Branches, Tags, Releases, and Gists”, covers repository-level features, including the Domain 2 staple distinctions between forks, clones, and template repositories.