GH-900 — GitHub Foundations Cheat Sheet

Last revised: September 28, 2026

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

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

The exam is foundational, so expect questions that test whether you understand how GitHub supports software development, collaboration, automation, security, and project workflows. Many questions are not about memorizing commands; they ask you to choose the best GitHub feature, workflow, permission model, or collaboration pattern for a scenario.

This page is IT Mastery exam-prep support. It is not affiliated with GitHub.

After reviewing the concepts above, move into an IT Mastery question bank in three passes:

Topic drills Start with focused drills for Git basics, repositories, pull requests, Actions, security, and project management. The goal is not speed yet; the goal is to expose weak concepts.
Mixed original practice questions Use mixed sets to practice switching between features. GH-900-style questions often test whether you can choose the right GitHub capability from similar-looking options.
Mock exams with detailed explanations Take timed mock exams only after the main topics feel familiar. Review every explanation, including questions you answered correctly, because the explanation often clarifies why similar distractors are wrong.

Exam Focus

This independent Cheat Sheet 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

Notes and examples

High-yield mental model

GitHub is not just “a place to store code.” It combines:

Area	What to know for GH-900
Git hosting	Repositories, commits, branches, tags, remotes, cloning, pushing, pulling
Collaboration	Issues, pull requests, reviews, discussions, forks, branch protection
Project management	Labels, milestones, assignees, projects, task lists, notifications
Automation	GitHub Actions workflows, events, jobs, runners, marketplace actions
Security	Authentication, permissions, secret scanning, Dependabot, code scanning
Open source	README, LICENSE, CONTRIBUTING, CODE_OF_CONDUCT, SECURITY files
Developer experience	GitHub Codespaces, GitHub Copilot, GitHub Pages, GitHub CLI, integrations

A strong GH-900 candidate can explain which GitHub feature solves which problem and how the pieces fit together in a typical development workflow.

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.

Notes and examples

Git vs. GitHub

Concept	Git	GitHub
What it is	Distributed version control system	Cloud platform built around Git repositories
Primary job	Track file history and changes	Host repositories and support collaboration
Works offline?	Yes, for local commits and history	Mostly online, though local Git work continues offline
Examples	`commit`, `branch`, `merge`, `rebase`, `clone`	Pull requests, issues, Actions, projects, security alerts
Common trap	Thinking Git requires GitHub	Git can be used without GitHub
Another trap	Thinking GitHub replaces Git	GitHub uses Git; it does not replace core Git concepts

Core distinction

Git tracks changes.
GitHub helps people collaborate around those changes.

If a question asks about version history, commits, branches, and merging, think Git. If it asks about reviews, issues, automation, permissions, or hosted collaboration, think GitHub.

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.

Notes and examples

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

Notes and examples

Repository fundamentals

A repository is the central workspace for a project. It usually contains source code, documentation, configuration files, issue and pull request history, security settings, and automation workflows.

Repository item	Purpose
README	Explains what the project is and how to use it
LICENSE	Defines legal permissions for using, modifying, and distributing the project
`.gitignore`	Tells Git which files not to track
Issues	Track bugs, tasks, questions, or enhancements
Pull requests	Propose, discuss, review, and merge changes
Actions workflows	Automate CI/CD or other tasks
Branches	Isolate work before integration
Tags	Mark specific points in history, often versions
Releases	Package and describe versioned software releases

Public, private, and internal repositories

Visibility	Meaning	Common use
Public	Visible to everyone	Open source, public docs, examples
Private	Visible only to selected users or teams	Proprietary code or restricted projects
Internal	Visible within an enterprise context	Shared enterprise code and resources

Common trap: repository visibility controls who can see the repository, but permissions still determine what authorized users can do.

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

Notes and examples

GitHub Flow

GitHub Flow is a lightweight workflow centered on branches and pull requests.

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

GitHub Flow decision points

