GitHub Foundations — Practice Set 1

Question 1

A new developer joins a team and asks what the difference is between Git and GitHub. Which statement correctly explains the distinction?

Accepted Answer

Git is an open-source distributed version control system created by Linus Torvalds. It runs locally on a developer's machine and tracks changes in files over time. GitHub is a cloud-based platform built on top of Git that adds collaboration features such as pull requests, issues, code review, Actions, and repository hosting. Git works without GitHub; GitHub uses Git as its underlying version control engine.

Question 2

A developer wants to save a snapshot of their current changes to the repository history with a descriptive message. Which Git operation accomplishes this?

Accepted Answer

`git commit` records the staged changes as a new snapshot (commit) in the local repository history, along with an author, timestamp, and commit message. `git push` uploads existing local commits to a remote repository. `git stash` temporarily shelves uncommitted changes without creating a commit. `git merge` integrates changes from one branch into another but does not create the initial snapshot.

Question 3

A company uses GitHub and needs to understand how to structure access for a large engineering division with multiple teams and repositories. Which GitHub structure allows grouping multiple repositories and users under shared settings and policies, above the individual repository level?

Accepted Answer

A GitHub organization is a shared account that groups multiple repositories and allows teams of users to collaborate with collective ownership, shared billing, and centralized policy management. An organization can contain many teams and repositories. A GitHub team is a group of users within an organization but does not contain repositories directly. A GitHub project is a planning and tracking tool for issues and pull requests. A Codespace is a cloud development environment.

Question 4

A team follows the GitHub Flow branching strategy. A developer has finished a feature on a branch named `feature/payment-retry`. What is the correct next step according to GitHub Flow before merging to `main`?

Accepted Answer

GitHub Flow is a lightweight branching model where all feature work happens on short-lived branches off `main`, and changes are integrated via pull requests. Opening a PR allows teammates to review code, run automated checks, and discuss changes before merging. Direct commits to `main` bypass review. Creating a `develop` branch is part of Git Flow, not GitHub Flow. Rebasing onto release tags is not part of the standard GitHub Flow process.

Question 5

A developer wants to format a pull request description with a bulleted list, bold text, and a link to an external document. Which GitHub-supported formatting syntax should they use?

Accepted Answer

GitHub renders Markdown in issue bodies, pull request descriptions, comments, README files, and wikis. Markdown supports headings (`#`), bold (`**text**`), bulleted lists (`-`), and hyperlinks (`[text](url)`). While HTML is partially supported in some GitHub Markdown contexts, Markdown is the intended and primary format. GitHub does not natively render RST or AsciiDoc in issue/PR descriptions.

Question 6

A developer is working on a laptop and a tablet and wants a native GUI application to manage cloning, committing, and pushing without using the command line. Which tool is designed for this?

Accepted Answer

GitHub Desktop is a native GUI application for Windows and macOS that provides a visual interface for Git operations such as cloning, staging, committing, pushing, and managing pull requests without a command line. GitHub CLI (`gh`) is a command-line tool. GitHub Codespaces is a cloud-based development environment accessed through a browser or VS Code. github.dev is a browser-based lightweight editor that does not support all Git operations.

Question 7

A team lead explains that version control is essential for their 20-person engineering team. A new hire asks why version control is needed when the team could just save files to a shared network drive. Which response best describes the purpose and benefits of version control?

Accepted Answer

Version control (specifically distributed VCS like Git) provides: (1) a complete, auditable history of every change with author and message, (2) the ability to create branches for parallel feature development without affecting the main codebase, (3) the ability to roll back to any previous state if bugs are introduced, and (4) merge and conflict resolution tools when multiple people edit the same file. Shared drives provide none of these capabilities. Version control benefits teams of all sizes. It does not replace code reviews — in fact, it enables them through pull requests.

Question 8

A developer is setting up a new repository and wants to provide an entry point for other contributors — explaining what the project does, how to install it, and how to contribute. Which file serves this purpose by convention?

Accepted Answer

README.md is the conventional entry-point documentation file rendered automatically on the repository's home page on GitHub. It typically describes the project's purpose, installation steps, usage examples, and contribution guidance. CONTRIBUTING.md contains contributor-specific guidelines. CODEOWNERS maps file paths to required reviewers. SECURITY.md describes the project's security policy and vulnerability reporting process.

Question 9

A team wants to create multiple new repositories that all start with the same folder structure, default workflow files, and issue templates. What GitHub feature should they use to standardize new repository creation?

Accepted Answer

Repository templates allow organizations to designate a repository as a template. When creating a new repository, users can select the template to start with its directory structure, files, and branches pre-populated. Forking (A) creates a copy but maintains a fork relationship with the source. Cloning and renaming (C) is a manual workaround. Using Actions to copy files (D) adds unnecessary complexity when templates solve the problem natively.

Question 10

A maintainer wants to understand how their repository is being used and discover potential issues. Which GitHub repository features provide visibility into repository health and usage patterns? Choose 3.

Accepted Answer

