GH-900 — GitHub Foundations (GH-900) Exam Quick Reference

Last revised: June 18, 2026

Compact GitHub Foundations (GH-900) reference for Git, repositories, pull requests, collaboration, Actions, security, and GitHub platform basics.

Exam Focus

This independent Quick Reference supports candidates preparing for GitHub Foundations (GH-900), exam code GH-900, from GitHub. Use it to review the platform vocabulary, Git workflows, collaboration features, automation basics, and security/governance decisions that commonly appear in foundation-level GitHub scenarios.

High-yield expectation: be able to choose the right GitHub feature for a collaboration, automation, repository management, or security scenario.

Core Mental Model

Concept	What it means	Exam cue
Git	Distributed version control system	Local commits, branches, history, merge, rebase
GitHub	Cloud platform built around Git repositories	Collaboration, pull requests, issues, Actions, security, organizations
Repository	Project storage containing files, history, branches, issues, PRs, settings	“Where code and project history live”
Working tree	Your current local files	Files edited but not necessarily committed
Staging area / index	Prepared changes for the next commit	`git add` places changes here
Commit	Snapshot of staged changes with metadata	Local history point; not automatically on GitHub
Branch	Movable line of development	Isolate work without changing the default branch
Remote	Named reference to a hosted repository, often `origin`	Used by `fetch`, `pull`, and `push`
Clone	Local copy of a remote repository	Work locally with full history
Fork	Your own server-side copy of another repository	Contribute without direct write access
Pull request	Proposed change set plus review discussion	Review, checks, approval, merge
Issue	Track task, bug, enhancement, or discussion item	Work planning, not code review

Git vs. GitHub: Fast Distinctions

Do not confuse	Correct distinction
Git and GitHub	Git is the version control tool; GitHub is a collaboration platform that hosts Git repositories.
Commit and push	Commit records local history; push uploads commits to a remote repository.
Fetch and pull	Fetch downloads remote updates; pull fetches and integrates them into the current branch.
Branch and fork	Branch is a line of work in a repo; fork is a copy of a repo under another account.
Clone and fork	Clone creates a local copy; fork creates a GitHub-hosted copy.
Pull request and issue	PR proposes code changes; issue tracks work, bugs, or ideas.
Release and tag	Tag marks a Git point; release adds GitHub release notes/assets around a tag.
Watch and star	Watch controls notifications; star bookmarks or signals interest.
Project and repository	Repository stores code/history; Project tracks work items across repos.

Git Command Quick Sheet

Daily Workflow Commands

Task	Command	Notes
Create a new Git repository	`git init`	Initializes `.git` in the current directory.
Copy a remote repository locally	`git clone <url>`	Creates local repo and configures `origin`.
Check current state	`git status`	Shows branch, staged changes, unstaged changes, untracked files.
View history	`git log`	Use `--oneline --graph --decorate` for compact history.
See file changes	`git diff`	Unstaged changes by default.
Stage files	`git add <file>`	Adds selected changes to next commit.
Stage all tracked/untracked changes	`git add .`	Be careful not to stage secrets or generated files.
Commit staged changes	`git commit -m "message"`	Creates local snapshot.
List branches	`git branch`	Shows local branches.
Create branch	`git branch <name>`	Does not switch to it.
Switch branch	`git switch <name>`	Modern command for changing branches.
Create and switch branch	`git switch -c <name>`	Common feature-work command.
Add remote	`git remote add origin <url>`	Links local repo to hosted repo.
View remotes	`git remote -v`	Shows fetch/push URLs.
Download remote updates	`git fetch`	Safe; does not modify current branch content.
Download and integrate	`git pull`	Fetch plus merge/rebase, depending on configuration.
Upload commits	`git push`	Sends local commits to remote branch.
Push new branch	`git push -u origin <branch>`	Sets upstream tracking.

Safe Undo and History Commands

