Reviewed 10 October 2026 against the linked published scope. January 2026 outline: Git basics 25–30%, repositories 10–15%, collaboration 10–15%, modern development 10–15%, projects 5–10%, administration 10–15%, community 5–10%.
Memory hook: Git records history; GitHub coordinates trusted collaboration around it.
Read the essentials, cover the answers and explain the decision aloud. Open the topic summaries below whenever a distinction is unclear.
Git, repositories and collaboration
- Working tree holds edits; staging/index selects the next commit; commits record snapshots/history.
fetchupdates remote-tracking information;pullalso integrates according to configuration.pushpublishes local commits to a permitted remote. - A branch is a movable reference, not an independent full copy of the repository. Merge joins histories; rebase replays commits and changes identities. Avoid rewriting shared history without coordination.
- GitHub Flow: create a focused branch, commit, open a pull request, review/check, merge and clean up. A pull request proposes integration; it is not the commit itself. Conflicts need human judgment about the desired combined result.
- A fork creates a related repository for independent contributions; a template seeds a new project; clone makes a local copy. An upstream remote can help a fork follow its source.
- README explains use, LICENSE grants permissions, CONTRIBUTING guides contributions, CODE_OF_CONDUCT sets community expectations and SECURITY documents reporting. Publicly visible source without a license does not automatically grant unrestricted reuse.
- Issues track work; discussions host broader conversation; pull requests review changes. Labels classify, milestones group a target and Projects combine work into table/board/roadmap views. Closing a linked issue depends on supported syntax and merge/default-branch context.
- CODEOWNERS requests relevant reviewers; enforced approval requires applicable rules. Branch protection/rulesets can require checks, reviews and other conditions, with configured exceptions/bypass behavior.
Development, automation and planning
- Actions workflows react to events and contain jobs/steps. Jobs run on hosted or self-hosted runners. They can build/test/deploy, but safe credentials, event trust and permissions remain necessary.
- Codespaces provides a hosted development environment with compute/terminal access. github.dev is browser-based editing without the same runtime environment. A dev container definition can make supported environments repeatable.
- Copilot offers code/chat/agent assistance within available features and policies. Review correctness, security and licensing implications; generated code is not automatically trusted. Organization plans add administration/governance beyond individual features.
- Projects track issues, PRs and draft items using fields, views and supported automation. A project field is not necessarily a repository label. Roadmaps visualize dates; milestones have repository scope.
- Insights and repository graphs help inspect activity/dependencies, but commit count alone does not measure useful work. Notifications/subscriptions determine what a person follows; mentions request attention, not access permission.
Security, administration and community
- Personal accounts represent people; organizations manage teams/repositories; enterprises coordinate eligible organizations/policy. Enterprise Managed Users are governed through the organization's identity system under that model.
- Use supported MFA/passkeys, protected recovery options and scoped tokens. Repository roles differ; team membership and inheritance affect access. Organization owner access should be limited and recoverable.
- Public, private and eligible internal repositories have different audience boundaries. Visibility changes do not erase copies, forks or previously exposed secrets. Revoke/rotate a leaked credential; deleting a commit alone is insufficient.
- Dependabot alerts concern vulnerable dependencies; code scanning detects supported code findings; secret scanning identifies exposed credentials. These controls overlap usefully but do not substitute for each other or a complete review.
- Open source depends on license and community practice; InnerSource applies collaboration patterns internally. Sponsors supports eligible maintainers; Marketplace distributes integrations/actions with varying trust and permissions.
- Follow contribution instructions, make reproducible reports, submit focused changes and communicate respectfully. A maintainer can decline a change even when its code works.
Exam traps
- A PR review request is not automatically an enforced merge gate.
- A public repository does not mean unrestricted license rights or safe secrets.
- Codespaces, github.dev and Copilot solve different development needs.
Final active recall
1. Fetch versus pull?
Fetch updates remote-tracking information; pull also integrates using the configured strategy.
2. Does CODEOWNERS alone require owner approval?
No. Applicable branch/ruleset protections must enforce the requirement.
3. Which provides a hosted terminal: github.dev or Codespaces?
Codespaces supplies a full hosted development environment; github.dev is browser editing.
4. A key was deleted from Git history. Is the incident resolved?
No. Revoke/rotate it and investigate exposure; copies may remain.
5. Fork versus template?
A fork retains a contribution relationship to its source; a template seeds a separate project.
Sources and further practice
- Official exam scope
- Objective-to-topic coverage map. Each full topic links to its supporting primary technical documentation.
- GitHub documentation
Every topic at a glance
Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.
01 · Git, Commits and GitHub Flow
Memory hook: Commit locally, share remotely, review before merging.
Must remember
Git is a distributed version-control system. GitHub hosts repositories and adds collaboration, automation and governance. A local repository can have commits that have never been pushed anywhere. A commit records a snapshot and metadata; a branch is a movable reference to a line of development.
The working tree contains files being edited. Staging selects changes for the next commit. git status shows the relationship between working tree, index and branch; git diff inspects changes. git add stages, git commit records locally and git push transfers commits to a remote. git fetch retrieves remote history without integrating it into your current branch; pull retrieves and integrates according to configuration.
GitHub Flow uses a short-lived branch, focused changes, a pull request, review/checks and merge. Keep the default branch usable and remove obsolete branches after their work is integrated. A pull request proposes integration between branches; it is not the same operation as git pull.
Merging joins histories; rebasing replays commits onto a new base and changes commit identities. Conflicts require understanding both intended changes, resolving files and verifying the result. Rewriting shared history can disrupt collaborators, so follow repository policy. A revert records an inverse change; deleting a file in a new commit does not erase it from older history.
Personal accounts represent individuals; organizations organize shared repositories, teams and policies; enterprises coordinate eligible organizations and enterprise settings. Keep individual attribution and use scoped access rather than shared human credentials.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Inspect remote changes without integrating | Fetch, then compare. |
| Propose a reviewed change | Branch and pull request. |
| Undo a published change while preserving history | A reviewed revert where appropriate. |
Traps
- Commit does not mean push.
- Removing a secret from the latest file does not remove it from history or revoke it.
02 · Repository Files, Templates and Visibility
Memory hook: A repository needs instructions as well as code.
Must remember
The README explains purpose and usage. LICENSE states reuse rights. CONTRIBUTING describes contribution expectations. SECURITY directs vulnerability reporting. CODEOWNERS identifies reviewers for matching paths, but required approval depends on protection/ruleset configuration. A code of conduct defines participation expectations and enforcement contacts.
A template repository seeds a new project without preserving the same collaboration relationship/history as a fork. A fork is a related repository used to develop changes independently and propose them upstream. A clone is a local copy of repository history. Choose based on whether the intent is reuse as a new project or continued upstream contribution.
Use branches, directories and focused commits to organize changes. .gitignore excludes matching untracked paths; it does not stop tracking a file already committed. Git LFS stores supported large-file content outside ordinary Git objects with pointers in the repository; it has separate usage considerations.
Repository insights and dependency views help understand activity, contributors and dependencies. Stars bookmark/show interest; watching controls notifications. A high star count is not evidence of security or maintenance quality. Inspect recent activity, documentation, issue handling and license suitability.
Public, private and eligible internal visibility have different audience boundaries. Publishing a repository requires checking its full history and artifacts, not just its current README. Feature previews expose changing functionality; learn the stable capability and verify current availability rather than assuming every account has the same UI.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Start an independent project from a scaffold | Template repository. |
| Contribute back to an upstream project | Fork plus pull request. |
| Request path-specific review | CODEOWNERS with suitable review enforcement. |
Traps
- A public repository without a license is not automatically freely reusable.
- Adding a tracked file to gitignore does not remove it from history.
03 · Issues, Pull Requests and Shared Communication
Memory hook: Issues describe work; pull requests propose changes.
Must remember
Issues track bugs, requests and actionable work. Pull requests present proposed changes for discussion, automated checks and review. Discussions suit broader questions and community conversation that may not yet be actionable tasks. Use templates to request reproduction steps or design context without making reporting unnecessarily difficult.
Link related issues and pull requests. Supported closing keywords can close an issue when the linked change reaches the default branch under the platform's rules. Assignments identify responsibility; labels classify work; review requests ask for specific assessment. A reviewer approval does not guarantee every required check passed or every policy is satisfied.
Review the diff, intent, test evidence and risk. Comments, suggested changes and resolved conversations provide a review trail. Merge commits preserve branching history, squash creates one combined commit and rebase merge creates a linear sequence; select according to project policy and audit needs.
Markdown supports readable headings, lists, links, fenced code and task lists. Use small reproducible examples and avoid secrets in public reports. Notifications can be configured by repository, participation and event type. Watching everything can bury the action that matters; tune subscriptions and use filters.
Wikis provide collaborative documentation. Gists share snippets and can be public or secret; secret means unlisted, not access-controlled private. GitHub Pages publishes supported static content. Repository privacy and Pages publication settings must be checked independently for the actual plan/configuration. GitHub Desktop supports common Git workflows visually; Mobile supports on-the-go collaboration but is not a full local development environment.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Track a reproducible defect | Issue with steps and expected/actual behavior. |
| Propose code for review | Pull request. |
| Host static project documentation | GitHub Pages with reviewed publishing settings. |
Traps
- A secret gist is accessible to anyone who has its URL.
- Resolving a conversation does not prove the underlying issue was fixed.
04 · Actions, Copilot and Development Environments
Memory hook: Automation runs work; an editor changes files; a runtime executes them.
Must remember
GitHub Actions automates repository events through workflows containing jobs and steps. Runners execute jobs; reusable actions package operations. Typical uses include tests, builds, releases and deployment. A workflow's permissions and event trust boundary determine what it can safely do.
Codespaces provides a hosted development environment with compute and terminal access. A dev container definition describes a repeatable environment, including supported tools, extensions and setup. Stop/delete unused resources according to retention and cost requirements; closing a browser tab is not necessarily immediate resource deletion.
The github.dev editor offers lightweight browser editing without the full compute/terminal environment of Codespaces. Choose it for quick edits and reviews; choose Codespaces or local development when you must run builds, tests or services. GitHub Desktop is a local Git client, not a cloud runtime.
Copilot assists with suggestions, chat and supported agent workflows. Agent Mode can plan and modify multiple files or invoke permitted tools; a coding agent can work through a delegated development workflow. Both need clear tasks, limited permissions, review and tests. Model selection changes capabilities and behavior; it does not remove the need to validate output.
Individual plans focus on personal use; Business and Enterprise offerings add organizational administration, policy and eligible capabilities. Plan names/features evolve, so distinguish governance needs from memorizing a transient price. Organization policies can constrain features even when a user has a license. Review generated code for correctness, security, dependencies and licensing implications.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Quick browser edit without running commands | github.dev. |
| Reproducible remote build/test environment | Codespaces with a dev container. |
| Run tests when a PR changes | An Actions workflow with scoped permissions. |
Traps
- A browser editor is not automatically a compute environment.
- AI-generated code still needs review and tests.
05 · Projects, Milestones and Work Visibility
Memory hook: Track outcomes and flow, not just a pile of tickets.
Must remember
GitHub Projects organizes issues, pull requests and draft items using table, board and roadmap views. Views are different presentations of project data, with filters, sorting and grouping. Custom fields capture attributes such as priority, status or iteration; define them consistently so reports remain meaningful.
Labels classify repository issues/PRs. Milestones group work toward a release or objective with progress tracking. Assignees identify people responsible for work. These are related but not interchangeable: a label named release does not automatically behave like a milestone.
Built-in project workflows can update fields or archive items when conditions are met. Automation should reflect the team's real process; a merged PR may complete implementation while release or verification remains outstanding. Inspect the trigger and status meaning before treating a board column as delivery evidence.
Saved replies reduce repeated typing, but adapt them to the actual report. Issue forms/templates improve incoming information. Use project insights to examine flow and progress while recognizing what is not measured: closed-ticket counts do not directly prove customer value or quality.
Keep permissions, scope and audience in mind. A project can reference items with their own repository visibility restrictions. The presence of a project view does not grant access to all underlying private issues. Review stale work, blocked dependencies and unclear ownership regularly.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| See work by status | Board view grouped by a consistent status field. |
| Group issues for a planned release | Milestone. |
| Track a custom priority across repositories | Project field and filtered views. |
Traps
- Ticket count is not a reliable standalone productivity measure.
- Project access does not automatically reveal every private repository item.
06 · Account Security, Teams and Repository Governance
Memory hook: Authenticate the person; authorize the action; protect the shared branch.
Must remember
Protect accounts with supported two-factor methods or passkeys and maintain safe recovery options. A passkey uses public-key authentication and can provide phishing-resistant sign-in. Credentials used by tools need their own scope, expiration and revocation strategy; do not share a human account to simplify automation.
Repository roles grant different capabilities. Organization teams simplify group access and reviewer coordination. Owners administer broad settings; routine work should use narrower roles. Internal repositories are intended for eligible enterprise audiences, while private repositories use explicitly controlled access.
Branch protection and rulesets can require pull requests, reviews, status checks and other conditions. Evaluate bypass actors and administrative exemptions. A rule that allows every administrator to bypass controls has a different risk profile from one with tightly controlled exceptions. Required checks must use trustworthy workflows.
Enterprise Managed Users are provisioned and governed through an organization's identity provider under the enterprise model. They differ from inviting ordinary personal accounts into an organization, including collaboration constraints. Organization/enterprise Copilot policies govern eligible features and usage; a personal preference cannot necessarily override them.
Dependency alerts, code scanning and secret scanning address different risks: vulnerable dependencies, supported code patterns and exposed credentials. Availability depends on product/plan/repository settings. A secret finding requires revocation/rotation and investigation; deleting the line is insufficient. Audit logs help investigate administrative changes but do not replace appropriate prevention.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Manage access for a team of engineers | Organization team with scoped repository roles. |
| Require review before default-branch changes | Protection/ruleset with controlled bypass. |
| Central identity lifecycle for enterprise users | Evaluate Enterprise Managed Users and its constraints. |
Traps
- 2FA does not make every automation token safe.
- A required check is weak if untrusted code can forge or bypass its result.
07 · Open Source, InnerSource and Community
Memory hook: Visibility invites participation; a license defines reuse.
Must remember
Open source combines source availability with a license granting specified rights and obligations. A public repository without an explicit license does not automatically grant broad reuse rights. Read license terms and contribution guidance, especially when combining dependencies or redistributing modifications.
Contribute by improving documentation, reporting reproducible bugs, reviewing or submitting focused changes. Read existing discussions/issues first and respect maintainers' process. A fork supports independent work and upstream proposals; a template starts a new project from a scaffold. Discoverability improves with useful descriptions, topics, README content and maintained documentation.
InnerSource applies open collaboration practices within an organization. Shared ownership, clear contribution rules and transparent review can reduce silos while the code remains private. It does not require publishing confidential material or removing access controls.
GitHub Sponsors supports eligible maintainers financially. Following people/organizations helps discover their public activity; watching a repository subscribes to selected notifications. Stars express interest and help discovery but are not an assurance of quality or security.
Marketplace helps discover integrations and reusable actions. Evaluate maintainer trust, source code, permissions, update history and license before adoption. Installation or use can grant meaningful access. Community health includes clear support boundaries, respectful conduct and realistic maintenance expectations, not only download or star totals.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Collaborate openly inside the company | InnerSource with appropriate access controls. |
| Help maintain a project without writing a feature | Documentation, reproduction, review or supported sponsorship. |
| Adopt a Marketplace action | Review trust, code, permissions and version before use. |
Traps
- Public visibility is not a substitute for a license.
- Popularity is not a security review.