Repository Insights > Traffic (A) shows views, unique visitors, clones, and referring sites — key signals for project popularity and reach. The dependency graph (B) shows the project's dependencies and its dependents, and is used by Dependabot for security alerts. Stars (C) are a simple metric of community interest and discoverability. The Actions billing report (D) is an enterprise/org-level billing tool, not a repository health indicator. Feature previews (E) are user-specific toggles for trying beta features, not repository metrics dashboards.

Question 11

A maintainer wants certain files in the repository to be owned by specific teams — so that pull requests touching those files automatically request a review from the owning team. Which file enables this?

Accepted Answer

The `CODEOWNERS` file (stored in the root, `docs/`, or `.github/` directory) maps file path patterns to one or more GitHub users or teams. When a pull request modifies a file matching a pattern, the designated owners are automatically requested for review. This integrates with branch protection rules that require code owner review before merging. The other files (A, C, D) are not recognized GitHub features for automatic review assignment.

Question 12

A QA engineer discovers a bug and wants to formally track it, assign it to a developer, label it as 'bug', and add it to a milestone for the next release. Which GitHub feature is designed for this purpose?

Accepted Answer

GitHub Issues are the native work-item tracking feature — they support titles, descriptions, labels, assignees, milestones, and linking to pull requests. They are the correct tool for tracking bugs, feature requests, and tasks. Gists are for sharing code snippets or notes. Wiki pages are for project documentation. GitHub Discussions are for open-ended community conversations and Q&A, not for structured work tracking.

Question 13

