Study Guide

A version control system (VCS) tracks changes to a collection of files. Its two goals are to let you get back any earlier version of a file or the whole project, and to let several people work on the same project, even the same files, at the same time without getting in each other's way. It isn't only for software: Learn mentions books and online tutorials too.

With a VCS you can see every change, when it was made, and who made it; attach a message to each change explaining why; retrieve past versions; create branches to try changes without affecting the main line of work, then merge the ones you keep; and tag a version, for example to mark a release.

Centralized systems such as CVS, Subversion (SVN), and Perforce keep the project's history on one server, which becomes a single point of failure. Git is distributed: every copy holds the complete history, so you can commit without a network connection and sync later, and a server outage doesn't lose the project.

Git is a fast, scalable, free, and open-source distributed version control system. Its primary author is Linus Torvalds, who created Linux. Git runs on your computer: it tracks changes, keeps history, and manages branches, and it can push those branches to a remote repository.

GitHub is a cloud platform that uses Git at its core. It acts as the remote repository and adds a website, more command-line tools, and a workflow for people to work together. Features that come from GitHub rather than Git include issues, discussions, pull requests, notifications, labels, Actions, forks, projects, Copilot, and Codespaces.

You can use Git through its command line or through GUIs such as GitHub Desktop or Visual Studio Code. GUIs each implement only part of Git, while the command line exposes all of it and behaves the same on every operating system, which is why Learn recommends knowing it even if you prefer a GUI.

The working tree is the set of folders and files you're working on. The repository (repo) is the data store, in a hidden .git folder at the top of the working tree, where Git keeps all history and metadata. A remote is a named reference to another repository; when you clone, Git creates one called origin that points to where you cloned from, and it's the default for git push and git pull.

A commit is a snapshot of your project. Git identifies each object by a hash of its contents, and a commit records the author, date, message, a reference to the snapshot, and its parent commits. You choose what goes into a commit by staging: git add puts changes in the staging area (the index), git commit saves them, git status shows what's modified, staged, or untracked, and git log lists earlier commits.

A branch is a named series of linked commits; its latest commit is its head, and HEAD names the head of the branch you have checked out. A new repository's default branch is called main on GitHub. Branches let people work independently and later merge into the default branch.

Every person signs in to a personal account (GitHub Docs now calls it a user account). It's your identity, with a username and profile, and every action you take, such as opening an issue, is attributed to it. Personal accounts use GitHub Free or GitHub Pro and can own unlimited public and private repositories; on Free, private repositories have a limited feature set. GitHub Docs also describes managed user accounts, which an enterprise creates for you on GitHub Enterprise Cloud.

An organization is a shared account where many people collaborate across many projects. Like a personal account it can own repositories, packages, and projects, but nobody signs in to it: people sign in to their own accounts, and one person can belong to many organizations. Members get roles with different levels of access, and only organization owners and security managers manage the organization's settings.

An enterprise account lets administrators manage policies and billing for multiple organizations in one place, and each enterprise policy controls the options available to its organizations. GitHub Enterprise comes as Enterprise Server (self-hosted) or Enterprise Cloud (hosted by GitHub). Enterprise Cloud can use Enterprise Managed Users, where the company's identity provider controls the accounts.

The GitHub flow is a simple, branch-based way to make and share changes safely. Create a branch so your work doesn't affect the default branch; make and commit changes on it; open a pull request to ask for feedback; respond to review comments with more commits; merge the pull request once it's approved; and delete the branch so nobody keeps using an outdated one. GitHub Docs notes it suits everyone, not just developers: GitHub uses it for its site policy, documentation, and roadmap.

A pull request signals that a branch's commits are ready to merge into another branch. Reviewers comment, suggest changes, and approve. If you want feedback before the work is ready, open a draft pull request. Linking an issue with a keyword closes the issue automatically when the pull request merges, and branch protection can block a merge until requirements such as approving reviews are met.

Git flow is a heavier alternative for release-driven teams. It keeps long-lived master and develop branches and adds feature, release, and hotfix branches. It fits scheduled, versioned releases and teams that maintain several production versions; GitHub flow fits continuous delivery. Trunk-based development is another common model.