Question	Best action
Need to start a new feature?	Create a branch
Need feedback before merging?	Open a pull request
Need automated validation?	Use GitHub Actions checks
Need required approval?	Use branch protection or rulesets
Need to keep main stable?	Require reviews and passing checks before merge

Common trap: a pull request is not only a “request to merge.” It is also a place for review, discussion, checks, and documentation of the change.

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

Notes and examples

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

Pull requests

A pull request proposes changes from one branch into another. Pull requests are central to GitHub collaboration.

Pull request feature	Why it matters
Conversation	Discuss proposed changes
Review comments	Comment on specific lines
Required reviewers	Enforce review before merge
Status checks	Show CI/test/security results
Linked issues	Connect code changes to tracked work
Draft pull request	Signal that work is not ready for full review
Merge methods	Control how history is integrated

Pull request states and actions

Situation	Appropriate action
Work is not ready	Open as draft or keep working on branch
Needs review	Request reviewers
Tests fail	Fix commits and push updates
Conflicts exist	Resolve conflicts before merge
Review requires changes	Update code and re-request review
Ready and allowed	Merge using allowed merge method

Merge methods

Merge method	Result	Common reason to use
Merge commit	Preserves full branch history	Keep detailed commit history
Squash merge	Combines branch commits into one commit	Keep main history clean
Rebase merge	Replays commits without a merge commit	Maintain linear history

Common trap: “squash” does not mean the work disappears. It combines multiple commits into a single commit on the target branch.

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 Cheat Sheet

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.

Notes and examples

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.

GitHub Actions fundamentals

GitHub Actions automates workflows such as building, testing, linting, scanning, packaging, releasing, and deploying.

Term	Meaning
Workflow	Automated process defined in YAML
Event	Trigger that starts a workflow
Job	Set of steps executed on a runner
Step	Individual command or action
Action	Reusable automation component
Runner	Machine that executes jobs
Artifact	File produced by a workflow
Secret	Encrypted value used by workflows

Workflow files are stored in:

.github/workflows/

Actions workflow model

Question clue	Concept
“Run tests when code is pushed”	Event trigger such as push
“Run checks on a pull request”	Pull request event
“Use Ubuntu to execute build steps”	Runner
“Reuse a published automation task”	Action
“Split build and test tasks”	Jobs
“Store deployment credential securely”	Secrets
“Save build output”	Artifacts
“Test across versions”	Matrix strategy

Actions vs. other GitHub features

Need	Use
Track a bug	Issue
Review a change	Pull request
Automatically run tests	GitHub Actions
Protect merge quality	Branch protection plus required checks
Store a password for workflow use	Actions secret
Publish package artifacts	GitHub Packages or release artifacts, depending on scenario

Common trap: GitHub Actions is for automation. It is not the same thing as GitHub Projects, which is for planning and tracking work.

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.

Notes and examples

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

Permissions and access control

GitHub access is organized around personal accounts, organizations, teams, repositories, and roles.

Concept	Meaning
Personal account	Identity for an individual user
Organization	Shared account for teams and projects
Team	Group of organization members
Repository role	Permission level for a repository
Enterprise	Higher-level structure for multiple organizations in enterprise use

Permission decision rules

Scenario	Concept to review
A user can view but not push	Repository permission level may be read-only
A team needs access to several repos	Use organization teams
External helper needs limited access	Assign the minimum necessary permission
Sensitive branch needs control	Use branch protection or rulesets
Automation needs access	Use appropriate token, GitHub App, or secret handling

Common trap: authentication proves who you are; authorization controls what you can do.

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.

Notes and examples

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.

Notes and examples

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

Security features on GitHub

GitHub includes multiple security features that help identify and reduce risk.

Feature	Purpose
Dependabot alerts	Identify vulnerable dependencies
Dependabot updates	Propose dependency updates
Secret scanning	Detect committed secrets
Code scanning	Find code vulnerabilities and errors
CodeQL	Semantic code analysis engine used with code scanning
Security advisories	Coordinate vulnerability disclosure and fixes
Private vulnerability reporting	Allows responsible reporting where enabled
Branch protection	Prevent risky changes from merging
Audit logs	Track activity in organization or enterprise contexts

