GH-900: GitHub Foundations Ultimate Cheat Sheet
Your Quick Reference Study Guide
This cheat sheet covers the core concepts, terms, and definitions you need to know for the GH-900: GitHub Foundations. We've distilled the most important domains, topics, and critical details to help your exam preparation.
💡 Note: While this study guide highlights essential concepts, it's designed to complement—not replace—comprehensiv e learning materials. Use it for quick reviews, last-minute prep, or to identify areas that need deeper study before your exam.
About This Cheat Sheet: This study guide covers core concepts for GH-900: GitHub Foundations. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
GH-900: GitHub Foundations
Cheat Sheet •
About This Cheat Sheet: This study guide covers core concepts for GH-900: GitHub Foundations. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Introduction to Git and GitHub
22%Branching (lightweight refs)
Named movable pointers to commits that isolate features/bugfixes so you can create/switch/merge safely.
Key Insight
A branch is a pointer, not a file copy—switching moves HEAD; merges may fast‑forward or create merge commits.
Often Confused With
Common Mistakes
- Thinking a branch is a full copy of the repo files (it's a ref to commits).
- Assuming many branches will bloat repo size (branches are lightweight).
- Believing deleting a local branch also deletes the remote branch (remote refs must be removed explicitly).
git push — share commits & update remote refs
Uploads commits and updates the named remote refs (branches/tags); rejected on non‑fast‑forward unless forced.
Key Insight
Push sends only commits reachable from the refs you push; a non‑fast‑forward means remote has new commits—pull/rebase first or force with caution.
Often Confused With
Common Mistakes
- Thinking git push uploads every local branch and tag by default.
- Interpreting a non‑fast‑forward rejection as lost or corrupted local commits.
- Believing force‑push is harmless if you keep a local copy (it can overwrite others' remote commits).
Git Remote — named URL refs (origin)
Local named refs pointing to remote URLs; used to fetch, push, and set branch tracking.
Key Insight
Remotes are config pointers — changing or removing them locally doesn't delete or become a live server copy; 'origin' is just a name.
Often Confused With
Common Mistakes
- Assuming 'git remote remove' deletes the project on the server
- Believing a remote is a live server working copy you can edit
- Thinking 'origin' always means the original project owner
Local Repository — working tree, index, .git
Developer's repo on disk: working directory + staging index + .git history; commits stay local until pushed.
Key Insight
.git stores the full history and refs; commits live locally until you push and only staged files are recorded in a commit.
Often Confused With
Common Mistakes
- Assuming 'git commit' shares changes with collaborators (it's local until pushed)
- Thinking .git contains only current files rather than full history and metadata
- Believing un‑staged edits are automatically part of the next commit
Clone — Local copy + origin remote
Create a local copy of a remote repo (files, branches, tags, full history) and set origin.
Key Insight
git clone copies the full history and sets the 'origin' remote; only the default branch is checked out unless you switch or use flags like --branch or
Often Confused With
Common Mistakes
- Thinking clone copies only the latest snapshot — it copies full history unless --depth is used.
- Assuming clone creates a new remote repo — it only makes a local copy and an 'origin' reference.
- Expecting immediate push access after clone — pushing needs proper auth or collaborator rights.
Commit — Immutable snapshot from staged files
Record a snapshot and metadata from staged changes; commits link by hashes to build repository history.
Key Insight
Commits store full snapshots of tracked files (not diffs); you must stage with git add first; git commit --amend rewrites the latest commit.
Often Confused With
Common Mistakes
- Thinking commits store only diffs — Git records snapshots of tracked files.
- Assuming untracked files are auto-included — run git add to stage them.
- Believing git add immediately saves to remote — it only stages changes locally.
Merge Conflicts — Resolve, Stage, Finish
When Git can't auto-merge overlapping edits; you must pick/merge hunks, stage, and complete the operation.
Key Insight
Resolve by editing marked hunks, then git add the files and git commit (or git merge --continue); staging is required.
Often Confused With
Common Mistakes
- Conflicts only happen on merge — false; they also occur on rebase, cherry-pick, etc.
- Deleting conflict markers without choosing which content to keep doesn't resolve the conflict.
- Editing files alone won't finish it — you must stage and commit (or use --continue).
PR Base vs Compare — Target (base) vs Source (compare)
Base is the merge target; compare (source/head) has the proposed commits and defines the diff and merge direction.
Key Insight
Changing the base flips the diff and the merge target — pick the base to control where commits land and which CI/releases run.
Often Confused With
Common Mistakes
- Mistaking the base for containing the new commits — the compare/source branch holds them.
- Believing the base must be the repo default (main/master) — any branch can be chosen as base.
- Assuming merging always deletes the source branch — deletion is optional and must be selected.
GitHub Repo Navigation
Use the Code/Issues/Pull Requests/Actions/Projects/Insights tabs and the branch selector to find files, branches, CI, PR
Key Insight
Actions holds CI workflow runs/logs; Code shows the default branch until you switch; opening a PR ≠ merging it.
Often Confused With
Common Mistakes
- Searching Insights for CI logs — workflow runs and logs are under Actions.
- Assuming opening a pull request automatically merges the branch.
- Expecting Code to show files from every branch without using the branch selector.
Issue & PR Labels
Color-coded tags on issues/PRs to categorize, filter, and prioritize; created and managed by repo maintainers.
Key Insight
Label color is cosmetic and team-defined; labels don't auto-assign, close issues, or trigger CI by themselves.
Often Confused With
Common Mistakes
- Treating label color as an automatic, platform-defined priority (e.g., red ≠ always high priority).
- Thinking applying a label auto-assigns the issue or closes it.
- Expecting labels to be global across all repos or to automatically trigger workflows/permissions.
Branching (lightweight refs)
Named movable pointers to commits that isolate features/bugfixes so you can create/switch/merge safely.
Key Insight
A branch is a pointer, not a file copy—switching moves HEAD; merges may fast‑forward or create merge commits.
Often Confused With
Common Mistakes
- Thinking a branch is a full copy of the repo files (it's a ref to commits).
- Assuming many branches will bloat repo size (branches are lightweight).
- Believing deleting a local branch also deletes the remote branch (remote refs must be removed explicitly).
git push — share commits & update remote refs
Uploads commits and updates the named remote refs (branches/tags); rejected on non‑fast‑forward unless forced.
Key Insight
Push sends only commits reachable from the refs you push; a non‑fast‑forward means remote has new commits—pull/rebase first or force with caution.
Often Confused With
Common Mistakes
- Thinking git push uploads every local branch and tag by default.
- Interpreting a non‑fast‑forward rejection as lost or corrupted local commits.
- Believing force‑push is harmless if you keep a local copy (it can overwrite others' remote commits).
Git Remote — named URL refs (origin)
Local named refs pointing to remote URLs; used to fetch, push, and set branch tracking.
Key Insight
Remotes are config pointers — changing or removing them locally doesn't delete or become a live server copy; 'origin' is just a name.
Often Confused With
Common Mistakes
- Assuming 'git remote remove' deletes the project on the server
- Believing a remote is a live server working copy you can edit
- Thinking 'origin' always means the original project owner
Local Repository — working tree, index, .git
Developer's repo on disk: working directory + staging index + .git history; commits stay local until pushed.
Key Insight
.git stores the full history and refs; commits live locally until you push and only staged files are recorded in a commit.
Often Confused With
Common Mistakes
- Assuming 'git commit' shares changes with collaborators (it's local until pushed)
- Thinking .git contains only current files rather than full history and metadata
- Believing un‑staged edits are automatically part of the next commit
Clone — Local copy + origin remote
Create a local copy of a remote repo (files, branches, tags, full history) and set origin.
Key Insight
git clone copies the full history and sets the 'origin' remote; only the default branch is checked out unless you switch or use flags like --branch or
Often Confused With
Common Mistakes
- Thinking clone copies only the latest snapshot — it copies full history unless --depth is used.
- Assuming clone creates a new remote repo — it only makes a local copy and an 'origin' reference.
- Expecting immediate push access after clone — pushing needs proper auth or collaborator rights.
Commit — Immutable snapshot from staged files
Record a snapshot and metadata from staged changes; commits link by hashes to build repository history.
Key Insight
Commits store full snapshots of tracked files (not diffs); you must stage with git add first; git commit --amend rewrites the latest commit.
Often Confused With
Common Mistakes
- Thinking commits store only diffs — Git records snapshots of tracked files.
- Assuming untracked files are auto-included — run git add to stage them.
- Believing git add immediately saves to remote — it only stages changes locally.
Merge Conflicts — Resolve, Stage, Finish
When Git can't auto-merge overlapping edits; you must pick/merge hunks, stage, and complete the operation.
Key Insight
Resolve by editing marked hunks, then git add the files and git commit (or git merge --continue); staging is required.
Often Confused With
Common Mistakes
- Conflicts only happen on merge — false; they also occur on rebase, cherry-pick, etc.
- Deleting conflict markers without choosing which content to keep doesn't resolve the conflict.
- Editing files alone won't finish it — you must stage and commit (or use --continue).
PR Base vs Compare — Target (base) vs Source (compare)
Base is the merge target; compare (source/head) has the proposed commits and defines the diff and merge direction.
Key Insight
Changing the base flips the diff and the merge target — pick the base to control where commits land and which CI/releases run.
Often Confused With
Common Mistakes
- Mistaking the base for containing the new commits — the compare/source branch holds them.
- Believing the base must be the repo default (main/master) — any branch can be chosen as base.
- Assuming merging always deletes the source branch — deletion is optional and must be selected.
GitHub Repo Navigation
Use the Code/Issues/Pull Requests/Actions/Projects/Insights tabs and the branch selector to find files, branches, CI, PR
Key Insight
Actions holds CI workflow runs/logs; Code shows the default branch until you switch; opening a PR ≠ merging it.
Often Confused With
Common Mistakes
- Searching Insights for CI logs — workflow runs and logs are under Actions.
- Assuming opening a pull request automatically merges the branch.
- Expecting Code to show files from every branch without using the branch selector.
Issue & PR Labels
Color-coded tags on issues/PRs to categorize, filter, and prioritize; created and managed by repo maintainers.
Key Insight
Label color is cosmetic and team-defined; labels don't auto-assign, close issues, or trigger CI by themselves.
Often Confused With
Common Mistakes
- Treating label color as an automatic, platform-defined priority (e.g., red ≠ always high priority).
- Thinking applying a label auto-assigns the issue or closes it.
- Expecting labels to be global across all repos or to automatically trigger workflows/permissions.
Working with GitHub Repositories
8%Merge Strategies (merge / squash / rebase)
Integrate branch commits into a target; chosen strategy alters history shape, authorship, and release notes.
Key Insight
Fast‑forward moves the branch pointer (no merge commit); merge commit preserves history; squash/rebase reshape commits and attribution.
Often Confused With
Common Mistakes
- Expecting a merge commit after a fast‑forward (it won't create one).
- Assuming squash permanently removes contributor attribution.
- Treating rebase-and-merge as identical to squash-and-merge.
CODEOWNERS — Auto-request Reviewers
Path-to-user/team file that auto-requests reviewers on PRs; must be on default branch and doesn't change permissions.
Key Insight
CODEOWNERS only requests reviewers; branch protection rules are required to enforce approvals; file must live on the default branch at root, .github/,
Often Confused With
Common Mistakes
- Believing CODEOWNERS alone enforces required approvals.
- Assuming adding to CODEOWNERS grants write or merge permissions.
- Thinking CODEOWNERS must be placed only at the repo root.
git log — Commit History
Show committed history; use --follow for renames, -p/--stat for diffs, --graph for merges.
Key Insight
git log lists committed snapshots only — add --follow to trace a file across renames and -p/--stat to see diffs.
Often Confused With
Common Mistakes
- Looking for staged/uncommitted changes in git log
- Not using --follow when tracing a file through renames
- Assuming branch/merge structure is shown without --graph or related flags
File Ops & Versioning
How files are staged, committed, pushed, and tracked; commits are snapshots and remotes require an explicit push.
Key Insight
Commits are local snapshots — nothing reaches the remote until git push; deletes keep prior history; renames are detected heuristically.
Often Confused With
Common Mistakes
- Assuming deleting a file removes its past commits/history
- Expecting a local commit to appear on the remote without git push
- Believing renames always record as a delete-plus-add in history
Collaboration Features
30%PR↔Issue Linking (Fixes # syntax)
Associate a PR with an issue using exact refs/closing keywords so merges auto-close and preserve traceability.
Key Insight
Only exact closing keywords + correct issue format trigger auto-close on merge; cross-repo needs owner/repo#N.
Often Confused With
Common Mistakes
- Believing any mention of an issue will auto-close it.
- Using casual phrasing (e.g., 'fix issue 123') instead of required keywords like 'Fixes #123'.
- Expecting labels/assignees/milestones to transfer between PR and issue.
PR CI Checks & Secrets (Actions/GitHub CI)
PR-triggered CI runs builds/tests and reports status checks that can block merges under branch protection.
Key Insight
Forked PR runs generally lack repo secrets; pull_request_target runs in the base repo (can use secrets) but executes untrusted code—use with care.
Often Confused With
Common Mistakes
- Assuming PR CI always has access to repository secrets (forks usually do not).
- Treating a passing CI as sole proof it's safe to merge without review or policy checks.
- Expecting the PR branch's workflow file to always run (pull_request_target may run the base workflow).
GitHub Actions — CI/CD Workflows
YAML workflows (events → jobs → steps) to build, test, and deploy code automatically on repo events.
Key Insight
Workflows run per-commit on specified triggers; runners can be GitHub-hosted or self-hosted — always vet third-party actions and secrets usage.
Often Confused With
Common Mistakes
- Assuming Actions only run on GitHub-hosted runners
- Printing secrets is safe because GitHub auto-redacts them
- Using Marketplace actions without reviewing code or permissions
Required Status Checks (Branch Protection)
A branch-protection gate that blocks merges until specified CI/status contexts report success on the branch head.
Key Insight
Only contexts explicitly listed in branch protection block merges; 'require up-to-date' forces checks on the current HEAD and admins can be exempt.
Often Confused With
Common Mistakes
- Treating every PR status as required — only configured contexts block merges
- Assuming repository admins are always prevented from merging
- Believing passing checks on an older commit satisfy 'require up-to-date'
Issues — Tasks, Bugs & Feature Requests
Repository work items for tasks, bugs, and features; use assignees, labels, milestones, and PR links to manage progress.
Key Insight
Issues are discussion/work items, not code — they only close manually or when a linked PR/commit uses closing keywords.
Often Confused With
Common Mistakes
- Treating an issue like a PR — issues can't be merged.
- Assuming anyone can open issues in every repo — issues can be disabled or restricted.
- Expecting labels or milestones to auto-enforce state or close issues without automation/closing keywords.
Issue Triage — Fast Categorize, Prioritize, Route
A reproducible process: assess incoming issues, apply templates/labels, set priority/severity, and route via automation.
Key Insight
Use issue forms + rule-based automation to enforce consistency, but keep human review for nuance and final priority.
Often Confused With
Common Mistakes
- Thinking adding labels completes triage — labeling is one step, not the whole process.
- Relying entirely on automation to make severity/priority calls — automation can't cover nuance.
- Conflating priority with severity — a severe bug isn't always the highest priority to fix now.
Modern Development
13%Third‑Party Action Security (Marketplace Safety)
Vet and pin Marketplace Actions; enforce least‑privilege tokens and provenance to prevent supply‑chain risk.
Key Insight
Pin to a commit SHA and review action code; JS actions run on the runner (broad access), Docker runs in a container, composite just wraps steps on the
Often Confused With
Common Mistakes
- Assuming Marketplace listing means the action is safe — always review provenance and code.
- Pinning to a tag equals immutability — pin to a commit SHA for true immutability.
- Believing 'read' workflow permissions or installation isolates secrets — tokens can still be abused if allowed.
Dependabot — Automated Dependency PRs
Scans manifests, opens version/security PRs and alerts; configure update policies and automerge cautiously.
Key Insight
Dependabot opens PRs that trigger CI like any PR; it won't merge changes unless automerge + passing checks are configured and constraints allow it.
Often Confused With
Common Mistakes
- Thinking Dependabot auto-merges by default — automerge needs explicit config and passing checks.
- Assuming Dependabot only handles security fixes — it also does routine version and lockfile updates.
- Believing Dependabot always upgrades to latest major — it respects your version constraints unless told otherwise.
Branch Protection Rules (Merge Gates & CODEOWNERS)
Repo settings that block merges until branches matching a pattern meet required reviews, status checks, or CODEOWNERS.
Key Insight
Rules apply only to branches matching the pattern; they enforce passing checks but don't run CI and admins can bypass unless disabled.
Often Confused With
Common Mistakes
- Assuming protection applies to every branch — it's pattern-based.
- Expecting required checks to run automatically — CI must be configured separately.
- Believing admins are always blocked — admin bypass can be allowed unless disabled.
PR Review Responses (Approve / Request Changes / Comment / Suggest)
The four PR review states; only 'Approve' counts as an approval and affects mergeability under branch protection.
Key Insight
Only 'Approve' registers as an approval; 'Comment' doesn't, 'Request changes' blocks merge until replaced, and new commits can dismiss approvals.
Often Confused With
Common Mistakes
- Thinking 'Approve' immediately merges the PR.
- Assuming one approval always satisfies required-reviewer counts.
- Believing approvals never reset after new commits — they can be dismissed.
Project Management
7%Issue Assignees — Users, Permissions & Limits
Assign GitHub users to issues/PRs to show responsibility; assignment doesn't change permissions or replace reviewers.
Key Insight
Assignees are individual users; anyone with write access can assign; assignment never modifies repo permissions.
Often Confused With
Common Mistakes
- Only owners can assign — users with write access may also assign.
- Assigning someone grants write access — it does not change permissions.
- Assignee = reviewer — reviewers are a separate code-review role.
Classic Project Column — workflow lane
Vertical lane on a classic project board representing a workflow stage; cards (issues/PRs/notes) move between columns.
Key Insight
Columns are board-scoped (not labels); moving cards doesn't change labels or open/closed state unless automation is configured.
Often Confused With
Common Mistakes
- Treating a column as a label — moving a card doesn't change issue labels.
- Assuming columns are repository-global — they're scoped to the classic project.
- Believing moving a card auto-closes/opens issues — state only changes with explicit actions/automation.
Privacy, Security, and Administration
10%Repository Visibility (Public / Private / Internal)
Controls who can view, discover, and clone a repo — visibility sets read/discovery scope.
Key Insight
Visibility controls read/discovery only; write and admin access are separate permissions.
Often Confused With
Common Mistakes
- Assuming public repos let anyone push; write access still requires explicit permission.
- Treating internal as identical to private — internal shares only inside an org/enterprise.
- Thinking internal repos are visible to every GitHub user or available on all plans.
Repo Security Tab — Controls & Alerts
Per-repo security controls (vulnerability alerts, dependency/secret scans, dependabot) to surface risks.
Key Insight
Security features report and enable fixes; they rarely auto-remediate and some settings live at org level.
Often Confused With
Common Mistakes
- Assuming all security controls are only in the Security tab — some live in Settings or org-level policies.
- Believing enabling an alert or scan auto-fixes vulnerabilities; most need manual or PR fixes.
- Assuming scans or Dependabot updates run with full admin privileges by default.
Org Members, Teams & Repo Roles
Maps members and teams to repo roles (Read, Triage, Write, Maintain, Admin) and resulting effective permissions.
Key Insight
Effective permission = the highest allowed action from all grants (direct + teams); branch protection can still block those actions.
Often Confused With
Common Mistakes
- Assuming Write grants full admin rights (visibility changes or repo deletion require Admin).
- Believing Triage lets you push commits or merge PRs.
- Thinking a direct user grant always overrides team grants — highest effective permission wins.
Secrets, GITHUB_TOKEN & Auth Scopes
Encrypted values scoped to repo/org/environment; GITHUB_TOKEN is ephemeral and limited to the workflow run, not a PAT.
Key Insight
Secrets are scoped and can be gated by environment rules; workflows from forks can't access repo/org secrets by default and GITHUB_TOKEN ≠ PAT.
Often Confused With
Common Mistakes
- Assuming secrets are available to pull-request workflows from forks.
- Treating GITHUB_TOKEN the same as a user PAT (lifetime/privileges differ).
- Believing masking guarantees zero leakage — third-party actions or poor use can still expose secrets.
Benefits of the GitHub Community
10%Pull Request (PR) — Propose & Merge
Proposal to merge commits from a source (compare) branch into a target (base) branch; central for review and CI gating.
Key Insight
A PR is a proposal — base vs compare determines which commits merge; pushing to the source branch updates the same PR and CI runs per pushed commit.
Often Confused With
Common Mistakes
- Assuming opening a PR automatically merges changes into the base branch.
- Believing status checks only run on the merge commit instead of each pushed PR commit.
- Creating a new PR for every commit instead of pushing updates to the existing PR branch.
Fork — Personal Repo Copy for Contributions
Independent copy of a repository under your account to develop changes, sync with upstream, and open PRs back to the org
Key Insight
A fork is a separate GitHub repo — pushes to your fork don't affect upstream; open PRs from a feature branch in your fork and sync via an upstream rem
Often Confused With
Common Mistakes
- Assuming changes pushed to a fork automatically appear in the upstream repository.
- Thinking forking creates a branch inside the original repository.
- After rebasing a pushed branch, forgetting you usually must force-push to update the fork.
Discussion → Issue Conversion
How a discussion’s content, authors, and history are copied into an issue and what changes after conversion.
Key Insight
Conversion copies the original post + comments (with authors/timestamps) into a new issue; the discussion remains linked—labels, assignees, and enroll
Often Confused With
Common Mistakes
- Thinking conversion deletes the original discussion.
- Believing marking an answer automatically closes or removes the discussion.
- Assuming any contributor can convert — conversion requires triage‑or‑higher (or maintainer) permissions.
Notification Controls: Watch, Subscribe, Mute
Repo and thread settings (watch/subscribe/mute) plus delivery channels control who gets web/email/mobile alerts.
Key Insight
Watch = repo preference; Subscribe = per-thread; @mentions usually notify but can be blocked by mute/filters; email off ≠ web/mobile off.
Often Confused With
Common Mistakes
- Expecting 'Watch' alone to guarantee notifications for every issue/PR without per-thread subscription.
- Confusing 'Watch' with access — watching does not grant collaborator or write permissions.
- Assuming @mention always overrides mutes or that turning off email disables web/mobile notifications.
Certification Overview
Cheat Sheet Content
Similar Cheat Sheets
- CCNA Exam v1.1 (200-301) Cheat Sheet
- AWS Certified Cloud Practitioner (CLF-C02) Cheat Sheet
- AWS Certified AI Practitioner (AIF-C01) Cheat Sheet
- Exam AI-900: Microsoft Azure AI Fundamentals Cheat Sheet
- Google Cloud Professional Cloud Architect Cheat Sheet
- Google Cloud Security Operations Engineer Exam Cheat Sheet