Markdown is a lightweight markup language that gives you formatting without writing HTML. One asterisk or underscore around text makes it italic and two make it bold; # through ###### make headings 1 to 6; > starts a blockquote; numbers or dashes make lists; pipes and dashes build tables; and backticks mark code, with three backticks for a fenced block that can name a language for syntax highlighting. A backslash shows a literal asterisk or underscore.

GitHub-Flavored Markdown (GFM) adds GitHub features. #42 links issue or pull request 42 in the same repository, GH-42 does the same, and owner/repo#42 links one in another repository; GitHub shortens pasted issue and commit URLs automatically. Pasting a commit's SHA links the commit. An @mention of a username or team notifies them.

Task lists (- [ ] and - [x]) track progress in an issue or pull request. Slash commands save typing in issue, pull request, and discussion comments: /code, /details, /saved-replies, /table, /tasklist (issue descriptions only), and /template.

GitHub Desktop is an open-source app for Windows and macOS that streamlines your Git workflow without the command line. You add or clone repositories, pick which changes go into a commit, add co-authors, check out branches from pull requests, view CI status, and compare changed images visually.

GitHub Mobile, for iOS and Android, is for quick, high-impact work away from your desk. You manage and triage notifications, read and review issues and pull requests, edit files in pull requests, search for and browse users, repositories, and organizations, get push notifications when someone mentions you, secure your account with two-factor authentication, and verify sign-ins from unrecognized devices. Current GitHub Docs add searching code in a repository and Copilot Chat.

Choose by the job: working with files on your own computer (cloning, committing) points to GitHub Desktop or the command line; triage, review, and approvals on the go point to GitHub Mobile; anything else works on github.com in a browser.

A README is usually the first thing a visitor sees: what the project does, why it's useful, how to get started, where to get help, and who maintains it. GitHub surfaces a README from the .github, root, or docs folder, in that order. Long documentation belongs in a wiki instead.

A LICENSE file states what others may do with the code. Without one, default copyright applies and nobody else may reproduce or build on the work, so a project without a license isn't open source even if the repository is public. A CONTRIBUTING file explains how to contribute; GitHub links to it when someone opens an issue or pull request, and shows a Contributing tab for CONTRIBUTING.md. A CODE_OF_CONDUCT sets community ground rules.

A CODEOWNERS file maps paths to people or teams, who are then requested automatically to review pull requests that change those files. Their approval becomes mandatory only when a branch protection rule requires code owner review. A SECURITY.md file tells people how to report a vulnerability responsibly. CODEOWNERS, like CONTRIBUTING, can live in the root, docs, or .github folder.

Anyone with admin permissions can mark a repository as a template in its settings. Anyone with read access can then select Use this template to create a new repository with the same directory structure and files from the default branch, or from all branches if they select Include all branches. Branches created this way have unrelated histories, so you can't open pull requests between them.

A template differs from a fork. A repository from a template starts with a single commit, its commits appear on your contribution graph, and it's meant to start a new project. A fork copies the parent's entire history and is often a temporary way to contribute changes back.

Branches let you develop features, fix bugs, or experiment in isolation. You always branch from an existing branch, and creating one needs write access. The default branch is the first branch GitHub creates, named main by default: visitors see it, clones check it out, and it's the base for new pull requests unless you choose otherwise. Protected branches can require reviews or status checks before merging.

On github.com, anyone with write access can create, upload, edit, rename, move, and delete files without installing Git. Each change is a commit with a message. When you're on the default branch, GitHub offers to commit to a new branch and open a pull request, which is usually the better choice. You can't edit or upload files directly in a protected branch on GitHub.

Browser uploads take up to 100 files at once, each up to 25 MiB. The command line accepts files up to 100 MiB. Anything larger needs Git Large File Storage (Git LFS). Push protection can block an upload that contains a supported secret, such as a token.

On the command line you copy the file into your local clone, then git add, git commit, and git push. Never add passwords or API keys to a repository; a .gitignore file tells Git which paths to leave out of commits.

A repository's Insights tab holds its graphs: Pulse (recent pull requests, issues, and commit activity, last seven days by default), Contributors, Traffic (clones, visitors, referring sites), Commits, Code frequency, Network, and Forks. Maintainers use them to see who uses the repository and why. With GitHub Free, several graphs are for public repositories only; GitHub Pro, Team, and Enterprise Cloud show them for private repositories too.

