Domain 1: Introduction to Git and GitHub
- Git is a distributed version control system (DVCS): every clone is a full copy of the repository including its entire commit history, so work can continue offline.
- A commit is an immutable snapshot of staged changes, identified by a unique SHA hash, and carries an author, committer, message, and timestamp.
- A repository is the version-controlled container for a project's files, complete change history, branches, issues, pull requests, and settings.
- Common Git workflow commands: git add stages changes, git commit records staged changes locally, git push uploads local commits to a remote, git clone copies a remote repo (with history) locally.
- git fetch downloads remote changes without merging them; git pull does a fetch AND merge into your current branch (pull = fetch + merge).
- Branches create independent, parallel lines of development; create and switch with git switch -c <branch> (or the older git checkout -b <branch>).
- A .gitignore file tells Git which files and paths to leave untracked, such as build artifacts, dependencies (node_modules), local config, and secrets.
- GitHub is a cloud platform built on Git that adds collaboration features on top: a web UI, issues, pull requests, Actions, project boards, and access control.
- GitHub Flavored Markdown is used in issues, PRs, comments, and READMEs; links use the [text](https://example.com) syntax and task lists use - [ ] checkbox items.
Domain 2: Working with GitHub Repositories
- A repository can be created from scratch, from a template repository, or by importing an existing project, and can be initialized with a README, .gitignore, and license.
- Cloning copies a remote repository (with its history) to your local machine, while forking creates your own server-side copy under your account that you can change and propose back via a pull request.
- Starring a repository bookmarks it and signals appreciation but does NOT create a copy; watching a repository subscribes you to its notifications.
- A README on the repository's main page documents the project's purpose, setup, and usage, and is the first thing visitors see; a special profile README appears on your GitHub profile.
- Adding a LICENSE file defines how others may use the code; a public repository without a license is still all-rights-reserved by default.
- Releases package a specific commit (usually tagged) with release notes and downloadable assets so users can grab a stable version of the software.
- The repository's Insights tab surfaces activity such as commits, contributors, traffic, and dependency information.
- You can search and navigate code in the browser, view file history and blame, and use gists to share small standalone snippets outside a full repository.
Domain 3: Collaboration Features
- Issues track tasks, bugs, feature requests, and questions; they can be assigned, labeled, grouped into milestones, and linked to pull requests.
- A pull request proposes changes from a source branch into a target branch (often main) and provides a place for discussion, review, and automated checks before merging.
- Reviewers can comment, approve, or request changes on a pull request; the Files changed tab shows the diff where reviewers leave inline comments on specific lines.
- Linking a closing keyword like 'Closes #123', 'Fixes #123', or 'Resolves #123' in a PR description automatically closes that issue when the PR merges.
- Merge strategies: a standard merge keeps all commits, squash merge combines a PR into a single commit on the target branch, and rebase merge replays commits without a merge commit.
- A merge conflict occurs when different branches change the same lines and Git cannot auto-merge; it must be resolved before the merge completes.
- Issue and pull request templates live in the .github directory; issue forms (YAML) can require structured fields so reports include needed information up front.
- @mentions notify a person or team, and referencing another issue or PR by number creates a cross-link between them.
- Notifications keep collaborators informed of activity they are watching, are assigned to, or are mentioned in, and can be tuned per repository or globally.
Domain 4: Modern Development
- GitHub Actions is a CI/CD and automation platform that runs workflows defined as YAML files in .github/workflows/ in response to events such as push and pull_request, on a schedule, or via manual dispatch.
- A workflow contains one or more jobs, each made of steps that run commands or reusable actions; the Marketplace offers thousands of prebuilt actions you can reference with the 'uses' keyword.
- Workflows run on runners: GitHub-hosted runners are free for public repositories and consume included minutes for private ones, while self-hosted runners use your own hardware.
- GitHub Codespaces provides cloud-hosted development environments accessible in the browser or VS Code, with the repository pre-cloned and tooling defined by a dev container configuration.
- GitHub Copilot is an AI pair programmer that suggests code and whole functions as you type and answers coding questions through Copilot Chat.
- GitHub Pages hosts static websites directly from a repository (for example from a branch or a /docs folder), commonly for documentation or project sites.
- GitHub Packages hosts and shares packages (npm, Maven, NuGet, RubyGems, containers, and more) alongside source code using the same permissions model.
- GitHub Mobile lets you triage notifications, review and merge pull requests, and manage issues from a phone.
- Continuous integration builds and tests changes automatically on each push or pull request, and continuous delivery/deployment can then ship them, with environments and approvals gating sensitive deploys.
Domain 5: Project Management
- GitHub Projects is a flexible planning tool that presents issues and pull requests as boards, tables, and roadmap views, so the same items can be seen as a Kanban board or a spreadsheet-style grid.
- Projects support custom fields (such as text, number, date, single-select, and iteration fields) to capture information like status, priority, or sprint, and iteration fields help plan recurring cycles.
- Issues, milestones, labels, and assignees are the core planning primitives: milestones group work toward a goal or deadline, labels categorize items, and assignees show who is responsible.
- Task lists (- [ ] checkbox items) break an issue into subtasks and can be tracked toward completion; converting a task into its own issue keeps a tracked relationship.
- Project insights provide built-in charts (for example burn-up and current-status charts) that visualize progress and workload over time.
- Built-in workflows and automation can move an item to a column or set a field automatically, for example when an issue is closed or a pull request is merged.
- Saved replies let you store and reuse common comment text to respond quickly to repetitive issues and pull requests.
- Projects can be scoped to a user or an organization and can pull in items across multiple repositories, and views can be filtered, sorted, and grouped and then saved for reuse.
Domain 6: Privacy, Security, and Administration
- Repository visibility can be public (visible to everyone), private (visible only to those granted access), or internal (visible to all members of an enterprise).
- Repository permission levels progress from Read, to Triage, to Write, to Maintain, to Admin, granting increasing capability; apply least privilege by giving people only the access they need.
- Organizations own repositories collectively and set a base permission that applies to all members, and use teams to grant access to groups of people at once instead of managing users individually.
- Organization roles (such as member and owner) and enterprise roles (such as enterprise owner and billing manager) control who can administer settings, billing, and policies at each level.
- Two-factor authentication (2FA) adds a second verification step beyond a password and is required for accounts that contribute code on GitHub.
- SAML single sign-on (SSO) lets an organization or enterprise authenticate members through an external identity provider, and the audit log records administrative and security-relevant events.
- Secret scanning detects committed credentials, code scanning (often via CodeQL) finds vulnerabilities in source, and Dependabot alerts on and can patch vulnerable dependencies.
- Security advisories let maintainers privately discuss, fix, and then publish disclosures for vulnerabilities, and a security policy (SECURITY.md) tells people how to report issues responsibly.
Domain 7: Benefits of the GitHub Community
- Open source software is released under a license that lets anyone view, use, modify, and share the code, which can speed development, improve quality through many contributors, and build reputation.
- InnerSource applies open source practices and collaboration (transparent repos, pull requests, and shared reuse) inside a single organization or company.
- GitHub Sponsors lets individuals and organizations fund the maintainers and projects they depend on with one-time or recurring payments.
- Community health files such as README, CONTRIBUTING, CODE_OF_CONDUCT, LICENSE, and issue/PR templates help newcomers understand and participate in a project; defaults can live in an organization's .github repository.
- GitHub Discussions provides a forum-style space for questions, ideas, and announcements that are separate from actionable issues.
- GitHub Skills offers hands-on interactive courses, and GitHub Education provides free tools and benefits for verified students and teachers.
- Stars bookmark and signal appreciation for projects, following people surfaces their activity, and Explore and trending help you discover repositories and developers.
- Sharing work publicly builds a portfolio and professional network, and contributing to established projects is a common way to learn, gain experience, and get noticed.
GitHub Foundations exam tips
- Know the precise difference between similar concepts: fetch vs pull (pull adds the merge), clone vs fork vs star, and public vs private vs internal visibility; these distinctions are frequently tested.
- Memorize the repository permission ladder (Read, Triage, Write, Maintain, Admin) and pick the least-privilege role that still fits the scenario.
- Match the GitHub feature to the scenario: Pages for static sites, Codespaces for cloud dev environments, Packages for artifacts, Actions for automation, and Projects/Milestones for planning.
- For Project Management questions, connect the tool to the need: boards/tables/roadmap views, custom and iteration fields, milestones/labels/assignees, task lists, insights charts, and built-in automation.
- For security questions, recognize each feature by what it protects: 2FA and SSO for access, secret scanning for leaked credentials, code scanning for code flaws, and Dependabot for vulnerable dependencies.
Study guide FAQ
How is the GitHub Foundations exam structured and scored?
It is a multiple-choice exam of roughly 60 questions organized into 7 domains, with a 90-minute time limit, delivered online with a proctor. It is scored on a scaled range (about 100-1000) and you need 700 to pass. There is no required prerequisite exam.
What are the seven domains covered on the exam?
They are: Introduction to Git and GitHub, Working with GitHub Repositories, Collaboration Features, Modern Development, Project Management, Privacy Security and Administration, and Benefits of the GitHub Community. The domains are weighted differently, so review the current exam guide to see where the most questions come from.
What is the difference between forking and cloning a repository?
Forking creates a server-side copy of a repository under your own GitHub account so you can change it independently and propose changes back via pull request. Cloning copies a repository (with its history) to your local machine to work on it. You typically fork on GitHub, then clone your fork locally.
How much real hands-on experience do I need before taking it?
GitHub recommends a few months of general familiarity with GitHub. Being comfortable creating repositories, branching, opening issues and pull requests, doing reviews, planning with Projects, and understanding basic permissions and security features is enough; you do not need professional CI/CD or administration experience.