Scenario	Prefer	Why
Unstage a file	`git restore --staged <file>`	Keeps working tree changes.
Discard local file changes	`git restore <file>`	Reverts file to last committed state.
Undo a public/shared commit	`git revert <commit>`	Creates a new commit that reverses changes.
Edit most recent local commit	`git commit --amend`	Good before pushing; avoid rewriting shared history.
Temporarily shelve work	`git stash`	Useful before switching branches or pulling.
Reset branch pointer	`git reset`	Powerful; can rewrite history or discard work.
Force update remote branch	`git push --force-with-lease`	Safer than plain force push, but still risky.

Exam trap: revert is usually safer for shared history because it preserves history. reset --hard can discard local changes and rewrite branch state.

GitHub Repository Reference

Repository Visibility

Visibility	Who can see it	Common exam cue
Public	Anyone can view	Open source, public docs, public examples
Private	Only explicitly granted users/teams	Restricted project or confidential source
Internal	Members of an enterprise context, where available	Share across an enterprise without making public

Common Repository Files

File / path	Purpose
`README.md`	Project overview, usage, setup, status
`LICENSE`	Terms under which others may use the project
`.gitignore`	Files Git should not track, such as build output or local config
`CONTRIBUTING.md`	Contribution expectations and process
`CODE_OF_CONDUCT.md`	Community behavior expectations
`SECURITY.md`	Vulnerability reporting and supported versions guidance
`SUPPORT.md`	How users should request help
`CODEOWNERS`	Automatically requests reviews from responsible owners
`.github/ISSUE_TEMPLATE/`	Standardizes issue creation
`.github/PULL_REQUEST_TEMPLATE.md`	Standardizes PR descriptions
`.github/workflows/`	GitHub Actions workflow files

GitHub Flow

GitHub Flow is a lightweight branch-and-pull-request model.

    flowchart LR
	    A[Create branch] --> B[Make commits]
	    B --> C[Push branch]
	    C --> D[Open pull request]
	    D --> E[Discuss and review]
	    E --> F[Run checks]
	    F --> G{Ready?}
	    G -- No --> B
	    G -- Yes --> H[Merge]
	    H --> I[Deploy or release]

Step	Purpose	Common cue
Create branch	Isolate work from default branch	Feature, bug fix, experiment
Commit changes	Record small logical snapshots	Clear commit messages matter
Open PR	Start review and collaboration	Compare branch into base branch
Review	Comment, request changes, approve	Quality and knowledge sharing
Run checks	Validate with CI, tests, scans	Status checks before merge
Merge	Integrate approved changes	Method depends on repository settings

Pull Request Essentials

PR concept	Meaning	Exam trap
Base branch	Target branch that receives changes	Often `main`, but not always
Compare/head branch	Source branch containing proposed changes	This is the branch being merged
Draft PR	PR not ready for final review	Good for early feedback
Review comment	Feedback on code or PR	Not the same as approval
Approve	Reviewer accepts the change	May still require checks to pass
Request changes	Reviewer blocks until changes are made	Usually requires updates before merge
Status check	CI or external validation result	Can be required by branch protection
Linked issue	Issue connected to a PR	Closing keywords can close issues on merge
Merge conflict	Git cannot automatically combine changes	Must be resolved before merge

Merge Method Selection

Method	What it does	Choose when
Merge commit	Creates a merge commit preserving branch history	You want full branch context and non-linear history is acceptable
Squash merge	Combines PR commits into one commit on the base branch	You want a clean main history per PR
Rebase merge	Replays commits onto the base branch	You want linear history while preserving individual commits

Branch, Fork, Clone, and Template Decisions

Need	Choose	Why
Work locally on an existing repository	Clone	Creates a local working copy with Git history.
Make a change in a repo where you have write access	Branch	Keeps work isolated inside the same repository.
Propose a change without write access	Fork plus PR	Your fork holds your branch; PR proposes changes upstream.
Start a new project from an existing structure	Template repository	Copies files without treating the new repo as the same project history.
Preserve relationship to original project	Fork	Maintains upstream contribution model.
Share unmerged work for review	Push branch and open PR	Lets GitHub show diffs, reviews, and checks.