The dependency graph summarizes a repository's manifest and lock files: its dependencies (with version, license, and known vulnerabilities) and, for public repositories, its dependents. At organization level, dependency insights shows vulnerabilities and licenses across the organization's dependencies; it needs GitHub Enterprise Cloud and GitHub Docs now lists it as in maintenance mode.

Starring a repository saves it to your stars page, thanks the maintainers, and tunes the content GitHub recommends; star counts feed GitHub's rankings and Explore. Feature preview, from your profile menu, lists features in public preview and lets you enable or disable each for your account. Public preview features are documented but carry no service level agreement or support obligations until they're generally available.

GitHub recommends a README for every repository, together with a license, contribution guidelines, and a code of conduct, so people know what to expect and how to contribute.

At a minimum, enable Dependabot alerts, secret scanning, push protection, and code scanning; all are free for public repositories. Consider a SECURITY.md file and private vulnerability reporting. Keep secrets out of commits: a .gitignore file helps, and you should assume anything ever committed has been exposed.

Regular collaborators should work in one repository with pull requests between branches, and protect important branches with required reviews and status checks. Forking suits outside contributors. Track large files with Git Large File Storage (Git LFS).

Issues track ideas, feedback, tasks, and bugs. You can open one from the Issues tab, a task-list item, a project note, a comment, a specific line of code, or a URL query. Maintainers can assign it, add it to a project, set a milestone, and apply labels. Issue templates and issue forms keep reports consistent.

A pull request brings together a title and description, the proposed commits, a comment thread, code reviews with suggested changes, and status checks from automated tests. Pushing new commits updates it automatically, and it stays open until maintainers merge it or close it. A draft pull request asks for early guidance.

GitHub Discussions is a forum for conversations that aren't tied to code: announcements, ideas, polls, Q&A, and show-and-tell, organized in categories that maintainers define. Someone with admin permissions must enable it in the repository's Settings first. You can mark an answer in a Q&A discussion, pin important discussions, and reference a discussion in a new issue when it turns into work.

Link a pull request to an issue with a closing keyword in the description: close, closes, closed, fix, fixes, fixed, resolve, resolves, or resolved, followed by #number (or owner/repo#number for another repository). When the pull request merges into the default branch, the issue closes; keywords are ignored if it targets another branch. People with write access can also link up to ten issues manually from the pull request sidebar.

Issue templates and issue forms live in .github/ISSUE_TEMPLATE on the default branch. Markdown templates (.md) guide what people write; issue forms (.yml) add web form fields that can be required. A pull request template prefills each new pull request's body. Use saved replies for routine responses after an issue is filed, and templates to collect details up front.

Filters such as is:open is:issue label:bug assignee:@me combine qualifiers; spaces mean AND, and you can use OR and parentheses. -linked:pr finds issues with no pull request, and milestone: filters by milestone. Anyone with write access can assign issues and pull requests, up to 10 assignees each.

Notifications are updates about activity you've subscribed to: a specific issue, pull request, or gist; all activity in a repository; GitHub Actions workflow status; or a repository's issues, pull requests, releases, security alerts, or discussions. You're subscribed automatically when you open, comment on, or are assigned to a thread, when you or your team are @mentioned, or when you change a thread's state. You also watch repositories you create.

Watch settings, from the Watch button on a repository, control volume: Watching sends all activity, Not watching (participating and @mentions) sends only what involves you, Ignore sends nothing, and Custom picks activity types such as releases or discussions. Unsubscribe from a single thread or unwatch a repository when it stops being relevant.

In your account's Notifications settings, choose where updates arrive: the web inbox, email, or GitHub Mobile push notifications. Triage in the inbox, which labels why each notification arrived. Search mentions: plus your username to find threads where you were @mentioned.

A gist shares a code snippet, note, or small file without a full repository. Every gist is a Git repository, so it has history and can be forked, cloned, and embedded. Public gists appear in Discover and search; secret gists don't, but anyone with the URL can see them. Never store secrets in a gist, and use a private repository when you need privacy. A public gist can't be made secret later.

Every repository has a wiki for long-form documentation such as how to use the project, how it was designed, and its principles, while the README stays short. In a private repository only people with access can read the wiki. By default only people with write access can edit it.

