GH-900 GitHub Foundations: A Practical 2026 Guide

What active Exam GH-900 measures

GitHub Foundations is designed for developers, non-developers, and any GitHub user who wants stronger foundational proficiency. The current study guide lists skills as of January 2026 and states that the exam changed significantly that month. The scope now includes core Git and GitHub concepts, repository maintenance, issue and pull-request collaboration, GitHub Actions, current Copilot concepts, Codespaces, github.dev, Projects, account security, organization administration, and community participation.

This breadth makes GH-900 practical. You do not need advanced programming, but you should understand how work moves. A repository contains files and history. A branch isolates change. A commit records a focused snapshot. A pull request proposes that change for conversation, checks, review, and merge. Issues, Discussions, Projects, Actions, Codespaces, Pages, permissions, and community files add planning, automation, development, publishing, governance, and participation around the repository.

The largest domain is Git and GitHub basics, but no domain exists alone. Branch protection depends on pull requests and Actions status checks. Projects organize issues and pull requests. Codespaces starts from a repository and branch. Open-source contribution uses community files, forks, branches, commits, and pull requests. Use the five-phase GH-900 roadmap to connect the concepts.

Domain 1: understand Git and GitHub basics

Version control, Git, and GitHub

Version control records a project's history so people can compare changes, restore earlier versions, attribute decisions, and work in parallel. Git is a distributed version control system. Each clone can contain the files and history, which supports local work without a constant connection. GitHub hosts Git repositories and adds issues, pull requests, review, automation, security, planning, documentation, and community.

A repository contains project files and revision history. A commit is a recorded snapshot of staged changes with metadata and a message. A branch is a parallel line of development. A remote is a repository location such as GitHub. Cloning creates a local repository copy; fetching retrieves remote information; pulling integrates remote changes into the current work; pushing sends local commits to a remote branch; merging combines lines of development.

Understand the distinction between the working tree, staging area, local repository, and remote. A file can be untracked, modified, staged, or committed. The two-step stage-and-commit process lets a contributor choose exactly what enters a snapshot. Focused commits and meaningful messages make history easier to understand, review, revert, and troubleshoot.

Accounts, organizations, GitHub Flow, Markdown, Desktop, and Mobile

Each person should use an individual personal account. Organizations provide shared ownership of repositories, team-based access, settings, and policy. Enterprise accounts can coordinate multiple organizations and enterprise-level capabilities. Plans affect features, but credentials must never be shared simply to avoid assigning a role.

GitHub Flow is a lightweight branch-based workflow: synchronize the default branch, create a descriptive branch, make and commit focused changes, push the branch, open a pull request, discuss and review, satisfy checks, merge, and delete the completed branch. Deployments can be attached according to the team's process. The important principle is that proposed changes remain isolated and reviewable until accepted.

GitHub Flavored Markdown structures collaboration through headings, emphasis, links, lists, tables, task lists, code blocks, mentions, issue references, and accessible images. Markdown improves a README, issue, pull request, discussion, release, or project update; it does not grant access or execute a workflow.

GitHub Desktop provides a graphical local workflow for cloning, branching, committing, comparing, merging, and synchronizing. GitHub Mobile supports notifications, issues, pull requests, reviews, and collaboration away from a desktop. Both use the same repository permissions as other clients.

Domain 2: work with GitHub repositories

A repository is GitHub's central project unit. It stores files and history and can host collaborators, issues, pull requests, Discussions, Projects, Actions, releases, Wikis, Pages, security features, and documentation. Repositories can be public or private. Internal visibility is available in eligible enterprise-owned organizations. Visibility affects who can view content and can affect forks, Pages, security, and collaboration, so changes deserve careful review.

Healthy repositories explain themselves. README introduces purpose and use. LICENSE states reuse terms. CONTRIBUTING describes the contribution process. CODE_OF_CONDUCT establishes community behavior. SECURITY explains how to report vulnerabilities. SUPPORT directs help requests. CODEOWNERS identifies review responsibility for matching paths. Issue forms and pull request templates collect consistent context.

