Study notes. Based on Microsoft Learn study guide (learn.microsoft.com) and GitHub Docs (docs.github.com) as of July/August 2026.
Exam at a Glance (Microsoft Learn, July 2026)
| Fact | Detail |
|---|---|
| Exam code / name | GH-900 – GitHub Foundations |
| Level | Beginner |
| Duration | 100 minutes, proctored |
| Passing score | 700 out of 1000 |
| Delivery | Pearson VUE (online proctored or test center) |
| Languages | English, Spanish, Portuguese (Brazil), Korean, Japanese |
| Validity | 2 years |
Official Domains & Weightings (Skills at a glance, as of January 2026)
| # | Domain | Official Weight |
|---|---|---|
| 1 | Understand Git and GitHub basics | 25–30% |
| 2 | Work with GitHub repositories | 10–15% |
| 3 | Collaborate using GitHub | 10–15% |
| 4 | Apply modern development practices | 10–15% |
| 5 | Manage projects with GitHub | 5–10% |
| 6 | Understand privacy, security, and administration | 10–15% |
| 7 | Explore the GitHub community | 5–10% |
Domain 1 – Understand Git and GitHub Basics (25–30%)
1.1 Version control fundamentals
- Git is a distributed version control system (DVCS). Every clone contains the full project history – this is what “distributed” means, as opposed to older centralized systems like SVN, where only the server holds full history.
- Commit – an immutable snapshot of the repository at a point in time. Each commit has a unique hash identifying its exact content and history.
- Branch – a lightweight, movable pointer to a line of commits (not a full copy of the repo).
- Remote – a reference to another copy of the repository (commonly on GitHub); the conventional default name is origin.
- Fork – a copy of a repo under your own account. Clone – a local copy of any repo you have access to, forked or not.
- Why version control matters: it tracks every change, lets multiple people work in parallel without overwriting each other, and lets you revert to any prior state.
Core Git commands to know
| Command | Purpose |
|---|---|
| git init | Start tracking a new repository in the current folder |
| git status | Show the state of tracked/untracked/staged files |
| git help | Get usage/help documentation for Git |
| git clone <url> | Copy a remote repo locally, including its full history |
| git add | Stage changes for the next commit |
| git commit | Record staged changes as a new snapshot |
| git push / git pull / git fetch | Send/retrieve commits to or from a remote; fetch alone does not merge |
| git merge | Combine changes from one branch into another |
| git branch / git checkout | List/create branches; switch between them |
| git stash | Temporarily shelve uncommitted changes |
| git log | Show commit history |
GitHub Flow
Create a branch → Add commits → Open a pull request → Discuss and review → (Deploy) → Merge.
Git vs. GitHub
Git is a distributed version control system that runs locally on your machine. GitHub is a cloud platform that hosts Git repositories and layers collaboration features (issues, pull requests, project management, CI/CD, etc.) on top of Git.
1.2 GitHub accounts, organizations, and enterprise
| Account type | What it’s for |
|---|---|
| Personal account | An individual. Free plan: unlimited public and private repos; private repos on Free get 2,000 Actions minutes/month and 500 MB of Packages storage (public repos have unlimited Actions minutes). |
| Organization account | A shared account for multiple people/teams. Supports role-based permissions and teams; paid tiers add SSO and audit logs. |
| Enterprise account | Ties together multiple organizations for centralized policy and billing management, and enables InnerSource across those orgs. It has its own handle, like a user or org account. |
- GitHub Desktop is a standalone GUI app (not a browser tool, not a CLI) for common Git tasks, available on Windows and macOS.
- GitHub Mobile lets you review, merge, comment on issues/PRs, and manage notifications from a phone – it is not a full code-editing environment.
1.3 Markdown for issues and pull requests
Markdown supports headings, bold/italic, lists, links, images, tables, task lists, code blocks, and @mentions / #issue references. Syntax on the left, how it renders on the right.
Text formatting
| Syntax | Renders as |
|---|---|
| **bold** or __bold__ | bold |
| *italic* or _italic_ | italic |
| ***bold italic*** | bold italic |
| ~~strikethrough~~ | |
| `inline code` | inline code |
Headings
| Syntax | Renders as |
|---|---|
| # header 1 | header 1 |
| ## header 2 | header 2 |
| ### header 3 | header 3 |
| #### header 4 | header 4 |
Lists
| Syntax | Renders as |
|---|---|
| – item 1 – item 2 (- , * , and + all work the same way) |
|
| 1. item 1 2. item 2 |
|
| – [ ] unchecked item – [x] checked item |
unchecked item
checked item
|
Links, images & quotes
| Syntax | Renders as |
|---|---|
| [link text](https://example.com/) | link text |
|  | 🖼️ renders the image, “alt text” as fallback |
| > this is a quote | this is a quote |
Code & comments
| Syntax | Renders as |
|---|---|
| “` code block “` | code block |
| <!– this is a comment –> | invisible in the rendered view |
Task lists in an issue or PR body render as checkboxes; checking them off in the rendered view edits the underlying text automatically.
📄 GitHub Docs – Basic writing and formatting syntax
1.4 User profile
- Shown by default: bio, profile photo, pinned repositories, public repositories, contribution graph, achievements/badges.
- Not shown by default: private repos, SSH keys, email/password (these are account settings, not public profile information).
- A profile README is created via a public repository named exactly the same as your username, containing a README.md – it then renders at the top of your profile page.
- Achievements are badges (e.g., Pull Shark, Galaxy Brain, YOLO, Quickdraw) earned for specific GitHub activity milestones.
Domain 2 – Work with GitHub Repositories (10–15%)
2.1 Repository structure and key files
| File | Purpose |
|---|---|
| README.md | Landing page/overview, rendered on the repo home page |
| LICENSE | Legal terms for use and reuse of the code |
| CONTRIBUTING.md | Contribution guidelines and expectations |
| CODEOWNERS | Auto-requests specific users/teams as reviewers for matched file paths – uses the same glob syntax as .gitignore |
| SECURITY.md | Vulnerability reporting instructions (renders as the repo’s Security Policy) |
| .gitignore | Tells Git which files/patterns to exclude from tracking – a client-side convention, not a server-enforced control |
| Issue/PR templates | .github/ISSUE_TEMPLATE/ and PULL_REQUEST_TEMPLATE.md – predefined structures for new issues/PRs |
2.2 Repository visibility
| Visibility | Who can see it |
|---|---|
| Public | Anyone on the internet |
| Private | Only you and people/teams you explicitly grant access to |
| Internal | All members of the enterprise – only exists on GitHub Enterprise Cloud/Server, not on personal Free/Pro/Team plans |
2.3 Creating and organizing repositories
- Template repositories: mark a repo as a template in Settings; others click “Use this template” to generate a new repo with the same file/folder structure but no shared commit history.
- Adding a file on GitHub.com: Add file → Create new file (or upload) → type content → commit directly to the default branch, or commit to a new branch and start a pull request (the web UI offers this choice at commit time).
- Branches organize parallel work; the default branch (commonly main) is what’s checked out by default and used as the base for most PRs.
2.4 Repository Insights, metrics, and dependency visibility
- Pulse – a summary of recent activity in the repo.
- Contributors – a graph of contributions over time.
- Traffic – views and clones; only visible to people with push access.
- Commits, Code frequency, Dependency graph, Network, Forks – additional insight graphs.
- Community Standards checklist – tracks whether the repo has a README, LICENSE, CONTRIBUTING file, CODE_OF_CONDUCT, issue templates, and similar health files.
- Dependency insights / dependency graph – shows the packages a repository depends on and (via Dependabot) flags known vulnerabilities in them. This feeds directly into Dependabot alerts (see Domain 6).
- Stars – bookmarks/tracks a repo, visible on your Stars page; also functions as a lightweight popularity signal.
- Feature previews – GitHub periodically rolls out opt-in features (found under your account’s Feature preview settings) before they become generally available. The exam guide notes questions are mostly about GA features, but may reference commonly used preview features.
Domain 3 – Collaborate Using GitHub (10–15%)
3.1 Issues
- Anyone who can view the repo can open an issue (if issues are enabled, and for public repos, generally anyone can open one).
- Only users with Triage/Write access or higher can: assign an issue, add it to a project, associate a milestone, or apply a label.
- Issues can be created from: a repo, a task-list item, a project note, a comment in an issue/PR, a specific line of code, or via a URL query string (?title=…&body=…).
- Issue forms (.yml templates) provide structured fields – dropdowns, checkboxes, required fields – a more structured alternative to a plain Markdown template.
- Convention: comment “Duplicate of #<number>” to mark a duplicate (a UI-recognized convention, not a hard mechanical rule).
Search qualifiers (memorize the syntax)
| Qualifier | Filters by |
|---|---|
| is:issue / is:pr | Item type |
| is:open / is:closed | State |
| label:name | Label |
| org:name / repo:owner/name | Scope to an org or a single repo |
| mentions:username | Where a user is @mentioned (title, body, or any comment) |
| assignee:username / author:username | Assignee or author |
| reason:mention | Filters your notifications inbox to items where you were mentioned |
💡 Example: org:Fruit is:Orange label:VitC “error” – combines org, type, label, and text search in one query typed directly into the search bar.
3.2 Pull requests
- PR tabs: Conversation, Commits, Checks, Files changed.
- You can keep committing to the compare/head branch after opening a PR – new commits appear automatically.
- Draft pull requests signal a PR isn’t ready for review yet; convert to “Ready for review” when it is.
Merge methods (know all three)
| Method | Result |
|---|---|
| Merge commit | All commits plus a new merge commit are added to the base branch |
| Squash and merge | All commits are combined into a single commit |
| Rebase and merge | Commits are replayed individually onto the base branch; no merge commit is created |
Linking pull requests to issues
| Mechanism | Effect |
|---|---|
| Mention #123 in a description/comment | Creates a link only – does not auto-close the issue |
| Closing keyword (Closes/Fixes/Resolves #123) | Auto-closes the issue when the PR merges, if used in the PR description or a commit on the default branch |
| Manual link via the “Development” sidebar section | Up to 10 linked issues per PR; requires write access; issue and PR must be in the same repository |
💡 If you only have read access to a repo: Fork → Clone → Commit → Push to your fork → Open a PR back to the original repo.
Code review etiquette
- Best practice: fix trivial typos inline yourself during review, comment on anything needing discussion, and use “Request changes” rather than an outright reject/close.
- Reviewing actions available: Comment, Approve, Request changes.
3.3 Discussions, Wikis, Gists, and GitHub Pages
| Feature | Best for |
|---|---|
| Issues | Actionable, trackable work items tied to a repo (bugs, tasks) |
| Discussions | Open-ended conversation, Q&A, announcements – not tied to a specific code change |
| Wiki | Long-form, structured documentation, edited via the web UI, Markdown-supported |
| Gist | Sharing a snippet of code or a small file (public or secret); each Gist is its own mini Git repo |
| GitHub Pages | Hosting a static website (HTML/CSS/JS, optionally built via Jekyll or GitHub Actions) directly from a repository |
- Wiki visibility rule: on a private repo, the Wiki is visible to anyone with Read access (not restricted to Write access). On a public repo, the wiki is public by default, just like the code.
- GitHub Pages: publishes from a branch (e.g., main or a gh-pages branch) or a /docs folder, or via a GitHub Actions workflow; available free on public repos (Free plan) and on public + private repos on paid plans. It serves static content only – no server-side languages like PHP, Ruby, or Python.
3.4 Notifications and staying informed
- Watch a repository (all activity) or customize watching (only participating & mentions, or ignore).
- Follow a user to see their public activity in your feed/dashboard – this is different from “subscribing,” which is not a GitHub feature.
- Filter your notifications inbox, e.g., reason:mention, to show only items where you’re mentioned.
- Saved replies: a reusable canned comment (e.g., “LGTM, approved!”) configured under personal Settings → Saved replies, insertable into any comment box to avoid retyping repetitive responses.
3.5 Outside collaborators vs. organization members
| Organization member | Outside collaborator | |
|---|---|---|
| Subject to org base permissions | Yes | No |
| Can be required to enable 2FA by org policy | Yes | No |
| Can be given Admin on a specific repo | Yes | Yes, but only per-repo, never org-wide |
| Scope of access | Org-wide (per default permission) | Only the specific repo(s) granted |
Domain 4 – Apply Modern Development Practices (10–15%)
4.1 GitHub Copilot
- Core function: an AI pair programmer giving inline code suggestions as you type, plus Copilot Chat, code explanations, and prompt-based edits.
- Accept a suggestion: Tab. Dismiss: Esc. Cycle alternatives with keyboard shortcuts.
- Supported IDEs (inline suggestions): Visual Studio Code, Visual Studio, JetBrains IDEs, Neovim, Xcode, Vim, Azure Data Studio. Chat specifically: VS Code, JetBrains, Visual Studio, plus GitHub.com and GitHub Mobile.
- Per GitHub’s docs, Copilot Chat is available in: Visual Studio Code, Visual Studio, JetBrains IDEs, Eclipse, Xcode, GitHub.com, GitHub Mobile, and Windows Terminal.
Copilot plans
| Plan | Who it’s for / key traits |
|---|---|
| Copilot Free | Limited monthly completions and chat requests, no cost |
| Copilot Pro | Individual paid plan with higher usage limits and premium model access |
| Copilot Pro+ | Individual plan for broad model selection and high request allowance |
| Max | Individual plan for high-volume agent workflows with GitHub Copilot. |
| Copilot Business | Org-wide seat management and policy controls; no training on your org’s code by default |
| Copilot Enterprise | Adds codebase-aware chat, fine-tuned custom models, and native chat in GitHub.com, on top of Business features |
- Agent Mode / coding agent: Agent Mode (in-editor) autonomously plans a task, edits multiple files, runs terminal commands, and iterates on errors – more autonomous than chat or inline suggestions. The separate cloud coding agent can be assigned a GitHub Issue and opens a draft pull request for your review once it finishes.
- Multi-model support: Copilot lets you choose from multiple underlying AI models (e.g., different OpenAI, Anthropic, and Google models) depending on your plan and the task, rather than being limited to one model.
- Organization-wide Copilot policy management: Organization/enterprise owners can centrally enable or restrict Copilot features (e.g., specific models, Agent Mode, chat in the IDE) through Copilot policy settings, without touching individual seats one by one.
4.2 GitHub Actions
A workflow is a YAML file in .github/workflows/, made up of one or more jobs, each made of steps.
| Trigger | Fires on |
|---|---|
| push | A push to the repository |
| pull_request | PR opened/updated |
| issue_comment | A comment on an issue or PR |
| schedule | Cron syntax, on a timer |
| workflow_dispatch | Manual trigger from the UI/API |
| repository_dispatch | External/API-triggered event |
Two types of custom actions
- Container actions – package the runtime environment with the action (e.g., via a Dockerfile); consistent, but slower to start.
- JavaScript actions – run directly on the runner’s Node.js; faster, but the environment isn’t packaged with the code.
- Runners: GitHub-hosted (Linux/Windows/macOS VMs managed by GitHub) vs. self-hosted (you provide and manage the machine).
- Secrets are stored encrypted at repo/org/environment level, referenced as ${{ secrets.NAME }}, and never printed in logs.
- Actions minutes: unlimited on public repos; 2,000 minutes/month included for private repos on Free personal accounts (higher allowances on paid tiers).
4.3 GitHub Codespaces
- A cloud dev environment defined by .devcontainer/devcontainer.json in the repo. Default OS if no image is specified: Linux.
- The cloned repo lives in the /workspaces directory.
- You can create an unlimited number of Codespaces per repo/branch, limited only by available storage/resources.
- Customizable per Codespace: display name, shell, machine type (CPU/RAM tier), region, default editor (VS Code Desktop/Web, JetBrains). A dotfiles repo can auto-configure shell/tooling.
- Not configurable via Codespace settings: branch protection rules – that’s a repository-level setting.
- Default timeout: Codespaces stop automatically after 30 minutes of inactivity by default (configurable).
- Billing/ownership: a Codespace is paid for by whoever owns it – the creating user, or the organization if it has opted to cover usage.
- Losing connectivity doesn’t destroy work, but unsaved (uncommitted) changes can be lost if the Codespace is deleted – commit + push is the safe save action.
- Can be created from: GitHub.com, VS Code, or the GitHub CLI (gh codespace create).
4.4 github.dev
- A lightweight browser editor, opened by pressing “.” on any repo, or by changing github.com to github.dev in the URL.
- No terminal, no compute/build/run capability – for quick text edits and navigation only. Contrast with Codespaces, which is a full compute environment.
Domain 5 – Manage Projects with GitHub (5–10%)
GitHub Projects (the current, table/board/roadmap-based version) can span multiple repositories within an org or user account.
View types and field types
| Category | Options |
|---|---|
| View types | Table, Board, Roadmap |
| Field types | Text, Number, Date, Single select (fixed categories, e.g. High/Medium/Low), Iteration (repeating time-based phases like sprints – organizational only, doesn’t move code or run automation) |
- Built-in automation (Project → Workflows in settings) offers no-code triggers like “when status changes to Done, set to Closed” or “auto-add items matching a filter”. This is the easiest way to automate a project, versus the GraphQL API or Actions, which need more setup.
- Danger Zone = the (typically red) settings area for closing, deleting, or changing the visibility of a Project.
- Milestones (a repository-level feature, distinct from Projects) group issues/PRs toward a due date to track a release or goal – they do not enforce coding standards, run CI/CD, or enable real-time co-editing.
- Labels are simple tags on issues/PRs for categorization; created/edited in repo Settings → Labels.
- Saved replies and assignees help streamline recurring project communication – saved replies avoid retyping the same review/triage comments, while assigning the right person to issues/PRs keeps ownership clear.
- Project insights (charts built into a Project) track progress and productivity.
Domain 6 – Understand Privacy, Security, and Administration (10–15%)
6.1 Organization roles
| Role | Key powers |
|---|---|
| Organization owner | Full control: billing, security, membership, repo creation policy |
| Member | Base permission level set by the org (read/write/admin default); can be added to teams |
| Billing manager | Only billing: change plan tier, manage payment methods, view/retrieve receipts – no access to code or repo settings |
| Security manager (assignable to any team) | View security alerts (Dependabot, code scanning) and manage security settings, without full org-owner access |
| GitHub App manager | Manage GitHub App installations for the org (owners can delegate this) |
| Outside collaborator | Repo-specific access only; not an org member; no license consumption; not subject to org-wide 2FA policy |
6.2 Repository roles (org repos) – least to most access
Read → Triage → Write → Maintain → Admin
| Role | What it grants |
|---|---|
| Read | View/clone the repo |
| Triage | Manage issues/PRs (labels, assign, close) without write access to code |
| Write | Push code, create branches, open PRs – the right level for active contributors |
| Maintain | Manage the repo without full admin/destructive actions |
| Admin | Full control, including destructive actions and settings |
6.3 Authentication and identity
- 2FA secures an individual account; can be enforced org-wide for members (not for outside collaborators). Secure 2FA methods are passkeys, security keys, authenticator apps (TOTP), and the GitHub Mobile app; SMS is allowed but considered less secure.
- Passkeys let you sign in without typing a password, using a device credential (Face ID, Windows Hello, a hardware key, etc.). If you also have 2FA enabled, a passkey satisfies both the password and the 2FA requirement in one step.
- SAML SSO verifies identity against an external Identity Provider (IdP); once enabled, users authenticate with the IdP rather than a GitHub-specific credential.
- SCIM automates provisioning/deprovisioning of user accounts in sync with an IdP, often paired with SAML SSO.
- Team synchronization mirrors IdP group membership into GitHub team membership.
- GitHub Enterprise Managed Users (EMUs) – accounts fully provisioned and controlled via an IdP; restricted from interacting with resources outside the enterprise (e.g., can’t contribute to public open source with that identity).
6.4 Security tab / GitHub Advanced Security (GHAS)
| Feature | What it does |
|---|---|
| Security Advisories | Privately discuss and coordinate a fix for a vulnerability before public disclosure |
| Dependabot alerts | Flags vulnerable dependencies found via the dependency graph |
| Dependabot security updates | Automatically opens a PR to bump a vulnerable dependency to a patched version |
| Dependabot version updates | Keeps dependencies current on a schedule regardless of known vulnerabilities, configured via dependabot.yml |
| Secret scanning + push protection | Detects committed secrets (API keys, tokens); push protection can block a push containing a detectable secret before it reaches the repo |
| Code scanning (often via CodeQL) | Static analysis to find vulnerabilities; free on public repos, requires GHAS on private repos |
| Security Policy | The rendered content of SECURITY.md |
6.5 Branch protection / rulesets
- Can require: pull request reviews before merge, status checks to pass, signed commits, restrictions on who can push directly, and blocking of force-pushes and branch deletion.
- CODEOWNERS + “Require review from Code Owners” together enforce that changes to specific paths need approval from designated reviewers.
6.6 GitHub Enterprise
| Offering | Hosting model |
|---|---|
| GitHub Enterprise Cloud | Hosted by GitHub (SaaS) |
| GitHub Enterprise Server | Self-hosted on your own infrastructure/private cloud |
Domain 7 – Explore the GitHub Community (5–10%)
- Open source: anyone, anywhere, can view, use, modify, and redistribute the code, per its license.
- InnerSource: applies the same open, collaborative practices within the boundaries of one organization – visibility stays limited to the org, but contribution opens up beyond just the owning team.
- GitHub Sponsors: lets the community financially support open-source maintainers directly through GitHub; requires a sponsor-enabled profile and (historically) residing in a supported region while contributing to an eligible open-source project.
- GitHub Marketplace: a place to discover and install Actions, Apps, and integrations – not for buying seats or upgrading your plan.
- Topics: labels attached to repos (e.g., machine-learning, react) that create subject-based discoverability connections between repos, used to browse/find related projects.
- Stars: bookmark/track a repo; visible on your Stars page; also a lightweight popularity signal.
- Following: follow a user or organization/topic to stay informed of their public activity in your feed/dashboard.
- Forks, templates, and discoverable repositories: forking lets anyone propose changes without write access to the original; template repos let others start a new project with the same structure but no shared history; good discoverability (topics, README, clear docs) invites outside contribution.
