GH-900 — GitHub Foundations Quick Review

Quick Review purpose

This Quick Review is for candidates preparing for the GitHub Foundations (GH-900) exam from GitHub. Use it as a fast, structured refresher before working through topic drills, mock exams, and detailed explanations in an IT Mastery question bank.

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.

High-yield mental model

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

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

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.

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.

Public, private, and internal repositories

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

Git workflow essentials

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

Working directory, staging area, repository

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.

Merge conflicts

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

1. Identify conflicted files.
2. Edit the files to keep the correct content.
3. Mark the conflicts as resolved.
4. Commit the resolution.
5. 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

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.

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

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 requests

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

Pull request states and actions

Merge methods

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

Issues, discussions, and pull requests

Decision rule:

• 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.

Labels vs. milestones vs. projects

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.

Documentation files with high exam relevance:

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

Permissions and access control

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

Permission decision rules

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

Authentication and secure access

GitHub supports several ways to authenticate and connect tools.

Security decision rules

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.

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.

GitHub Actions fundamentals

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

Workflow files are stored in:

.github/workflows/

Actions workflow model

Actions vs. other GitHub features

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

CI/CD basics

For GH-900, understand CI/CD conceptually.

Typical CI pattern:

1. Developer opens pull request.
2. GitHub Actions workflow runs tests.
3. Status check reports pass or fail.
4. Branch protection requires passing checks.
5. 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.

Security features on GitHub

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

Security feature decision table

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

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.

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.

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.

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

GitHub Pages, Packages, and Releases

Decision rules:

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.

Open source collaboration

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

Contribution workflow

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

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

Search, navigation, and discovery

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

Useful search concepts

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.

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

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

High-yield “which feature?” table

Common GH-900 traps

Trap 1: Confusing Git actions with GitHub features

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.

Scenario decision practice

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

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?

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?

How to use IT Mastery practice

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

1. 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.

2. 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.

3. 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.

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 Quick Review to choose your weakest GH-900 topic, complete a focused topic drill, and read the detailed explanations before moving to a mixed mock exam.

Continue in IT Mastery

Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official GitHub questions, copied live-exam content, or exam dumps.