Template repositories create independent repositories from reusable starter files and structure. Forks create related repository copies commonly used to contribute to an upstream project. Clones create local copies. A star saves a repository and can signal interest but grants no permission and creates no editable copy. Watching controls notifications. Topics and descriptions improve discoverability.

Repository Insights provides permission-dependent views such as activity, traffic, contributors, commits, network relationships, community health, and dependencies. Metrics provide context, not automatic performance judgments. Good maintenance includes ownership, current documentation, focused changes, review, automation, issue hygiene, security guidance, archived inactive work, and careful dependency updates.

Domain 3: collaborate using GitHub

Choose collaboration surfaces by purpose. Issues track actionable defects, tasks, and requests. Pull requests propose file changes and bring together description, conversation, commits, checks, changed files, review findings, and merge status. Discussions support open-ended questions, ideas, announcements, and community conversation. Linking these surfaces preserves context without making them interchangeable.

Closing keywords such as “Closes #42” can link a pull request to an issue and close the issue when the pull request merges into the default branch. Labels categorize work, assignees identify responsibility, milestones group work toward a target, templates improve submissions, and filters help users find relevant items. A draft pull request shares work in progress without making it mergeable or formally requesting code-owner review.

Reviewers should inspect intent, Files changed, commits, and checks; ask questions; add line comments; request changes or approve; and resolve conversations only when the result is visible. The merge strategy—merge commit, squash, or rebase—affects history and should match repository policy. Conflicts must be resolved with an understanding of both lines of work.

Notifications preserve awareness only when managed. Configure watching levels, thread subscriptions, routing, inbox filters, and unsubscription. Mention only people who need to act. Gists share snippets, Wikis provide repository-associated documentation, and Pages publishes static websites. None is a secure place for secrets.

Domain 4: apply modern development practices

GitHub Actions

GitHub Actions automates repository and software-development workflows. An event such as a push, pull request, issue, schedule, or manual dispatch triggers a workflow. A workflow is a YAML file in the repository's workflow directory. It contains jobs. Each job runs on a runner and contains ordered steps. A step runs a command or reusable action. Jobs can depend on one another or run in parallel.

Common uses include continuous integration, tests, builds, releases, deployments, labeling, project automation, and scheduled maintenance. GitHub-hosted runners provide fresh environments for jobs; self-hosted runners require the organization to secure and operate them. Workflows should declare minimum permissions, protect secrets, review third-party actions, and treat untrusted pull requests carefully.

GitHub Copilot

GitHub Copilot can suggest, explain, and help change code or text through current product surfaces. The January 2026 GH-900 blueprint includes Copilot agents, Agent Mode, and multi-model support, along with differences between individual, Business, and Enterprise plans. Capabilities change rapidly; understand purpose and governance instead of memorizing a volatile feature matrix.

Copilot output is proposed work. Users remain responsible for understanding, reviewing, testing, securing, and using it according to organizational and licensing policy. AI assistance does not bypass branch protection, required review, status checks, intellectual-property considerations, or secure-development responsibility.

Codespaces and github.dev

GitHub Codespaces provides a cloud-hosted development environment. A codespace runs in a container on hosted compute and can be opened in a browser, Visual Studio Code, or supported clients. A repository can include dev-container configuration that defines tools, runtimes, extensions, and settings as code, producing a more repeatable environment.

github.dev is a lightweight browser editor suitable for navigation and quick edits. It does not provide the same hosted terminal, runtime, debugging, port forwarding, or compute. Use Codespaces when work must execute; use github.dev when a fast web edit is enough. Codespaces also introduces lifecycle, storage, compute, ownership, quota, billing, stop, and deletion considerations.

Domain 5: manage projects with GitHub