GitHub Pages hosts a static website (HTML, CSS, and JavaScript, optionally built from source) straight from a repository. Each account can have one user or organization site, from a repository named owner.github.io, and each repository one project site, at owner.github.io/repository by default. You can use a custom domain. Pages is the choice when content must be indexed by search engines.

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform. Workflows can build and test every pull request or deploy merged changes to production, and they go beyond DevOps: a workflow can label each new issue, for example.

A workflow is a YAML file in the repository's .github/workflows folder. It runs when an event happens in the repository (a push, a pull request, an issue), on a schedule, through the REST API, or manually. A repository can have many workflows.

A workflow contains jobs. Each job runs on its own runner, a virtual machine or container, and contains steps that run in order and share data. A step runs a script or an action, a reusable extension. Jobs run in parallel unless one depends on another, and a matrix runs a job across several operating systems or versions. GitHub provides Linux, Windows, and macOS runners, or you can host your own.

Inline suggestions appear as grayed-out text as you type; Tab accepts and Esc dismisses. A comment describing what you want also prompts a suggestion. Copilot Chat answers questions in natural language, inline chat (Ctrl+I or Cmd+I) works on the code at the cursor, and slash commands such as /explain and /tests are shortcuts. Copilot can also summarize pull requests and help with code review.

Agent mode, in Copilot Chat in VS Code, Visual Studio, JetBrains IDEs, Xcode, and Eclipse, takes a high-level task, decides which files to change, edits them, and proposes terminal commands, iterating until the task is done. You review edits and approve commands, and you can extend it with MCP servers. Copilot cloud agent works on GitHub instead: it researches the repository, makes changes in an ephemeral cloud environment, and prepares a pull request for review.

Copilot supports several AI models with different strengths, such as low latency, complex reasoning, or large context windows. You choose one in the model picker or select Auto, which routes each request by task complexity and availability. What you can choose depends on your plan, the client, and your administrators' policies, and models are added and retired over time. Copilot's output can be wrong, so review and test it.

For individuals, GitHub currently offers Copilot Free and Copilot Student (free, Student for verified students) and the paid Copilot Pro, Pro+, and Max, each with a larger monthly allowance of GitHub AI Credits. Copilot Free is only for people who don't get Copilot through an organization or enterprise, and verified teachers and maintainers of popular open-source projects may get Copilot Pro free. The exam outline groups these as "Copilot for Individuals".

Copilot Business is made for organizations and enterprises. It's billed per granted seat and gives administrators centralized management and policy control: which members get access, which features and models are available, and which files Copilot should ignore. Owners of organizations on GitHub Free or GitHub Team can buy it.

Copilot Enterprise is designed for enterprises on GitHub Enterprise Cloud. It includes everything in Copilot Business, a larger monthly pool of AI credits, and additional enterprise-grade capabilities. Copilot isn't included in GitHub plans by default and isn't currently available for GitHub Enterprise Server. Plan names and allowances change, so check GitHub Docs before the exam.

GitHub Codespaces gives you a development environment in the cloud. Creating one assigns a virtual machine and storage, builds a container, connects you, and runs post-creation setup. You can create a codespace from a template, a branch, a pull request, or a commit, and open it in the browser, Visual Studio Code, or a JetBrains IDE. It has a terminal and the compute to build, run, and debug code.

The environment is a dev container: a Docker container configured as a full development environment. Its configuration lives in a devcontainer.json file, usually in a .devcontainer folder, often with a Dockerfile, and defines frameworks, tools, extensions, and port forwarding. Without one, Codespaces uses a default configuration. Put team-wide needs in devcontainer.json; personal preferences belong in dotfiles and Settings Sync. Rebuild the codespace to apply configuration changes.

You can personalize a codespace by renaming it, changing the machine type, shell, default editor, region, and timeout. By default a codespace stops after 30 minutes of inactivity, keeping your saved changes; only running codespaces incur compute charges. Inactive codespaces are deleted after 30 days by default, so commit and push your work.

Press the period key (.) on any repository or pull request, or change github.com to github.dev in the URL, to open the github.dev editor. GitHub Docs now calls it VS Code for the Web. It's free, needs you to be signed in, and gives you VS Code search, syntax highlighting, and a source control view for editing and committing.

github.dev runs entirely in the browser. It doesn't clone the repository, and your changes stay in the browser's local storage until you commit. There's no compute: you can't build or run code or use a terminal, and only extensions that can run on the web are available.