Security feature decision table

Scenario	Best GitHub feature
Dependency has known vulnerability	Dependabot alert
Need automated dependency update PRs	Dependabot updates
Token accidentally committed	Secret scanning
Need static analysis for code flaws	Code scanning
Need maintainers to coordinate a vulnerability fix	Security advisory
Need to require review before merge	Branch protection
Need to see who changed settings	Audit log

Common trap: Dependabot focuses on dependencies. Code scanning focuses on code. Secret scanning focuses on leaked credentials or secrets.

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.

Notes and examples

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.

Notes and examples

GitHub Pages, Packages, and Releases

Feature	Purpose
GitHub Pages	Host static websites from a repository
GitHub Packages	Host and manage packages
Releases	Publish versioned software and release notes
Tags	Mark specific commits, often for versions

Decision rules:

Scenario	Use
Host project documentation website	GitHub Pages
Publish a version with release notes	GitHub Releases
Mark a version in Git history	Git tag
Store package artifacts	GitHub Packages

Common trap: a tag identifies a point in Git history; a release is a GitHub object that can add release notes and assets around a tag.

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.

Notes and examples

Trap 1: Confusing Git actions with GitHub features

Candidate answer	Why it may be wrong
Use GitHub Actions to save file history	Git commits save history
Use issues to merge code	Pull requests merge code
Use GitHub Projects to run tests	GitHub Actions runs automation
Use Dependabot for leaked tokens	Secret scanning detects secrets
Use code scanning for dependency updates	Dependabot handles dependency vulnerability alerts and updates

Trap 2: Confusing visibility with permissions

A private repository limits visibility, but users still need the correct role to read, write, maintain, or administer. A public repository may be visible to everyone, but not everyone can push to it.

Trap 3: Treating pull requests as only a merge button

Pull requests support:

Code review
Discussion
Automated checks
Linked issues
Review approvals
Change history
Merge control

Trap 4: Assuming local commits are already on GitHub

A commit is local until pushed. If the scenario says the developer committed changes but teammates cannot see them, the likely missing step is git push.

Trap 5: Choosing forks when branches are enough

If a developer has write access to the repository, a branch is often enough. Forks are especially useful when the contributor does not have write access or wants an independent copy.

Trap 6: Confusing Actions secrets with repository secrets in code

Secrets should be stored securely using GitHub secret management, not committed into source files, configuration files, or documentation.

Trap 7: Confusing releases and tags

A tag marks a commit. A release is a GitHub feature that uses a tag and can include release notes and assets.

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.

Git workflow essentials

You do not need to be a Git expert for GH-900, but you should understand the basic lifecycle.

Step	Typical command or action	Meaning
Get a repository	`git clone`	Copy a remote repository locally
Inspect changes	`git status`, `git diff`	See what changed
Stage files	`git add`	Choose changes for the next commit
Save snapshot	`git commit`	Record changes in local history
Share changes	`git push`	Send local commits to a remote
Get remote changes	`git pull`	Fetch and integrate changes
Fetch only	`git fetch`	Download remote updates without merging
Create branch	`git branch` or `git switch -c`	Start isolated work
Merge work	`git merge`	Combine branch histories
View history	`git log`	Inspect commits

Notes and examples

Working directory, staging area, repository

Area	What it contains	Candidate mistake
Working directory	Files you are editing	Thinking edited files are automatically committed
Staging area	Selected changes for the next commit	Forgetting to stage changes
Local repository	Local commit history	Thinking local commits are already on GitHub
Remote repository	Hosted repository, often on GitHub	Confusing `commit` with `push`

Decision rule:

Commit saves changes locally.
Push sends commits to GitHub.
Pull brings remote changes down and integrates them.
Fetch brings remote data down without integrating it.

Branches, commits, merges, and conflicts