GitHub Projects is an adaptable planning layer that integrates with issues and pull requests. A project can present the same items through table, board, and roadmap layouts. Saved views filter, sort, slice, and group work for different questions. A team can use one dataset to see the backlog, current flow, iteration, or release timeline instead of duplicating items across unrelated boards.

Built-in and custom fields can represent assignee, label, milestone, priority, size, date, iteration, text, or other metadata. Built-in workflows can set status, auto-add matching work, or archive completed items. Project insights create charts from project items. Status updates communicate whether work is on track or at risk. Templates can preserve views, fields, guidance, workflows, and insights for reuse.

Labels and milestones remain repository metadata; project fields add flexible planning metadata. Saved replies speed respectful repeated communication but should not replace understanding. Insights should support planning and learning rather than simplistic individual ranking.

Domain 6: understand privacy, security, and administration

Protect personal accounts with two-factor authentication, passkeys where appropriate, and securely stored recovery methods. Passkeys use public-key credentials and can provide phishing-resistant authentication. Never share accounts, passwords, recovery codes, personal access tokens, SSH private keys, or Actions secrets. GitHub Support cannot simply restore every account if all 2FA recovery methods are lost.

Apply least privilege. Organization repositories can use graduated roles such as Read, Triage, Write, Maintain, and Admin. Teams make recurring access easier to manage. Organization owners and enterprise administrators have broader authority and should be limited. Review outside collaborators, inactive users, app access, deploy keys, tokens, and team membership.

Protected branches and rulesets can require pull requests, reviews, status checks, signed commits, linear history, or other conditions before important refs change. Review bypass actors and current plan behavior. A required Actions check should produce relevant evidence; a permanently skipped check is not protection.

Repository visibility is a security decision. Public content is accessible on the internet. Private content is restricted to authorized users, though authorized users can still expose data. Internal visibility has enterprise-specific behavior. Use strong access control, secret scanning, push protection, dependency features, code scanning where appropriate, a security policy, and regular reviews according to current availability.

Enterprise Managed Users lets an enterprise control account provisioning, authentication, profile data, membership, and access through an identity provider. Managed users have collaboration restrictions, especially around public activity and work outside the enterprise. Organization-wide Copilot policy management allows administrators to govern eligible Copilot capabilities; exact plan and policy behavior should be verified in current docs.

Domain 7: explore the GitHub community

Open source gives people the ability to inspect, use, improve, and collaborate under the project's license. Before contributing, read README, LICENSE, CONTRIBUTING, CODE_OF_CONDUCT, and SECURITY. Look for maintained projects, suitable issues, “good first issue” or “help wanted” labels, and contribution instructions. Non-code work—documentation, design, testing, issue reproduction, translation, and community support—can be valuable.

The fork-and-pull model lets a contributor create a fork, work on a branch, and propose changes to the upstream repository without prior write access. The shared-repository model gives collaborators access to one repository and still uses branches and pull requests. Templates are for independent scaffolding, not upstream contribution.

GitHub Sponsors can support eligible open-source contributors and organizations. Following people or organizations surfaces public activity. Marketplace helps users find apps and actions, but using third-party automation still requires source, permission, update, security, and trust review. InnerSource applies open-source collaboration practices inside an organization, improving discoverability and contribution while retaining organizational access boundaries.

Two beginner projects that cover the blueprint

The first GH-900 project creates a synthetic open-source-style repository. You write community health files, configure issue and pull request templates, use labels and a milestone, create a branch and focused commits, link a pull request to an issue, add an Actions validation check, protect the default branch, complete review and merge, simulate a fork contribution, inspect Insights, and clean up temporary access.

The second project creates a secure planning and publishing workflow. You enable account security, apply least privilege, create issues and a GitHub Project, build table, board, and roadmap views, configure a dev container and Codespace, compare github.dev, build a small static site, run pull-request checks with Actions, require review and checks, publish through GitHub Pages, inspect project insights, and remove temporary resources.

