Explanation:
The GitHub personal dashboard (the home page when logged in) shows activity from repositories and users that a person follows. This activity includes pushes, pull requests, issues, and comments from public repositories. Understanding what sources populate the dashboard helps users customize their feed to see relevant updates without noise from unrelated projects.

Correct Option:

✅ B – people
When you follow another GitHub user, their public activity (e.g., creating a repository, opening an issue, pushing commits, starring a repo) appears on your personal dashboard. This is similar to social media following. Following key developers, maintainers, or community leaders curates a feed of interesting activity from individuals you want to track.

✅ E – organizations
When you watch repositories owned by an organization or follow the organization itself, public activity from those repositories appears on your dashboard. While GitHub's feed behavior has evolved, watching repositories within organizations and having organization activity visible is standard. Organizations act as a source of activity similar to following individual users or watching specific repos.

Incorrect Option:

❌ A – teams
Teams are internal groups within an organization used for permission management. Following or watching a team does not populate public activity on your personal dashboard. Teams are not designed as content feeds; they manage access to repositories. Activity from team members appears only if you follow the individual people or watch specific repositories.

❌ C – enterprises
Enterprises are administrative containers for multiple organizations (GitHub Enterprise feature). You cannot "follow" an enterprise to see public activity. Enterprises provide centralized policy and billing management, not social feeds. Public activity from repositories under an enterprise appears only if you follow the organization, repository, or individual users.

❌ D – stars
Starring a repository bookmarks it but does not automatically add its public activity to your personal dashboard. Starring is for saving favorites and showing appreciation, not for subscribing to activity. To see activity from a starred repository, you must additionally "watch" the repository. Stars alone do not generate dashboard feed items.

Reference:
GitHub Docs – "About your personal dashboard" – Your dashboard shows activity from repositories you watch and users you follow. Following people and watching organizations/repositories are the primary sources. Teams, enterprises, and starring alone do not populate the feed. Stars are bookmarks; watching controls feed visibility.

Explanation:
When creating a new repository on GitHub, the web interface provides optional checkboxes to automatically initialize the repository with common files. These files help establish project documentation, licensing, and version control best practices from the start. Knowing which options are available prevents manually adding these files later via command line or file uploads.

Correct Option:

✅ C – README, .gitignore, and LICENSE
During repository creation, GitHub offers three optional files: (1) README.md – a markdown file describing the project; (2) .gitignore – a template file specifying which files Git should ignore (e.g., build artifacts, dependencies); (3) LICENSE – a file containing the open source license (e.g., MIT, GPL, Apache). These are the only three file types automatically addable via the creation wizard.

Incorrect Option:

❌ A – README, -git, and DOCS
"‑git" is not a valid file; the correct file is .gitignore (note the leading dot and "ignore"). "DOCS" is not an automatic creation option; documentation typically lives in docs/ folder or README. This option contains a typo and a non-existent feature. Only README is correct; the other two are wrong.

❌ B – LICENSE, .git, and README
.git is the internal directory where Git stores version control metadata (commits, branches, config). It is never automatically added by the user during repository creation; Git initializes it automatically behind the scenes. Users cannot "automatically add" .git via checkboxes. This option confuses a system directory with optional user files.

❌ D – LICENSE, DOCS, and .gitignore
"DOCS" is not a file type offered by GitHub during repository creation. While you can manually create a docs/ folder or documentation files, GitHub does not provide an "Add DOCS" checkbox. This option substitutes DOCS for README, which is incorrect. README is the standard and only documentation file offered in the creation wizard.

Reference:
GitHub Docs – "Creating a new repository" – On the new repository form, you can select "Add a README file," "Add .gitignore," and "Choose a license." No other automatic file creation options (e.g., DOCS, .git, -git) are provided. These three files help users quickly set up a standardized project structure.

Explanation:
GitHub allows users to create a new repository from an existing template repository. This feature is designed to quickly replicate a standardized project structure, including files, folders, and branch settings. However, certain dynamic elements like collaboration history, open pull requests, and contributor lists are intentionally excluded to provide a clean starting point for the new project.