Branches allow parallel work. A branch is a movable pointer to a commit, not a full copy of the repository.

Concept	Review point
Commit	Snapshot of tracked changes with metadata
Branch	Independent line of development
Default branch	Main integration branch, often named `main`
Merge	Combines changes from one branch into another
Merge conflict	Occurs when Git cannot automatically combine changes
Tag	Named reference to a specific commit, often used for versions

Merge conflicts

A merge conflict means Git needs human judgment. The usual process is:

Identify conflicted files.
Edit the files to keep the correct content.
Mark the conflicts as resolved.
Commit the resolution.
Continue the merge or pull request workflow.

Common trap: a conflict is not an error in GitHub itself. It is Git asking for a decision between incompatible changes.

Forks vs. branches

Use case	Prefer this
You have write access to the repository	Create a branch in the repository
You do not have write access	Fork the repository and open a pull request
You want to contribute to open source	Fork, branch, commit, push, open pull request
You want isolated internal feature work	Branch
You want your own copy under your account	Fork

A fork is a copy of a repository under another account or organization. A branch is a separate line of work inside a repository.

Common trap: forks and branches both support parallel work, but they solve different permission and ownership problems.

Issues, discussions, and pull requests

Feature	Best for	Not best for
Issues	Bugs, tasks, enhancements, work tracking	Long-form community Q&A if Discussions is enabled
Pull requests	Reviewing and merging code changes	General planning with no code changes
Discussions	Questions, ideas, announcements, community conversation	Formal code review
Projects	Planning, tracking, and visualizing work	Replacing Git history

Use an issue to track work.
Use a pull request to propose code changes.
Use a discussion for broader conversation.
Use a project to organize and visualize work across issues and pull requests.

GitHub project management

GitHub includes features that support planning and tracking directly near the code.

Feature	Purpose
Labels	Categorize issues and pull requests
Milestones	Group work toward a target or release
Assignees	Show who is responsible
Projects	Track work using tables, boards, fields, and views
Task lists	Break work into checklist items
Mentions	Notify users or teams
Notifications	Keep users informed about relevant activity

Labels vs. milestones vs. projects

Need	Use
Categorize work by type or priority	Labels
Group work for a release or deadline	Milestones
Visualize and manage work across items	Projects
Assign ownership	Assignees
Track smaller steps in one item	Task lists

Common trap: labels and milestones do not replace project planning views; they add metadata that can help organize planning.

Markdown and documentation

GitHub uses Markdown widely in README files, issues, pull requests, comments, discussions, and wikis.

Markdown element	Example purpose
Headings	Structure documentation
Lists	Steps, requirements, notes
Links	Reference docs, issues, pull requests
Images	Screenshots, diagrams
Code blocks	Show commands or examples
Task lists	Track checklist items
Tables	Compare options

Documentation files with high exam relevance:

File	Purpose
`README.md`	Project overview and usage
`CONTRIBUTING.md`	Contribution guidelines
`CODE_OF_CONDUCT.md`	Community behavior expectations
`LICENSE`	Legal terms for reuse
`SECURITY.md`	Security policy and vulnerability reporting
Issue templates	Standardize issue submissions
Pull request template	Standardize PR descriptions

Common trap: a repository without a license is not automatically “free to use” just because it is public.

Authentication and secure access

GitHub supports several ways to authenticate and connect tools.

Method	Typical use
Username and browser session	Web access
Multi-factor authentication	Stronger account protection
Personal access token	HTTPS Git or API access where token-based auth is needed
Fine-grained token	More limited, specific access
SSH key	Git operations over SSH
GitHub CLI authentication	Command-line GitHub workflows
GitHub App	Integration with controlled permissions
OAuth App	Third-party authorization flow

Notes and examples

Security decision rules

Need	Likely solution
Protect account login	Enable multi-factor authentication
Avoid password use for Git operations	Use SSH key or token-based authentication
Limit automation permissions	Use least privilege permissions
Store workflow secrets	Use GitHub Actions secrets
Avoid exposing credentials	Never commit secrets to repositories