Both projects use invented content and disposable repositories. Never put real credentials, personal data, employer source, customer records, private vulnerabilities, or protected exam material into a public lab. Treat Pages source and workflow logs as potentially visible. Review usage and delete Codespaces, artifacts, collaborators, and test resources that should not remain.

A six-to-eight-week GH-900 study plan

1. Week 1: Learn version control, Git versus GitHub, repository, commit, branch, remote, clone, pull, push, merge, accounts, and GitHub Flow.
2. Week 2: Practice Markdown, GitHub Desktop or the command line, repository creation, files, visibility, templates, forks, community files, stars, watchers, and Insights.
3. Week 3: Use issues, forms, labels, assignees, milestones, Discussions, pull requests, reviews, closing keywords, notifications, Gists, Wikis, and Pages.
4. Week 4: Learn Actions events, workflows, jobs, steps, actions, runners, checks, and permissions. Review Copilot plans, agents, Agent Mode, multi-model concepts, and validation responsibility.
5. Week 5: Practice Codespaces, dev containers, github.dev, lifecycle, quota, and cost. Build a Project with fields, iterations, table, board, roadmap, workflows, status, and insights.
6. Week 6: Practice 2FA, passkeys, recovery, roles, teams, visibility, protected branches, rulesets, EMUs, and organization-wide policy concepts.
7. Week 7: Practice forks, open-source contribution, Sponsors, following, discovery, Marketplace review, and InnerSource. Complete the collaborative repository project.
8. Week 8: Complete the Projects, Pages, Actions, and Codespaces lab; answer original GH-900 questions; review GH-900 flashcards; and explain every distractor.

Common GH-900 preparation mistakes

• Calling Git and GitHub the same thing. Git is distributed version control; GitHub hosts repositories and adds collaboration and platform services.
• Confusing a fork, clone, and template. A fork is related to upstream, a clone is local, and a template creates an independent starter repository.
• Committing directly to the default branch. Use a branch and pull request when review and isolation matter.
• Using issues for every conversation. Issues track actionable work; Discussions suit broad questions and ideas.
• Thinking a pull request is a download. It is a proposal to merge changes between branches.
• Thinking a star grants access. A star saves a repository and signals interest; it grants no permission.
• Using github.dev when compute is required. Use Codespaces for a hosted terminal and runtime.
• Treating Copilot output as automatically correct. Review, test, secure, and follow policy.
• Giving Admin for convenience. Assign the minimum role needed and use teams for recurring access.
• Publishing secrets through Pages or Actions. Keep credentials out of source, logs, artifacts, and static output.

Certification and career expectations

GH-900 can structure foundational fluency that supports development, documentation, project coordination, product operations, DevOps, security, support, data, and open-source work. It cannot guarantee an exam pass, job, promotion, salary, contribution acceptance, or project success. Strong evidence includes a healthy repository, readable Markdown, focused commits, linked issues and pull requests, review responses, a protected default branch, a passing workflow, a reusable Codespaces environment, a useful Project, a safe Pages site, and documented cleanup.

Use the PrepKloud jobs explorer to compare this evidence with role descriptions. Continue through the PrepKloud blog for GitHub Actions, secure development, platform engineering, AI-assisted development, and career guidance. Describe your own contribution precisely and do not present synthetic collaboration as production experience.

Official sources

• Study guide for Exam GH-900: GitHub Foundations
• About Git
• GitHub Flow
• About repositories
• Pull requests
• GitHub Issues documentation
• Understanding GitHub Actions
• Plans for GitHub Copilot
• What are GitHub Codespaces?
• About GitHub Projects
• About two-factor authentication
• Finding ways to contribute to open source

Continue your GH-900 preparation

• GH-900 five-phase roadmap
• GH-900 original practice questions
• GH-900 flashcards
• GH-900 beginner projects
• Technology jobs explorer
• PrepKloud editorial policy

Frequently asked questions