Use github.dev for quick edits, reviews, and documentation fixes. Use Codespaces when you need to build, test, debug, or use a terminal; it takes a few minutes to start because it sets up a VM and container, and personal accounts get a free monthly quota. From github.dev, commit your changes and choose Continue Working On to move into a codespace.

GitHub Projects is a planning and tracking tool at user or organization level. A project is built from the issues and pull requests you add, plus draft issues, and syncs both ways: change an item's information in the project and the issue or pull request reflects it. You can create a project from scratch or a template, from your profile, your organization, or a repository.

Each view of a project has one of three layouts. Table is a high-density spreadsheet you can group, sort, and filter. Board spreads items across columns, such as a Status field for a kanban board, and dragging an item between columns updates its field. Roadmap places items on a timeline using date and iteration fields, with markers for iterations and milestones.

Save views so the team can return to them. Projects can be public or private, and access can be granted to the organization, teams, members, or outside collaborators with read, write, or admin roles. Closing a project keeps its data; deleting it removes views, fields, insights, and draft issues.

Beyond built-in metadata such as assignees, labels, and milestones, a project can have custom fields: text, number, date, single select (such as Low, Medium, High priority), and iteration (such as weekly sprints with breaks). A project holds up to 50 fields. Group, sort, and filter views by any field.

Built-in workflows set fields automatically when items are added or changed. Two are on by default: closed issues and pull requests, and merged pull requests, get Status Done. You can turn on others, such as setting Status to Todo when an item is added, and auto-archive or auto-add items that match a filter. GitHub Actions and the GraphQL API give more control.

Labels categorize issues, pull requests, and discussions within one repository. Every new repository gets default labels such as bug, documentation, enhancement, good first issue, and help wanted, and anyone with write access can create more. A milestone groups issues and pull requests toward a goal like a release or sprint, with an optional due date, completion percentage, and counts of open and closed items.

A saved reply is a prewritten response you store in your personal settings (Settings, then Saved replies). When commenting on an issue or pull request, insert it from the comment box, or with the /saved-replies slash command, and edit it before posting. Saved replies keep routine answers fast and consistent. To collect the right information when an issue is opened, use an issue template instead.

Assignees show who's responsible for an issue or pull request. Add them from the item's sidebar, or select several items in the list and choose Assign. Anyone with write access can assign, and an item can have several assignees. Filter with assignee:@me to see your own work.

An @mention brings someone into a conversation and notifies them without making them responsible, and it helps identify who was involved long after an issue closes.

Insights for Projects lets you view, create, and customize charts that use the project's items as data. You set the filters, chart type, and fields shown, and anyone who can view the project can see the charts.

Current charts show the state of the project now, such as how many items each person has or how many issues fall in each upcoming iteration. Filters narrow them to particular labels or assignees.

Historical charts show change over time. The default Burn up chart shows completed work against what's left, so you can see progress, trends, and bottlenecks. To build your own, set the X-axis to Time; states include Open, Completed, Closed pull requests, and Not planned. Insights doesn't track archived or deleted items.

Two-factor authentication (2FA) means signing in with your password and then a second factor: a time-based code from an authenticator app, an SMS code, a security key such as a FIDO2 hardware key, Windows Hello, or Touch ID, or GitHub Mobile. Learn describes SMS as supported but less secure and not recommended as the main method. Save your recovery codes: if you lose your factors and recovery methods, GitHub Support can't restore the account. GitHub began requiring 2FA for people who contribute code on GitHub.com in 2023.

A passkey is a pair of cryptographic keys stored by an authenticator you control, such as a phone, a laptop, a password manager, or a security key. It satisfies both the password and 2FA requirements in a single step, never sends the secret to GitHub, and is bound to GitHub.com, so a lookalike phishing site can't use it. Synced passkeys follow you across devices that use the same service; device-bound passkeys stay on one authenticator. Keep a fallback 2FA method to avoid lockouts.

Organization owners can require 2FA for members, billing managers, and outside collaborators. With Enterprise Managed Users, admins can require it for the managed accounts.

Repository roles, from least to most access: Read (view and discuss), Triage (manage issues and pull requests without write access), Write (push to the project), Maintain (manage the repository without sensitive or destructive actions), and Admin (full access, including security settings and deleting the repository). GitHub Enterprise can add custom roles built on these.