Correct Option:

✅ A – Default branch
When creating a repository from a template, the new repository will contain the default branch (usually main or master) of the template repository. All files, folders, and directory structure from that default branch are copied exactly. Additionally, the new repository inherits the template's default branch setting, meaning the branch name and its status as default are preserved.

Incorrect Option:

❌ B – contributors
The new repository does not retain the contributor list from the template repository. Contributors are user-specific metadata tied to commit history and repository access. Since the new repository starts with a fresh commit (even if the same files exist), only the user creating the new repository appears as the initial contributor. Previous contributors are not copied over.

❌ C – commit history
Commit history is not copied when creating a repository from a template. The new repository receives the current file state of the default branch, but without the underlying Git commit history. The first commit in the new repository is often generated by GitHub (e.g., "Initial commit from template") or by the creator. This ensures a clean, linear history.

❌ D – pull requests
Pull requests are not copied from the template repository. Pull requests are associated with specific branches, commits, reviews, and discussions that belong to the original repository's timeline. Since commit history and contributor data are not replicated, pull requests are also excluded. The new repository starts without any open or closed pull requests.

Reference:
GitHub Docs – "Creating a repository from a template" – The new repository includes all files and folders from the template's default branch but does not include commit history, pull requests, issues, or collaborators. Repository settings (e.g., branch protection rules) are also copied. Contributors and pull requests are explicitly excluded.

Explanation:
GitHub Actions is a CI/CD and automation platform that allows you to build, test, and deploy code directly from your repository. It has a specific architecture composed of modular components that work together to define and execute workflows. Understanding these core components is essential for writing and troubleshooting automation pipelines.

Correct Option:

✅ C – events
An event is a specific activity that triggers a workflow. Examples include push, pull_request, issues, schedule (cron), workflow_dispatch (manual), and release. Events are the "trigger" component of GitHub Actions. When an event occurs, GitHub checks if any workflows in the repository are configured to run on that event and then executes them.

✅ D – steps
A step is an individual task within a job. Each step can run either a shell command (e.g., run: npm test) or an action (e.g., uses: actions/checkout@v4). Steps are executed sequentially in the same runner environment. They are the smallest executable unit in a workflow and can share data with each other (e.g., via environment variables or files).

✅ G – jobs
A job is a collection of steps that execute on the same runner (virtual machine or container). Jobs run in parallel by default, but you can configure dependencies so one job waits for another (using needs). Each job has its own runner instance. Jobs group related steps together (e.g., a "build" job, a "test" job, and a "deploy" job).

Incorrect Option:

❌ A – JavaScript
JavaScript is a programming language, not a component of GitHub Actions. While GitHub Actions supports JavaScript-based custom actions, JavaScript itself is not a structural component like events, jobs, or steps. Actions can be written in JavaScript or Docker, but the language choice is an implementation detail, not a core component.

❌ B – agents
"Agent" is a Microsoft Azure Pipelines term for what GitHub Actions calls a "runner." GitHub Actions uses the term runner, not agent. While conceptually similar (a machine that executes jobs), "agent" is not the correct terminology for GitHub Actions components. The official components are runners, not agents.

❌ E – CI/CD
CI/CD (Continuous Integration/Continuous Deployment) is a software development practice, not a component of GitHub Actions. GitHub Actions can be used to implement CI/CD pipelines, but the practice is separate from the platform's architectural components. Confusing a use case with a component is incorrect.

❌ F – octokit
Octokit is a set of client libraries (e.g., octokit/rest.js) for interacting with the GitHub API. It is a development tool, not a component of GitHub Actions. While workflows can use octokit in custom scripts, octokit is external to the GitHub Actions core architecture, which consists of workflows, events, jobs, steps, runners, and actions.

Reference:
GitHub Docs – "Understanding GitHub Actions" – Core components include: Workflows, Events, Jobs, Steps, Actions, and Runners. JavaScript is a language for custom actions. Agents is an Azure term. CI/CD is a practice. Octokit is an API client library. Events, steps, and jobs are explicitly listed as core components.