Common trap: a secret stored in code is not protected just because the repository is private. Secrets should be managed through appropriate secret storage and access controls.

Branch protection and repository rules

Branch protection and rulesets help enforce quality and security before changes reach important branches.

Control	What it helps enforce
Require pull request reviews	Human review before merge
Require status checks	Tests or checks must pass
Restrict who can push	Limit direct changes
Require linear history	Avoid merge commits if desired
Require signed commits	Strengthen commit authenticity
Prevent force pushes	Protect branch history
Prevent deletion	Protect critical branches

Common exam pattern: choose branch protection when the scenario says the team wants to prevent unreviewed or failing code from being merged into the default branch.

CI/CD basics

For GH-900, understand CI/CD conceptually.

Term	Meaning
Continuous integration	Frequently integrate and validate code changes
Continuous delivery	Keep software ready to release
Continuous deployment	Automatically deploy validated changes
Build	Compile or package software
Test	Validate behavior or quality
Deploy	Release software to an environment

Typical CI pattern:

Developer opens pull request.
GitHub Actions workflow runs tests.
Status check reports pass or fail.
Branch protection requires passing checks.
Pull request is reviewed and merged.

Common trap: CI/CD is not only deployment. A workflow that runs tests on every pull request is also CI.

GitHub Advanced Security concepts

Some GitHub security capabilities may be discussed as part of the broader GitHub platform. For foundational review, focus on what the features do rather than licensing details.

Capability	Core idea
Secret scanning	Detect secrets in repositories
Code scanning	Analyze source code for security issues
Dependency review	Show dependency changes and risk in pull requests
Dependabot	Alert on and help update vulnerable dependencies

Decision rule: if the question is about identifying a password, token, or key in code, think secret scanning, not code scanning.

GitHub Codespaces

GitHub Codespaces provides cloud-hosted development environments.

Concept	Review point
Codespace	Cloud development environment connected to a repository
Dev container	Configuration for a consistent development environment
Browser-based development	Work without local setup
Standardized onboarding	Reduce “works on my machine” problems
Preconfigured tools	Install dependencies and extensions consistently

Common use cases:

New contributors can start quickly.
Teams can standardize development environments.
Training or workshops can avoid local setup issues.
Developers can work from different devices.

Common trap: Codespaces is a development environment. It is not the same as GitHub Actions, which runs automation workflows.

GitHub Copilot

GitHub Copilot is an AI-powered coding assistant. For a foundations exam, know the basic concept and responsible-use mindset.

Concept	Review point
Code suggestions	Copilot can suggest code as you work
Chat assistance	Copilot can help explain, generate, or refactor code
Developer control	Developers remain responsible for reviewing output
Productivity support	Helps with boilerplate, examples, and exploration

Common trap: Copilot suggestions are not automatically correct, secure, or license-safe. A developer must review, test, and validate code.

Open source collaboration

Open source work on GitHub often combines code, documentation, governance, and community expectations.

File or feature	Why it matters
README	Helps users understand the project
LICENSE	Defines reuse rights
CONTRIBUTING	Explains how to contribute
CODE_OF_CONDUCT	Sets community behavior standards
SECURITY	Explains how to report vulnerabilities
Issues	Track bugs and feature requests
Discussions	Community Q&A and ideas
Pull requests	Propose changes
Forks	Contribute without direct write access

Contribution workflow

Find or create an issue.
Fork the repository if you lack write access.
Create a branch.
Make commits.
Push to your fork.
Open a pull request.
Respond to review comments.
Maintainer merges if accepted.

Common trap: public visibility does not automatically grant write access. Contributors usually propose changes through forks and pull requests.

GitHub provides search and navigation features to find repositories, code, issues, pull requests, users, and discussions.