Organization roles: owners have complete administrative access, and you should have at least two; members can create repositories and projects; moderators can block non-member contributors, set interaction limits, and hide comments; billing managers manage billing; security managers manage security alerts and settings across the organization and can read every repository. Outside collaborators get access to specific repositories without becoming members, which suits contractors and consultants.

Access can come from a direct collaborator role, team membership, and the organization's default permission. GitHub applies the highest of them. Follow least privilege: give the lowest role that does the job, and audit access in repository settings or the audit log.

With Enterprise Managed Users on GitHub Enterprise Cloud, an external identity provider (IdP) manages the lifecycle and authentication of users. The IdP provisions accounts, users must sign in through it, and it controls usernames, profile data, organization membership, and repository access. Managed user accounts can't create public content or collaborate outside the enterprise, and users can't change their profile name or email on GitHub. Partner IdPs include Microsoft Entra ID, Okta, and PingFederate.

Organization owners with Copilot Business or Copilot Enterprise manage Copilot in the organization's Settings, under Copilot. Policies controls which features are available and their privacy settings; Models controls which models beyond the basic ones members can use, which may add costs.

Enterprise owners can set Copilot policies too. When they choose a setting (enabled everywhere, disabled everywhere, or enabled for selected organizations), organization owners can't override it; organizations decide only the policies the enterprise leaves to them.

Repositories are public (everyone on the internet), private (you, people you give access, and certain organization members), or internal (everyone in the enterprise, for organizations owned by an enterprise on GitHub Enterprise Cloud). Organization owners can always see every repository in their organization, and people with admin permissions can change visibility. Public repositories expose your code, so turn on security features and add a SECURITY.md file.

A branch protection rule applies to a specific branch, all branches, or a name pattern. By default it blocks force pushes and deletion. It can also require pull request reviews (including from code owners), passing status checks, resolved conversations, signed commits, linear history, a merge queue, or successful deployments, and it can lock the branch or restrict who can push.

Admins bypass the rule unless you apply it to them too. Only one branch protection rule applies to a branch at a time; rulesets can layer several. With required reviews, collaborators can change the protected branch only through an approved pull request.

Teams group organization members to match your company's structure. Owners and team maintainers grant a team access to repositories once for everyone in it, members can @mention a team or request its review, and a team can be a code owner. Teams are visible (seen by every member) or secret (seen only by their members and owners). Outside collaborators can't be on teams.

Nested teams reflect hierarchy: child teams inherit the parent team's repository access, and mentioning a parent notifies its child teams too. Give parent teams access that's safe for everyone below them and grant child teams more specific access.

Team maintainers manage a team without being organization owners: they change its name, description, and visibility, add and remove members, remove repository access, and manage code review assignment. Organization owners set default repository permissions for all members; Learn recommends default Read with more granted case by case, following least privilege.

Open-source software can be freely used, viewed, modified, and shared by anyone for any purpose. The idea is that sharing code produces better, more reliable software. Contributing builds your skills and portfolio and connects you with developers worldwide, and every kind of contribution counts, from code to documentation fixes. A project needs an open-source license to be open source.

Open source relies heavily on volunteer work. GitHub Sponsors lets you financially support developers and organizations with sponsored profiles, from your personal account or an organization, with one-time or monthly payments at tiers the maintainer sets. Sponsorships from personal accounts carry no GitHub fees. A project eligible for sponsorship shows a Sponsor button on its main page.

GitHub helps contributors find work: search by topic, browse github.com/topics, and use Explore for recommendations. Labels such as good first issue and help wanted mark beginner-friendly issues, and a repository's /contribute page lists them. Before starting, check for a license, a code of conduct, contributing guidelines, and active maintainers; Pulse shows recent activity.

Contributing follows a standard path. Say on the issue that you plan to work on it, after checking its assignees and linked pull requests. Fork the repository, make the change on a branch, push it, and open a pull request to the original project with a clear description that links the issue. Pass the project's status checks, respond to review respectfully, and keep discussion public.

Follow a person from their profile page to see their public activity on your personal dashboard; repositories they star may be recommended to you. Follow an organization from its page to see its public activity, such as new discussions, sponsorships, and repositories. Following organizations is in public preview and may change.

You can unfollow at any time, and see who a user follows and who follows them from their profile. Following is about people and organizations; to get notifications about a single repository, watch it, and to bookmark one, star it.