Explanation:
GitHub offers two browser-based code editing experiences: github.dev (lightweight, instant editor) and Codespaces (full cloud development environment). While they share a similar VS Code-based interface, they have significant differences in capabilities, especially regarding compute resources, terminal access, and customization. Understanding these differences helps users choose the right tool for their task.

Correct Option:

✅ D – Codespaces provides terminal access
This is a key differentiator. Codespaces provides a full Linux virtual machine (or container) with root access, a fully functional terminal, the ability to install system packages, run build commands, debug applications, and execute tests. In contrast, github.dev is a browser-based editor that connects directly to the repository on GitHub without a compute backend; it has no terminal, cannot run code, and only supports basic file editing and Git operations.

Incorrect Option:

❌ A – Extensions in the Visual Studio Code Marketplace are supported by github.dev
Both github.dev and Codespaces support VS Code extensions from the Marketplace. This is not a differentiator; they share the same extension system. While some extensions requiring a terminal or local compute may not function in github.dev, extension support itself exists in both. Therefore, this statement does not correctly identify a difference.

❌ B – Codespaces is available within the web browser
Both github.dev and Codespaces are available within a web browser. github.dev is accessed by pressing the period (.) key on a repository, while Codespaces is accessed via the "Code" button or github.com/codespaces. Both run in the browser. This statement describes a similarity, not a difference, making it incorrect for this question.

❌ C – A free monthly quota for personal accounts is provided by github.dev
github.dev has no quotas because it uses no compute resources; it is entirely free and unlimited. Codespaces provides a free monthly quota (e.g., 120 core-hours or 60 hours on a 2-core machine for personal accounts). Stating that github.dev provides a quota is misleading; it has no quota because it consumes no resources. This does not correctly distinguish the two.

Reference:
GitHub Docs – "github.dev vs GitHub Codespaces" – github.dev is a lightweight editor with no compute power, no terminal, and no ability to run or debug code. Codespaces is a full development environment with terminal, build tools, debugging, and customizable resources. Extension support exists in both, and both work in a browser. Quotas apply only to Codespaces.

Explanation:
Branching is one of Git's most powerful features, distinguishing it from older version control systems. Unlike SVN or CVS, Git makes branching incredibly lightweight and fast. Understanding why branching is a core concept requires recognizing the development workflows it enables, particularly around isolation and experimentation without disrupting stable code.

Correct Option:

✅ D – Branching creates an isolated environment to try new ideas and make changes without affecting other branches
This is the fundamental reason branching is central to Git. Branches allow developers to work on features, bug fixes, or experiments in complete isolation from the main codebase (e.g., main or develop). Changes made in one branch have no impact on other branches until explicitly merged. This isolation enables parallel development, safe experimentation, and code review before integration.

Incorrect Option:

❌ A – Branching creates physical copies of the project on disk, ensuring data redundancy and backup
This is false. Git branches are lightweight pointers to specific commits, not physical copies of files. Creating a branch does not duplicate the entire project on disk; it simply creates a new reference (a file in .git/refs/heads/). This is why Git branching is nearly instantaneous and uses minimal disk space. Data redundancy and backup are separate concerns (e.g., pushing to remotes).

❌ B – Branching helps in automatically merging changes from different branches into the main branch
Merging is not automatic; it requires a manual command (git merge) or a pull request. Branching itself does not perform merging. While branches enable merging workflows, the automatic merging claim is incorrect. Git can sometimes auto-resolve merges without conflicts, but this is a result of the merge process, not a property of branching.

❌ C – Branching is necessary for organizing files and folders within a Git repository
Branching has nothing to do with file/folder organization within a repository. Git tracks content, not separate folders per branch. All branches share the same repository structure. File organization is managed by the directory tree and .gitignore. Branching is about isolating commit histories, not structuring files.

Reference:
Pro Git Book – "Git Branching – Branches in a Nutshell" – A branch in Git is a lightweight movable pointer to a commit. Creating a branch is fast and creates an isolated environment for parallel development. Git's branching model is often cited as its killer feature, enabling experimentation and collaboration without interfering with stable code.