A developer opens a pull request that fixes a known bug. They want the related issue (#42) to close automatically when the pull request is merged into `main`. How should they link them?

Accepted Answer

GitHub supports closing keywords (`Closes`, `Fixes`, `Resolves`, `Fix`, `Close`, `Resolve` — case-insensitive) in pull request descriptions, titles, or commit messages. When the PR is merged into the default branch (or a specified target branch), the linked issue is automatically closed. A comment on the issue (A) creates a reference but does not trigger auto-close. Manual closure (C) works but is not automated. Including the issue number in the branch name (D) is a convention for organization but does not trigger auto-close.

Question 14

A team member is overwhelmed by GitHub email notifications. They want to reduce noise but still be notified when someone directly mentions them or when they are assigned to an issue. Which setting allows this level of control?

Accepted Answer

GitHub's notification settings allow users to distinguish between 'Participating' (direct mentions, assignments, PR review requests, threads you commented in) and 'Watching' (all activity on watched repositories). Setting email or web notifications to 'Participating only' reduces noise while ensuring you are still notified for actions relevant to you. Unwatching repositories you don't actively work on further reduces volume. Unsubscribing from all emails (A) is too aggressive. Deleting existing subscriptions (C) is a one-time cleanup, not a sustainable preference. Bookmarks (D) require manual checking and do not provide notifications.

Question 15

A developer wants to share a one-off Python script with a colleague without creating a full repository. The colleague needs to be able to view, comment on, and fork the script. Which GitHub feature is most appropriate?

Accepted Answer

GitHub Gists are lightweight, version-controlled file snippets. They can be public or secret, support multiple files, and can be forked and commented on by other GitHub users — making them ideal for sharing one-off scripts, configuration snippets, or notes. Creating a full repository (A) is heavier than necessary for a single script. GitHub Pages (C) hosts static websites, not code snippets for sharing and forking. A Discussion post (D) is a conversation format, not designed for code snippet collaboration.

Question 16

A developer is writing a Python function and wants real-time AI-powered code suggestions that complete lines and suggest entire function bodies as they type in VS Code. Which GitHub feature provides this?

Accepted Answer

GitHub Copilot is an AI-powered coding assistant integrated into code editors (VS Code, JetBrains, Neovim, etc.). It provides real-time autocomplete suggestions, can suggest entire functions and blocks of code, and offers chat-based explanations and generation. GitHub Actions automates workflows (CI/CD). Codespaces provides cloud-based dev environments. GitHub Pages hosts static websites.

Question 17

A developer wants to work on a project that requires specific tools and environment variables but cannot install those tools on their local machine due to corporate IT restrictions. Which GitHub feature allows them to develop entirely in a cloud-based environment with a full VS Code experience?

Accepted Answer

GitHub Codespaces provides a fully configured, cloud-hosted development environment running in a container, accessible via browser or VS Code Desktop. It supports custom `devcontainer.json` configurations for installing specific tools, extensions, and environment variables. Because it runs in the cloud, no local installation is needed. GitHub Mobile is for reviewing and managing GitHub on mobile devices. github.dev is a lightweight browser-based editor with limited terminal access — it is not a full development environment. GitHub Actions is for CI/CD automation, not interactive development.

Question 18

A developer wants to quickly view and edit a file in a GitHub repository without cloning it locally or spinning up a full development environment. They navigate to the repository on GitHub.com and press the `.` key on their keyboard. What happens?

Accepted Answer

Pressing `.` (period) on a GitHub repository page opens it in github.dev — a fast, browser-based editor that loads the VS Code interface with the repository's files for reading and editing. github.dev does not have a compute backend (no terminal, no running processes), distinguishing it from Codespaces. It is ideal for quick edits and navigation. Pressing `.` does not start a Codespace (that requires navigating to Code > Codespaces), does not preview the README, and does not create a pull request.

Question 19

A project manager wants to visualize the team's backlog in a spreadsheet-style view where they can group items by status, sort by priority, and add custom fields. Which GitHub Projects layout supports this?

Accepted Answer

GitHub Projects supports multiple layouts: Table (spreadsheet/list view with custom fields, sorting, grouping, and filtering), Board (Kanban columns), and Roadmap (timeline view). The Table layout is best suited for a backlog view where custom fields, sorting by priority, and grouping by status are needed. The Board layout is for workflow state visualization. The Roadmap is for date-based planning. The Burndown chart is an Insights feature within Projects, not a primary layout.

Question 20

A developer frequently types the same responses to first-time contributors (e.g., 'Thank you for your contribution! Please read our CONTRIBUTING.md first.'). How can they save and reuse this response in GitHub without third-party tools?

Accepted Answer

GitHub Saved Replies (accessible in user account settings) allow you to save frequently used comment text and insert them into issue or PR comments with a few clicks. They are personal to the user account and available in any repository. Issue templates (A) pre-fill new issue creation, not comment responses. Pinning a comment on a pinned issue (C) is static and requires contributors to find it. Linking to CONTRIBUTING.md (D) requires manual message crafting each time.

Question 21

An organization administrator wants to prevent members from contributing to repositories outside the organization's owned repositories while keeping their accounts accessible for internal collaboration. Which access control feature achieves this without removing users?

Accepted Answer

Enterprise Managed Users (EMU) is the GitHub feature specifically designed to restrict user accounts to enterprise-controlled resources — EMU users cannot contribute to repositories outside the enterprise's organizations. The other options do not restrict where organization members can contribute externally: 2FA (A) improves authentication security. Setting default repo permission to 'None' (B) controls access within the organization, not external contributions. Making repositories private (C) controls visibility, not member activity on other platforms.

Question 22

An administrator wants to enforce rules on the `main` branch of a repository so that: (1) no one can push directly, (2) at least one approval is required on pull requests, and (3) CI checks must pass. Which GitHub features can be configured to enforce these rules? Choose 2.

Accepted Answer

Both branch protection rules (A) and repository rulesets (B) are native GitHub mechanisms that can enforce all three requirements: blocking direct pushes to `main`, requiring a minimum number of PR approvals, and requiring CI status checks to pass before merging. Rulesets are the newer, more flexible approach that supports organization and enterprise-level enforcement. A workflow that closes failing PRs (C) is a workaround and does not block merging. CODEOWNERS (D) assigns reviewers but does not by itself block merging without approval. Making the repo private (E) controls visibility, not branch protection.

Question 23

A user's GitHub account was compromised because their password was leaked in a third-party data breach. The attacker logged in and pushed malicious code to several repositories. Which account security feature would have prevented unauthorized access even with the correct password?

Accepted Answer

Two-factor authentication requires a second verification factor (a time-based one-time password from an authenticator app, a hardware security key like a YubiKey, or a passkey) in addition to the password. Even if an attacker obtains the correct password from a data breach, they cannot log in without the second factor. A strong password (A) helps prevent brute-force attacks but does not protect against credential theft in breaches. Email notifications (C) alert you after the fact but do not prevent access. Fine-grained PATs (D) are for API access, not for protecting the main account login.

Question 24

A developer wants to contribute to an open-source project they do not have write access to. They want to make changes and propose them back to the original project. What is the correct first step?

Accepted Answer

The standard open-source contribution workflow on GitHub is: Fork the repository (creates a copy in your account), clone your fork locally, make changes on a branch, push the branch to your fork, then open a pull request from your fork to the original (upstream) repository. You cannot push directly to a repository you don't have write access to (A). Asking maintainers to make changes for you (C) is appropriate only for suggesting, not contributing. Emailing changes (D) bypasses the entire GitHub collaboration workflow.

Question 25

A company wants to apply open-source collaboration principles (transparent contribution, issue tracking, pull request reviews, and shared documentation) to their internal software development across departments — without making any code public. Which term describes this practice and which GitHub features support it? Choose 2.

Accepted Answer

InnerSource (A) is the practice of adopting open-source collaboration methodologies (pull requests, issues, transparent review) for internal software development, keeping code private to the organization. GitHub supports this with 'internal' repository visibility (B, available in organizations under GitHub Enterprise), which makes repositories visible to all organization/enterprise members but not to the public — enabling InnerSource without exposure. 'OuterSource' (C) is not a real term. GitHub Pages can host documentation but is not specifically the InnerSource portal tool. InnerSource can be implemented on both GHEC and GHES (E is incorrect).

GH-900 — GitHub Certified: GitHub Foundations