GitHub Marketplace connects developers with tools that extend and improve their GitHub workflows. It lists two kinds of tools, GitHub Actions and apps, either free or paid.

Anyone can publish an action, and GitHub verifies some partner organizations as verified creators. Anyone can list an app for free, but only apps owned by organizations can sell paid plans, after the organization completes publisher verification. Marketplace lists both GitHub Apps and OAuth apps; GitHub recommends GitHub Apps because they offer much more granular permissions.

InnerSource applies open-source patterns to projects with a limited audience, such as a company's employees: in effect, open source behind the firewall. It increases internal visibility, so teams can see and reuse each other's solutions; it reduces friction, because a team that needs a change can propose it, or fork if it can't be merged; and it standardizes practices across teams.

On GitHub Enterprise, use internal visibility for InnerSource repositories so every enterprise member can find them, and set roles from Read to Admin as needed. Make repositories discoverable and easy to contribute to with a README, a license, a CONTRIBUTING file, CODEOWNERS, issue and pull request templates, and a clear branching workflow. GitHub Discussions and Projects support cross-team collaboration.

Measure process and teams, not individuals: code review turnaround, pull request size, work in progress, unique contributors, projects reusing code, and cross-team @mentions. Misused metrics can harm the culture.

A fork is your own copy of a repository, connected to the original (upstream) one. Fork when you don't have write access, want to experiment without affecting the original, or are exploring a new direction; changes flow back through pull requests. If you have write access to a shared repository, use a branch instead.

A template repository gives a new project the same structure and files, starting from a single commit with no shared history. Use it to start new projects consistently, not to contribute back.

Discoverable repositories are easy to find and reuse: a descriptive name and short description, a README explaining the purpose, a license, and topics describing the purpose and subject area. Topics use lowercase letters, numbers, and hyphens, and a repository can have up to 20.

Not in the GH-900 skills measured, but taught in the official Part 1 module *Introduction to GitHub's products*. GitHub bills by account type. A bill can combine license (subscription) charges for products assigned to an account, such as GitHub Pro, GitHub Team, or Copilot seats, with usage-based charges for products whose cost grows with use, such as GitHub Actions, GitHub Packages, Codespaces, and some Copilot features. An enterprise account can consolidate billing across its organizations or route charges to cost centers.

Copilot Business and Copilot Enterprise are billed per assigned license, prorated when seats are added mid-cycle. Each license adds AI credits to a shared pool that features such as Copilot Chat, Copilot CLI, and Copilot cloud agent consume; code completions don't use credits on paid plans. Keep billing views (seats, costs, AI-credit use) separate from the Copilot usage metrics and impact dashboards, which measure adoption: a user can hold a billable license without using Copilot.

Enterprise admins review seat use by organization under license usage in the enterprise's billing settings; pay-as-you-go plans bill monthly for seats used, while prepaid plans show available licenses. Billing settings also break down Actions minutes by repository and runner type and Packages by storage and transfer. Budgets prevent surprises: they send email alerts as spending passes set percentages and can stop metered usage such as Actions at the limit (older training calls them spending limits), and reclaiming inactive seats and auditing regularly keep costs down. Prices and allowances change, so check GitHub's billing documentation.

Not in the GH-900 skills measured, but taught in the official Part 2 module *Authenticate and authorize user identities on GitHub*. SAML single sign-on connects GitHub to a company identity provider (IdP) such as Microsoft Entra ID, Okta, AD FS, OneLogin, or PingOne, so people authenticate there before reaching organization resources. Enforcing it for one organization removes noncompliant members immediately and suits pilots; enforcing it for the enterprise applies one policy everywhere, prompting noncompliant members when they next access a resource.

SAML SSO alone doesn't remove people who leave. SCIM provisions and deprovisions users automatically from the IdP and revokes stale tokens. Team synchronization maps GitHub teams to IdP groups in Entra ID or Okta so membership changes flow to GitHub teams; it needs SAML SSO and SCIM and doesn't create accounts. Enterprise Managed Users go further, with the IdP owning the accounts themselves.

For Git and API access, GitHub no longer accepts passwords. Use personal access tokens, preferring fine-grained PATs, which are limited to specific repositories and permissions and can expire; SSH keys on your account; or deploy keys, which attach to a single repository and are read-only by default. With SAML SSO, a PAT or SSH key must be authorized for the organization.