Explanation:
GitHub allows users to write formatted text in comments on issues, pull requests, discussions, and commit messages. While the platform displays code snippets in various programming languages with syntax highlighting, the actual language used to author and format the comment text itself (including headings, lists, links, bold/italic text, and code blocks) is a specific lightweight markup language.

Correct Option:

✅ C – Markdown
GitHub comments are authored using Markdown, specifically GitHub Flavored Markdown (GFM). This lightweight markup language allows users to add formatting such as headings, lists, bold/italic text, links, images, task lists, tables, and code blocks with language-specific syntax highlighting. Markdown is human-readable in its raw form and renders to HTML on GitHub. It is the standard for all user-generated text content on the platform.

Incorrect Option:

❌ A – CSS
CSS (Cascading Style Sheets) is a styling language used to control the visual presentation of web pages. It is not used for authoring GitHub comments. While you can include CSS code within a Markdown code block for demonstration purposes, the comment text itself is written in Markdown, not CSS.

❌ B – JavaScript
JavaScript is a programming language for adding interactivity to web pages. It is not used to author GitHub comments. GitHub does not execute JavaScript from user comments for security reasons. Comments are static text formatted with Markdown. JavaScript code may appear inside code blocks as examples, but it is not the comment authoring language.

❌ D – JSON
JSON (JavaScript Object Notation) is a lightweight data interchange format, not a text formatting language. You cannot write a GitHub comment in JSON and expect headings or lists to render. JSON may appear in code blocks within Markdown comments, but the comment itself must be authored in Markdown. JSON has no native rendering for rich text.

❌ E – XML
XML (Extensible Markup Language) is a markup language designed for data storage and transport, not for authoring human-readable formatted comments. GitHub does not support XML as a comment formatting language. While Markdown is also a markup language, XML is verbose, not human-friendly for writing, and not used for GitHub comments.

❌ F – own
There is no language called "own" in this context. This appears to be an incomplete or placeholder option in the original question. GitHub does not have a proprietary comment language; it uses standard Markdown.

Reference:
GitHub Docs – "About writing and formatting on GitHub" – GitHub supports GitHub Flavored Markdown (GFM) for comments, issues, pull requests, discussions, and README files. Markdown is the standard. CSS, JavaScript, JSON, and XML are programming or data languages, not text formatting languages for comments.

Explanation:
GitHub Codespaces are cloud-based development environments that can be stopped, resumed, and reconnected to from various entry points. Understanding how to resume an existing codespace (rather than creating a new one) is important for maintaining workflow continuity and avoiding unnecessary resource usage. GitHub provides multiple methods to reconnect to a previously created codespace bound to a specific repository.

Correct Option:

✅ B – Browse to the repository in GitHub.com, press the comma V key and select Resume this codespace
Pressing the comma key (,) followed by the V key is a keyboard shortcut that opens the "Codespaces" menu for the current repository. From this dropdown, you can see all existing codespaces associated with that repository and select one to resume. This method works directly from the repository page without leaving the browser tab.

✅ C – Open https://github.com/codespaces in the browser, select the repository, and then select the existing Codespace
The central Codespaces dashboard at github.com/codespaces lists all codespaces across all repositories owned by the user. From this page, you can click on any existing codespace entry to resume it. This method is useful when you don't remember which repository the codespace belongs to or want a global view of all your environments. Incorrect Option:

❌ A – Use the git CLI with the codespace parameter (e.g., "git codespace code -web")
The standard Git CLI does not have any codespace subcommand. Git is a version control system, not a Codespace management tool. To interact with Codespaces from the command line, you need the GitHub CLI (gh) with the gh codespace command. The example given uses git codespace, which does not exist.

❌ D – Browse to the repository in GitHub.com and press the period "." key
Pressing the period (.) key on a repository page launches github.dev, which is a lightweight, browser-based VS Code editor that opens the repository directly on GitHub's servers. This creates a new, temporary editing session, not a Codespace. It does not resume an existing Codespace and is a completely separate feature.