Need	GitHub capability
Find a repository	Repository search
Find code	Code search
Find open bugs	Issue search and filters
Find pull requests needing review	Pull request filters
Find project activity	Notifications and activity feeds
Find a file quickly	Repository file navigation
Find ownership guidance	CODEOWNERS file, if present

Useful search concepts

Concept	Purpose
Filters	Narrow results by state, author, label, language, etc.
Saved views or project views	Reuse a work-tracking perspective
Mentions	Notify users or teams
Watch settings	Control repository notifications

Common trap: assigning someone to an issue is not the same as mentioning them. Assignment indicates responsibility; mention notifies or references.

CODEOWNERS and review ownership

A CODEOWNERS file can define individuals or teams responsible for parts of a repository.

Scenario	CODEOWNERS helps by
Specific team owns a directory	Automatically suggests or requires reviewers
Critical files need expert review	Maps file paths to owners
Large repo needs review routing	Sends changes to relevant maintainers

Common trap: CODEOWNERS identifies ownership and can support review workflows, but branch protection or rules must enforce required review where needed.

Notifications and collaboration signals

Signal	Meaning
Watching	Subscribe to repository activity
Starring	Bookmark or show interest
Forking	Create a copy under your account
Mentioning	Notify a user or team
Assigning	Indicate responsibility
Requesting review	Ask for pull request review
Subscribing	Follow a specific issue or pull request

Common trap: starring a repository does not give access, create a copy, or subscribe you to every workflow notification.

High-yield “which feature?” table

If the question says…	Think…
“Track a bug or enhancement”	Issue
“Discuss a proposed code change”	Pull request
“Require approval before merge”	Branch protection / rulesets
“Run tests automatically”	GitHub Actions
“Detect leaked credentials”	Secret scanning
“Find vulnerable dependencies”	Dependabot alerts
“Create dependency update PRs”	Dependabot updates
“Analyze code for vulnerabilities”	Code scanning
“Host a static site”	GitHub Pages
“Develop in a browser environment”	Codespaces
“Publish version notes and binaries”	Releases
“Mark a version in Git history”	Tags
“Organize work visually”	Projects
“Categorize issues”	Labels
“Group work for a release”	Milestones
“Give a team repository access”	Organization teams
“Contribute without write access”	Fork and pull request
“Standardize issue creation”	Issue templates
“Standardize PR descriptions”	Pull request template
“Route reviews by file path”	CODEOWNERS

Scenario decision practice

Use this section like a mini topic drill before moving into original practice questions.

Scenario	Best answer	Why
A team wants tests to run whenever a PR is opened	GitHub Actions	PR events can trigger workflows
A maintainer wants to prevent direct pushes to `main`	Branch protection or rulesets	Enforces merge requirements
A contributor lacks write access but wants to propose a fix	Fork and open PR	Standard open source contribution model
A team wants to track bugs and assign owners	Issues	Issues are for work tracking
A project needs release notes and downloadable assets	GitHub Releases	Releases package version information
A team wants a consistent cloud dev environment	Codespaces	Provides hosted development environments
A token is accidentally committed	Secret scanning	Detects exposed secrets
A dependency has a known vulnerability	Dependabot alert	Identifies vulnerable dependencies
A repository needs contribution instructions	CONTRIBUTING file	Guides contributors
A project needs legal reuse terms	LICENSE file	Defines usage rights
A team wants to route frontend file changes to frontend reviewers	CODEOWNERS	Maps paths to owners

Review checklist before question-bank practice

Use this checklist to identify weak spots before attempting a mock exam.

Git and repository basics

Can you explain Git vs. GitHub?
Can you distinguish clone, commit, push, pull, and fetch?
Can you explain branches, merges, conflicts, tags, and releases?
Can you describe what .gitignore does?
Can you explain local vs. remote repositories?

Notes and examples

Collaboration

Can you explain the purpose of issues, pull requests, discussions, and projects?
Can you choose between a fork and a branch?
Can you describe GitHub Flow?
Can you explain pull request review and status checks?
Can you identify when to use labels, milestones, assignees, and project views?

Automation