Feature Selection Matrix

Scenario	GitHub feature to choose	Why
Track a bug, task, or enhancement	Issues	Lightweight work item tracking.
Propose and review code changes	Pull requests	Review, comments, checks, merge workflow.
Organize work across issues and PRs	Projects	Boards/tables/roadmaps with fields and views.
Group work for a release or timebox	Milestones	Tracks progress across linked issues/PRs.
Categorize issues or PRs	Labels	Filtering and triage.
Assign responsibility	Assignees	Identifies who owns the work item.
Ask open-ended questions or run community conversations	Discussions	Better than issues for Q&A and non-task conversations.
Automate builds, tests, or deployments	GitHub Actions	Event-driven workflows.
Store workflow secrets	GitHub Actions secrets	Prevents hard-coding sensitive values.
Store non-sensitive workflow config	Variables	Reusable configuration without treating it as a secret.
Create cloud development environments	Codespaces	Reproducible browser/VS Code development environment.
Publish versioned software deliverables	Releases	Release notes and downloadable assets around a tag.
Publish packages or containers	GitHub Packages	Package registry integration.
Host a static website or documentation	GitHub Pages	Static site hosting from repository content.
Automatically request reviews from owners	CODEOWNERS	Maps paths to responsible reviewers.
Enforce merge rules	Branch protection or repository rulesets	Requires reviews, checks, or other policies.
Find vulnerabilities in dependencies	Dependabot alerts	Uses dependency graph information.
Propose dependency updates	Dependabot updates	Opens PRs for version updates.
Detect committed secrets	Secret scanning	Alerts on exposed credentials/tokens.
Detect code vulnerabilities	Code scanning	Static analysis results in GitHub security views.
Report or coordinate vulnerability disclosure	Security advisories	Private coordination and disclosure workflow.
Search code and metadata	GitHub search	Uses qualifiers such as `repo:`, `org:`, `language:`.

Issues, Projects, Discussions, and Planning

Feature	Best for	Not best for
Issues	Actionable tasks, bugs, enhancements	Long-running open-ended community chat
Discussions	Q&A, announcements, ideas, community conversation	Tracking assigned engineering work
Projects	Visualizing and prioritizing work across items	Storing source code
Milestones	Tracking progress toward a release or goal	General categorization
Labels	Categorizing and filtering	Ownership or scheduling by themselves
Assignees	Showing who is responsible	Categorization
Templates/forms	Standardizing issue or PR input	Replacing triage judgment

High-yield links between planning and code:

A PR can be linked to an issue.
Closing keywords in a merged PR can close linked issues.
Labels help filtering; they do not grant access.
Milestones show progress; they do not enforce deadlines.
Projects can include issues, PRs, draft items, and custom fields.

GitHub Actions Quick Reference

Workflow Anatomy

Term	Meaning
Workflow	Automated process defined in YAML under `.github/workflows/`.
Event	Trigger such as push, pull request, scheduled run, or manual dispatch.
Job	Group of steps that runs on a runner.
Step	Individual command or action in a job.
Action	Reusable unit of automation.
Runner	Machine that executes workflow jobs.
GitHub-hosted runner	Runner managed by GitHub.
Self-hosted runner	Runner you manage in your own environment.
Artifact	File produced by a workflow for later download/use.
Cache	Reused dependencies/build outputs to speed later runs.
Environment	Deployment target with optional protection and secrets.
Secret	Encrypted sensitive value used by workflows.
`GITHUB_TOKEN`	Automatically available token for workflow authentication, with permissions controlled by configuration.

Minimal CI Workflow

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Actions Decision Cues

Need	Use
Run tests on every PR	`on: pull_request`
Run workflow after commits to default branch	`on: push` with branch filter
Manually start workflow	`workflow_dispatch`
Reuse automation from marketplace or another repo	`uses:` action reference
Run shell command	`run:`
Test multiple versions/platforms	Matrix strategy
Protect deployment target	Environments with reviewers/rules
Avoid exposing credentials	Secrets, restricted token permissions, least privilege