Reference:
GitHub Docs – "Resuming an existing codespace" – Methods include using the github.com/codespaces dashboard and using the repository's "Codespaces" menu (accessed via comma+V shortcut). The period key launches github.dev, not Codespaces. Git CLI does not manage codespaces; GitHub CLI (gh codespace) is the correct command-line tool.

Explanation:
GitHub offers several collaboration features, each designed for specific use cases such as task tracking, documentation, or community discussion. Polling—a way to conduct votes or surveys—is not available in all features. Only one of these options provides a native, structured way to create multiple-choice polls for gathering feedback from contributors or community members.

Correct Option:

✅ C – Discussions
GitHub Discussions includes a native Polls category. When you start a new discussion in a repository or organization, you can choose the "Polls" category, which allows you to create a multiple-choice question with up to 10 options. Participants can vote, and results are displayed in real time. This is the only GitHub feature with built-in polling functionality.

Incorrect Option:

❌ A – Issues
Issues are used for tracking bugs, tasks, and feature requests. They do not have a native polling feature. While you can informally gather opinions by asking for emoji reactions (👍/👎) on a comment, this is not a structured poll. GitHub does not provide vote counting, multiple-choice options, or result aggregation in Issues.

❌ B – Projects
Projects are project management boards (similar to Trello or Jira) used to organize and track work items such as issues and pull requests. They do not support polling in any form. Projects focus on workflow status (e.g., "To Do," "In Progress," "Done") and cannot host surveys or multiple-choice questions.

❌ D – Wikis
Wikis are static documentation areas where teams can write guides, policies, or technical references using Markdown. They do not support any interactive features like polling, voting, or forms. Wikis are purely for reading and editing text-based documentation, not for gathering feedback or conducting surveys.

Reference:
GitHub Docs – "About discussions" – Discussions supports four category types: Announcements, Ideas, Polls, and Q&A. The Polls category is explicitly designed for creating multiple-choice surveys. Issues, Projects, and Wikis lack any polling functionality. For structured voting, Discussions is the correct and only native GitHub feature.

Explanation:
GitHub introduced achievements (also known as "Achievement Badges") on user profiles to recognize notable accomplishments and engagement milestones within the GitHub ecosystem. These badges appear on profile pages alongside other metrics. Understanding what achievements represent helps users distinguish them from other profile elements like repository counts or star tallies.

Correct Option:

✅ A – special recognition for significant contributions and milestones
GitHub achievements are badges awarded for reaching specific milestones, such as "Arctic Code Vault Contributor" (code archived in the Arctic), "Galaxy Brain" (answer accepted in a Q&A discussion), "Pull Shark" (merged pull requests), "YOLO" (merged a PR without review), and "Heart On Your Sleeve" (emoji reactions received). These are special recognitions, not automated metrics.

Incorrect Option:

❌ B – total number of repositories owned
The total number of repositories owned by a user appears as a simple numeric counter on the profile page (e.g., "15 repositories"), not as an achievement badge. Achievements are visual icons with specific names and unlocking criteria. Counting repositories is a basic profile statistic, not a special recognition.

❌ C – number of stars received on repositories
Stars received on repositories appear as a cumulative star count below the repository section. This is a metric of popularity, not an achievement. While GitHub does not currently award a badge for total stars, achievements are milestone-based (e.g., "Heart On Your Sleeve" for emoji reactions, not stars). Stars are separate.

❌ D – virtual trophies awarded for completing coding challenges
GitHub does not host coding challenges or award trophies for completing them. This describes platforms like HackerRank, LeetCode, or Codewars. GitHub achievements are earned through real-world collaboration on the platform (e.g., merging PRs, opening discussions, sponsoring projects), not through artificial challenge completion.

Reference:
GitHub Docs – "GitHub Achievements" – Achievements recognize special milestones such as participation in the Arctic Code Vault, merged pull requests, accepted answers, and reaction counts. They are distinct from repository counts, star counts, and third-party challenge platforms. Achievements appear as badges on the profile overview.