Can you define workflow, event, job, step, action, and runner?
Can you identify when GitHub Actions is the right answer?
Can you explain how CI checks connect to pull requests?
Can you distinguish artifacts, secrets, and runners?

Security and administration

Can you distinguish authentication from authorization?
Can you explain MFA, tokens, SSH keys, and secrets at a high level?
Can you match secret scanning, code scanning, and Dependabot to scenarios?
Can you explain branch protection and required checks?
Can you describe teams, organizations, and repository permissions?

Community and productivity

Can you explain README, LICENSE, CONTRIBUTING, CODE_OF_CONDUCT, and SECURITY files?
Can you describe Codespaces, Copilot, Pages, Packages, and Releases?
Can you identify common open source contribution steps?
Can you explain notifications, mentions, stars, watchers, and forks?

Final quick pass

Before your next practice set, remember these anchors:

Git tracks changes; GitHub enables collaboration around them.
Issues track work; pull requests review and merge changes.
Actions automate workflows; Projects organize work.
Dependabot handles dependency risk; secret scanning finds exposed secrets; code scanning analyzes code.
Branches isolate work; forks support independent copies and external contributions.
Branch protection helps enforce review and quality gates.
README explains, LICENSE permits, CONTRIBUTING guides, SECURITY reports.
Codespaces is a cloud development environment; Actions is automation.
Tags mark versions; Releases publish version information and assets.

Next step: use this Cheat Sheet to choose your weakest GH-900 topic, complete a focused topic drill, and read the detailed explanations before moving to a mixed mock exam.

Put the review into practice

Study Plan

GH-900 — GitHub Foundations Cheat Sheet

Exam Focus

Core Mental Model

High-yield mental model

Git vs. GitHub: Fast Distinctions

Git vs. GitHub

Core distinction

Git Command Quick Sheet

Daily Workflow Commands

Safe Undo and History Commands

GitHub Repository Reference

Repository Visibility

Common Repository Files

Repository fundamentals

Public, private, and internal repositories

GitHub Flow

GitHub Flow

GitHub Flow decision points

Pull Request Essentials

Merge Method Selection

Pull requests

Pull request states and actions

Merge methods

Branch, Fork, Clone, and Template Decisions

Feature Selection Matrix

Issues, Projects, Discussions, and Planning

GitHub Actions Cheat Sheet

Workflow Anatomy

Minimal CI Workflow

Actions Decision Cues

GitHub Actions fundamentals

Actions workflow model

Actions vs. other GitHub features

Identity, Access, and Governance

Account and Organization Model

Repository Permission Roles

Access Control Cues

Permissions and access control

Permission decision rules

Authentication and Credential Safety

Security Features

Security features on GitHub

Security feature decision table

Markdown and GitHub-Flavored Markdown

Search, Notifications, and Repository Signals

Search Qualifiers

Repository Social and Notification Features

GitHub Pages, Releases, Packages, and Codespaces

GitHub Pages, Packages, and Releases

Common Exam Traps

Trap 1: Confusing Git actions with GitHub features

Trap 2: Confusing visibility with permissions

Trap 3: Treating pull requests as only a merge button

Trap 4: Assuming local commits are already on GitHub

Trap 5: Choosing forks when branches are enough

Trap 6: Confusing Actions secrets with repository secrets in code

Trap 7: Confusing releases and tags

Last-Minute Decision Checklist

Git workflow essentials

Working directory, staging area, repository

Branches, commits, merges, and conflicts

Merge conflicts

Forks vs. branches

Issues, discussions, and pull requests

GitHub project management

Labels vs. milestones vs. projects

Markdown and documentation

Authentication and secure access

Security decision rules

Branch protection and repository rules

CI/CD basics

GitHub Advanced Security concepts

GitHub Codespaces

GitHub Copilot

Open source collaboration

Contribution workflow

Search, navigation, and discovery

Useful search concepts

CODEOWNERS and review ownership

Notifications and collaboration signals