Exam trap: GitHub Actions workflow files live in .github/workflows/. A workflow is triggered by events; jobs run on runners; steps run commands or actions.

Identity, Access, and Governance

Account and Organization Model

Entity	Purpose
Personal account	Identity for an individual GitHub user.
Organization	Shared account for teams, repositories, permissions, and collaboration.
Team	Group of organization members used to manage access and review ownership.
Enterprise account	Higher-level structure for managing multiple organizations and policies.
Outside collaborator	User with access to specific repositories but not full organization membership.

Repository Permission Roles

Role	General capability
Read	View and clone repository content.
Triage	Manage issues and pull requests without write access to code.
Write	Push code and manage most collaboration activities.
Maintain	Manage repository without full access to sensitive/admin settings.
Admin	Full repository administration.

Access Control Cues

Requirement	Use
Give a group access to many repositories	Organization team
Grant limited repo-only access to an external person	Outside collaborator
Restrict direct pushes to important branches	Branch protection or rulesets
Require successful CI before merging	Required status checks
Require human review before merging	Required pull request reviews
Require specific path owners to review	`CODEOWNERS`
Centralize policies across organizations	Enterprise-level governance, where applicable
Investigate administrative activity	Audit log, where available

Authentication and Credential Safety

Method / concept	Use	Watch for
Browser sign-in	Interactive GitHub use	Protect with strong authentication.
Two-factor authentication	Adds a second verification factor	Important account security control.
SSH key	Authenticate Git operations over SSH	Protect private key.
HTTPS with token	Authenticate Git operations over HTTPS	Passwords are not the normal Git auth method for GitHub operations.
Personal access token	Script/API/Git authentication with scoped access	Scope narrowly and rotate/revoke when needed.
Fine-grained token	More targeted token permissions	Prefer least privilege when supported by the scenario.
GitHub App	Integration with scoped, installable permissions	Often preferred for app-to-GitHub automation.
OAuth App	User-authorized app access	Acts based on user authorization.
Secret	Encrypted sensitive workflow value	Do not print secrets in logs or commit them.

Credential handling rules to remember:

Never commit passwords, API keys, private keys, or cloud credentials.
Use .gitignore to keep local config and generated secrets out of Git.
If a secret is committed, assume it is exposed: revoke, rotate, and remove it from history if needed.
Store CI/CD credentials as GitHub Actions secrets or environment secrets.
Give tokens only the permissions required for the task.

Security Features

Feature	Detects / manages	Typical scenario
Dependency graph	Project dependencies	Foundation for dependency security features.
Dependabot alerts	Known vulnerable dependencies	“Notify me when a dependency has a vulnerability.”
Dependabot updates	Dependency version update PRs	“Keep dependencies current automatically.”
Code scanning	Potential vulnerabilities in code	Static analysis and security findings.
Secret scanning	Secrets committed to repositories	Prevent credential exposure.
Security advisories	Vulnerability coordination and disclosure	Privately coordinate a fix before public disclosure.
Branch protection / rulesets	Risky changes to important branches	Require review, checks, signed commits, or other rules.
CODEOWNERS	Required or suggested reviewers by path	Ensure knowledgeable review.

High-yield distinction:

Need	Choose
Vulnerable dependency notification	Dependabot alerts
Automated dependency PRs	Dependabot updates
Secret accidentally committed	Secret scanning plus credential rotation
Static code security analysis	Code scanning
Prevent unreviewed change to default branch	Branch protection or rulesets

Markdown and GitHub-Flavored Markdown

Need	Syntax
Heading	`## Section`
Bold	`text`
Italic	`text`
Link	`[label](https://example.com)`
Image	`![alt text](image.png)`
Inline code	`code`
Fenced code block	Triple backticks before and after code
Unordered list	`- item`
Ordered list	`1. item`
Task list	`- [ ] task` and `- [x] done`
Blockquote	`> quoted text`
Table	Pipes and header separators
Mention user/team	`@username` or `@org/team`
Reference issue/PR	`#123`
Close issue from PR	`Fixes #123`, `Closes #123`, or similar closing keyword

Markdown commonly appears in:

README.md
Issues and pull requests
Discussions
Wikis
Release notes
Comments and reviews

Search, Notifications, and Repository Signals

Search Qualifiers

Qualifier	Example	Use
`repo:`	`repo:owner/name test`	Search within a repository.
`org:`	`org:example topic`	Search within an organization.
`user:`	`user:octocat`	Search user-owned content.
`language:`	`language:python`	Filter by programming language.
`path:`	`path:docs`	Filter by path.
`filename:`	`filename:README.md`	Find specific filenames.
`is:issue`	`is:issue is:open`	Search issues.
`is:pr`	`is:pr is:closed`	Search pull requests.
`label:`	`label:bug`	Filter by label.
`assignee:`	`assignee:@me`	Find assigned work.
`author:`	`author:username`	Find items by creator.

Feature	Meaning
Watch	Subscribe to repository notifications.
Star	Bookmark or show interest in a repository.
Fork	Create your own copy of a repository.
Follow	Subscribe to a user’s public activity.
Mention	Notify a user or team using `@`.
Review request	Ask a person or team to review a PR.
Notification inbox	Central place to manage GitHub notifications.

GitHub Pages, Releases, Packages, and Codespaces

Feature	Primary purpose	Choose when
GitHub Pages	Static website hosting	Publish docs, portfolio, project site, simple static content.
Releases	Versioned distribution	Publish release notes, source snapshots, binaries/assets.
Tags	Git references to specific commits	Mark versions or important points in history.
GitHub Packages	Package hosting	Publish packages/containers tied to GitHub workflows and permissions.
Codespaces	Cloud development environment	Need consistent dev setup without local machine configuration.
Dev container config	Defines Codespaces/container environment	Need reproducible tools, extensions, dependencies.

Common Exam Traps

Trap	Correct answer pattern
“I committed, so the code is on GitHub.”	Not until you push to a remote.
“I pushed, so it is merged.”	Push updates a branch; merge integrates into the target branch.
“A PR is only for code review.”	PRs also host discussion, checks, linked issues, and merge decisions.
“Use an issue for every conversation.”	Use Discussions for open-ended Q&A or community conversations.
“Use a fork when I have write access and just need a feature branch.”	Use a branch in the same repo when appropriate.
“Use reset to undo public commits.”	Prefer revert for shared history.
“Labels control permissions.”	Labels categorize; permissions come from roles, teams, and policies.
“Projects store source code.”	Repositories store code; Projects organize work.
“Secrets belong in workflow YAML.”	Store sensitive values in secrets, not in repository files.
“Dependabot, code scanning, and secret scanning do the same thing.”	They address dependencies, code analysis, and credential exposure respectively.
“GitHub Actions job equals workflow.”	Workflow contains one or more jobs; jobs contain steps.
“A release and a tag are identical.”	A release is GitHub metadata/assets around a tag.

Last-Minute Decision Checklist

Before answering a GH-900 scenario question, identify the target:

Version control action? Think Git commands: commit, branch, merge, fetch, pull, push, revert.
Code collaboration? Think pull request, review, checks, branch protection, CODEOWNERS.
Work tracking? Think issues, labels, assignees, milestones, Projects.
Community conversation? Think Discussions, not Issues.
Automation? Think GitHub Actions: workflow, event, job, step, runner, secret.
Security finding? Match the tool: Dependabot, code scanning, secret scanning, security advisory.
Access control? Think organization, team, role, outside collaborator, repository visibility.
Publishing? Think Pages for static sites, Releases for versions/assets, Packages for package artifacts.
Cloud development environment? Think Codespaces and dev containers.
Policy enforcement? Think branch protection, rulesets, required reviews, required checks.

Next Step

Turn the feature-selection tables into flashcards, then practice mixed GH-900 scenarios where you must choose the right GitHub feature, Git command, or collaboration workflow from similar-looking options.

Scenario Guide

Git and Github Basics