How to Pass GITHUB FOUNDATION Exam?

with Microsoft Copilot: Your everyday AI companion

https://resources.github.com/learn/certifications/

Get ready with assurance

Start your path to GitHub Foundation certification achievement with a thorough study guide. This selected resource provides you with our suggested knowledge resources, learning objectives, and assessment questions to help you ace your certification exam.

you can download the study guide from this link: https://assets.ctfassets.net/wfutmusr1t3h/1kmMx7AwI4qH8yIZgOmQlP/79e6ff1dfdee589d84a24dd763b1eef7/github-foundations-exam-study-guide__1_.pdf

If you look carefully, there’s an Objective Domains: An objective domain for a certification exam, often referred to as a “domain” or “exam domain,” is a
structured outline or framework that defines the specific knowledge, skills, and topics that the certification exam will cover. It provides a clear roadmap for what candidates should expect to encounter on the exam
and what they need to study and prepare for. The domains provided in this study guide are intended to provide insight into the topic categories covered in the GitHub Foundations exam, along with the learning objective within each domain.

latest Reference: 3 March 2024.

Now, in order to prep-up for all the above domains there are multiple questionnaire in each domains outlined in study guide. Where, I seek help from Microsoft Copilot: Our everyday AI Companion who assisted me in getting all the clarifications and simplified responses which helped me in clearing the Github Foundation Exam.

Domain 1: Introduction to Git and GitHub

Q. Describe version control

→ Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. 1 Version control is useful for software development, where multiple developers may work on the same code base and need to track and merge their changes. Version control also helps to prevent data loss, improve collaboration, and facilitate testing and debugging. Some of the common features of version control systems are:

• Branching: The ability to create a separate copy of the code base for working on a new feature, bug fix, or experiment without affecting the main code base. 3
• Merging: The ability to combine the changes from different branches into a single code base, resolving any conflicts that may arise. 3
• Committing: The act of saving a snapshot of the code base with a message describing the changes made. 3
• Reverting: The ability to undo a commit or a merge and restore the code base to a previous state. 3
• History: The ability to view the list of commits and merges that have been made to the code base, along with the messages, timestamps, and authors. 3
• Diffing: The ability to compare the differences between two versions of the code base, or between the code base and the working copy. 3

This diagram shows how a centralized version control system works. The developers connect to a server that stores the code base and the history. They can check out the latest version of the code, make changes, and commit them back to the server.

This diagram shows how a distributed version control system works. The developers have their own local copies of the code base and the history. They can make changes and commit them locally, and then synchronize them with a remote repository.

This diagram shows how branching and merging work in version control systems. The developers can create separate branches of the code base for different purposes, such as developing new features, fixing bugs, or experimenting. They can then merge their changes back to the main branch, or to another branch, after resolving any conflicts.

Q. Define distributed version control

→ Distributed version control is a form of version control in which the complete codebase, including its full history, is mirrored on every developer’s computer. 1 This allows developers to work offline, branch and merge locally, and synchronize changes with a remote repository. 2 Distributed version control systems, such as Git, Mercurial, and Bazaar, are faster, more reliable, and more flexible than centralized version control systems, such as Subversion. 3

Q. Describe Git

→ Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Here are some key points about Git:

1. Distributed Version Control:

• Git follows a distributed model, where each developer has their own local repository.
• Changes are synchronized between local repositories and a central remote repository.
• This decentralization allows for offline work, faster operations, and redundancy.

1. Features:

• Cheap Local Branching: Developers can create branches easily without network access.
• Convenient Staging Areas: Git allows selective staging of changes before committing.
• Multiple Workflows: Supports various workflows (feature branches, Gitflow, etc.).

1. Advantages:

• Speed and Efficiency: Git performs quickly even with large projects.
• Branching and Merging: Easy branching and merging for collaborative development.
• Widely Used: Git is the foundation for platforms like GitHub and GitLab.

1. Basic Workflow:

• Developers clone a repository to their local machine.
• They make changes, stage them, and commit to their local repository.
• Changes are pushed to a remote repository for collaboration.

1. Resources:

• Official Git Documentation
• GitHub: A popular platform for hosting Git repositories.

Remember that Git is essential for managing source code in software development projects, enabling collaboration, version tracking, and efficient code management. 🚀

Q. Describe GitHub

→ GitHub is a developer platform that allows developers to create, store, manage, and share their code. Here are some key points about GitHub:

1. Version Control System:

• GitHub uses Git, a popular distributed version control system.
• Developers can track changes to their code, collaborate with others, and manage software projects.

1. Features:

• Repositories: Developers create repositories to organize their code.
• Collaboration: Multiple developers can work on the same project.
• Issues and Bug Tracking: Developers can report and track issues or bugs.
• Pull Requests: Developers propose changes and request code reviews.
• Continuous Integration: Integrates code changes automatically.
• Wikis: Provides documentation for projects.

1. Open Source Hosting:

• GitHub is widely used for hosting open source software projects.
• It allows developers to contribute, fork, and collaborate on public repositories.

1. Key Facts:

• Founded in 2008 by Tom Preston-Werner, Chris Wanstrath, P. J. Hyett, and Scott Chacon.
• Acquired by Microsoft in 2018.
• Over 100 million developers use GitHub.
• Hosts more than 420 million repositories, including millions of public ones.

In summary, GitHub is a powerful platform that facilitates collaboration, code management, and community-driven development. 🚀

Q. Explain the difference between Git and GitHub

Q. Describe a GitHub repository

→ GitHub repository is and its key features:

Definition:

• A repository (often referred to as a repo) is the most fundamental element in GitHub.
• It serves as a place to store your code, files, and each file’s revision history.
• Repositories can be either public (visible to everyone) or private (restricted access).

Key Aspects:

• Code Storage: Repositories hold your project’s source code, documentation, and other files.
• Collaboration: Multiple developers can work together within a repository.
• Version Control: Git manages the revision history of files within the repository.
• Branching and Merging: Developers can create branches to work on specific features or fixes.
• Issues and Bug Tracking: Repositories allow users to report issues, track bugs, and organize tasks.
• Pull Requests: Developers propose changes and request code reviews.
• Projects and Wikis: Repositories can have associated project boards and wikis.

Creating a Repository : To create a new repository on GitHub;

1. Go to GitHub’s New Repository page.
2. Choose a name for your repository (e.g., “my-project”).
3. Specify whether it should be public or private.
4. Optionally, add a description and choose other settings.
5. Click “Create repository.”

Collaboration and Ownership:

• Repositories can have multiple collaborators who work together.
• Ownership can be individual (personal account) or shared within an organization.
• Access permissions are managed through roles and permissions.

Visibility:

• Public Repositories: Often used for open source software, freely accessible to everyone.
• Private Repositories: Restricted access, visible only to authorized collaborators.

Remember that GitHub repositories are essential for managing code, collaborating with others, and organizing your projects. They play a crucial role in software development and version control. 🚀

Q. Describe a commit

→ A commit is a fundamental concept in Git and other version control systems. Here are the key points:

Definition:

• A commit represents a snapshot of your project at a specific point in time.
• It captures changes made to files (additions, modifications, deletions) since the last commit.

Purpose:

• Commits serve as save points for your code.
• They allow you to track the history of your project and revert to previous states if needed.

Components of a Commit:

• Content: The actual changes made to files (code, text, etc.).
• Author: The person who made the changes.
• Timestamp: When the commit was created.
• Commit Message: A brief description of what the commit accomplishes.

Creating a Commit:

• Developers use the git commit command to create a commit.
• Before committing, they stage changes using git add.
• The commit message should be descriptive and concise.

Commit Hash (SHA-1):

• Each commit is identified by a unique hash (usually a long alphanumeric string).
• This hash allows you to reference a specific commit.

Commit Workflow:

• Developers work on their code, make changes, and test.
• When satisfied, they stage and commit their changes.
• Commits are organized in a commit history.

Benefits:

• Version Tracking: Commits provide a detailed history of your project.
• Collaboration: Multiple developers can work on different branches and merge their commits.

Example Commit Message:

Commit: Fix bug in login validation 
- Updated login form validation to handle edge cases. 
- Resolved issue with password validation.

Remember that commits are essential for tracking progress, collaborating with others, and maintaining a reliable history of your project. 🚀

Q. Describe Branching

→ A branch is a fundamental concept in Git and other version control systems. Here are the key points:

Definition:

• A branch represents an independent line of development within a Git repository.
• It allows developers to work on separate features, bug fixes, or experiments without affecting the main codebase.

Purpose:

• Branches enable parallel development by allowing multiple tasks to progress simultaneously.
• They prevent conflicts by isolating changes until they are ready for integration.

Creating a Branch:

• Developers create branches using the git branch command.
• A new branch starts from an existing commit (usually the main branch).
• Changes made in a branch do not affect other branches.

Common Branch Types:

• Feature Branch: Created for developing a specific feature or enhancement.
• Bugfix Branch: Isolated branch for fixing a specific bug.
• Release Branch: Used for preparing a new release version.
• Hotfix Branch: Created to address critical issues in production.

Workflow:

• Developers switch to a branch using git checkout.
• They make changes, commit them, and push to the branch.
• When ready, changes are merged back into the main branch (e.g., main or master).

1. Visual Representation:

Best Practices:

• Keep branches short-lived and focused.
• Regularly merge changes from the main branch into feature branches.
• Delete branches after merging to keep the repository clean.

Remember that branches are essential for organizing development efforts, collaborating, and maintaining a structured codebase. 🌿

Q. Define a remote in Git terminology

→ In Git terminology, a remote refers to a common repository that all team members use to exchange their changes. Here are the key points about remotes:

• A remote is typically stored on a code hosting service like GitHub, GitLab, or an internal server.
• It allows developers to collaborate by sharing code changes.

Characteristics:

• A remote repository does not provide a file tree of the project’s current state; it only consists of the .git versioning data.
• Remotes enable communication between local repositories and the central repository.

Usage:

• Developers can push their local changes to a remote repository.
• They can also pull changes from the remote repository into their local branches.
• Common commands related to remotes include git clone, git push, and git pull.

Example:

• If you’re using the Tower Git client, managing remote repositories is straightforward. You can access connected remotes through the sidebar.

Remember that remotes facilitate collaboration and allow developers to work together on shared projects. They play a crucial role in distributed version control systems like Git. 🌐🚀

Q. Describe the GitHub Flow

→ GitHub flow, a lightweight and effective workflow for collaborating on projects using Git and GitHub. GitHub flow simplifies the development process and encourages continuous integration. Here are the key steps:

1. Create a Branch:

• Start by creating a new branch in your repository.
• Give it a descriptive name related to the feature or task you’re working on.
• For example, feature/add-login-page or bugfix/fix-api-call.

1. Make Changes:

• Switch to your branch and make the necessary changes to your code.
• Commit your changes with clear and concise commit messages.

1. Push Changes to Remote:

• Push your branch to the remote repository (usually on GitHub).
• This allows others to see your work and collaborate.

1. Open a Pull Request (PR):

• Create a pull request to merge your branch into the main branch (often main or master).
• Describe the purpose of your changes in the PR description.
• Request feedback from collaborators.

1. Review and Discuss:

• Collaborators review your code, leave comments, and suggest improvements.
• Address feedback by making additional commits to your branch.

1. Merge the Pull Request:

• Once the changes are approved and tested, merge the PR into the main branch.
• This integrates your changes into the project.
• Optionally, delete the branch after merging.

1. Continuous Integration (CI):

• Set up automated tests and checks (CI) to ensure code quality.
• CI tools (like GitHub Actions or Travis CI) run tests on your branch before merging.

1. Repeat for New Features:

• For each new feature or bug fix, create a new branch and follow the same process.

GitHub flow encourages collaboration, transparency, and a smooth development experience. It’s widely used for open source projects, team workflows, and individual contributions. 🌟

Q. Describe the different GitHub accounts (personal, organization, enterprise)

→ The different types of GitHub accounts:

Personal Accounts:

• Definition: Every individual who uses GitHub signs up for a personal account.
• Identity: Your personal account represents you as an individual.
• Features:
• Has a username and profile (e.g., @octocat).
• Can own repositories, packages, and projects.
• Actions taken on GitHub (e.g., creating issues, reviewing pull requests) are attributed to your personal account.
• Plans:
• Personal accounts can use either GitHub Free or GitHub Pro.
• Unlimited public and private repositories with unlimited collaborators.
• GitHub Pro provides additional features for private repositories.

Organization Accounts:

• Definition: Organizations are shared accounts where multiple people collaborate across many projects.
• Ownership: Organizations own resources like repositories, packages, and projects.
• Access:
• Each person signs in with their personal account.
• Actions taken on organization resources are attributed to their personal accounts.
• Roles:
• Members within an organization have different roles (e.g., owners, security managers).
• Collaboration occurs in repositories and projects.
• Only owners and security managers manage organization settings.
• Use Case: Ideal for teams working together on shared projects.

Enterprise Accounts:

• Definition: Enterprise accounts allow central management of multiple organizations.
• Scope: Enterprises manage multiple organizations under a single umbrella.
• Features:
• Enhanced security and administrative features.
• Centralized control over access and data.
• Customized workflows and integrations.
• Use Case: Large companies or institutions with complex organizational structures.

Remember that personal accounts are for individual work, organization accounts enhance collaboration, and enterprise accounts provide centralized management. Choose the type that best suits your needs! 🌟

Q. Describe GitHub’s products for personal accounts (free, pro)

→ The different GitHub products available for personal accounts:

GitHub Free for Personal Accounts:

• Features:
• Work with unlimited collaborators on unlimited public repositories with a full feature set.
• Work on unlimited private repositories with a limited feature set.
• Includes GitHub Community Support.
• Dependabot alerts for security vulnerabilities.
• Deployment protection rules for public repositories.
• Two-factor authentication enforcement.
• 500 MB GitHub Packages storage.
• 120 GitHub Codespaces core hours per month.
• 15 GB GitHub Codespaces storage per month.
• GitHub Actions features: 2,000 minutes per month.
• Ideal for individual developers and small projects.

GitHub Pro:

• Includes all features from GitHub Free for Personal Accounts, plus:
• GitHub Support via email.
• 3,000 GitHub Actions minutes per month.
• 2 GB GitHub Packages storage.
• 180 GitHub Codespaces core hours per month.
• 20 GB GitHub Codespaces storage per month.
• Advanced tools and insights in private repositories:
• Required pull request reviewers.
• Protected branches.
• Code owners.
• Auto-linked references.
• GitHub Pages (private publishing requires an organization account).
• Repository insights graphs (e.g., Pulse, contributors, traffic).
• Suitable for developers who need additional features and support.

GitHub Free for Organizations:

• Similar to GitHub Free for Personal Accounts but for organizations.
• Work with unlimited collaborators on unlimited public repositories or unlimited private repositories.
• Includes GitHub Community Support and team access controls.
• Ideal for open source projects and small teams.

GitHub Team:

• Includes all features from GitHub Free for Organizations, plus:
• GitHub Support via email.
• 3,000 GitHub Actions minutes per month.
• 2 GB GitHub Packages storage.
• Advanced tools and insights in private repositories.
• Suitable for teams that need additional support and features.

Remember to choose the GitHub product that aligns with your needs, whether you’re an individual developer or part of a team! 🌟

Q. Describe GitHub’s products for organization accounts (free for organizations, teams)

→ Certainly! Let’s explore the different GitHub products available for organization accounts:

GitHub Free for Organizations:

• Features:
• Work with unlimited collaborators on unlimited public repositories with a full feature set.
• Work on unlimited private repositories with a limited feature set.
• Includes GitHub Community Support.
• Dependabot alerts for security vulnerabilities.
• Deployment protection rules for public repositories.
• Two-factor authentication enforcement.
• 500 MB GitHub Packages storage.
• 120 GitHub Codespaces core hours per month.
• 15 GB GitHub Codespaces storage per month.
• GitHub Actions features: 2,000 minutes per month.
• Ideal for open source projects and small teams.

GitHub Team:

• Includes all features from GitHub Free for Organizations, plus:
• GitHub Support via email.
• 3,000 GitHub Actions minutes per month.
• 2 GB GitHub Packages storage.
• Advanced tools and insights in private repositories:
• Required pull request reviewers.
• Protected branches.
• Code owners.
• Auto-linked references.
• GitHub Pages (private publishing requires an organization account).
• Repository insights graphs (e.g., Pulse, contributors, traffic).
• Suitable for teams that need additional support and features.

Remember to choose the GitHub product that aligns with your organization’s needs and collaboration requirements! 🌟

Q. Describe the different deployment options for GitHub Enterprise

→ The different deployment options for GitHub Enterprise:

GitHub Enterprise Cloud:

• GitHub Enterprise Cloud is a cloud-hosted solution provided by GitHub.
• It is part of GitHub.com and is managed by GitHub.
• Features:
• Hosted on GitHub’s infrastructure.
• No need to manage servers or maintenance.
• Access to advanced functionality available on GitHub.com.
• Ideal for organizations that prefer a cloud-based solution.

GitHub Enterprise Server:

• GitHub Enterprise Server is a self-hosted solution.
• Organizations install and manage it on their own infrastructure.
• Features:
• Provides complete control over the environment.
• Customizable and scalable.
• Suitable for organizations with specific security, compliance, or integration requirements.
• Requires dedicated server resources.

Choosing Between Cloud and Server:

GitHub Enterprise Cloud:

• Easier setup and maintenance.
• No need to manage hardware or software updates.
• Ideal for smaller organizations or those without dedicated IT resources.

GitHub Enterprise Server:

• Greater control over security and data.
• Customizable deployment options.
• Suitable for larger organizations with specific needs.

Remember that the choice between GitHub Enterprise Cloud and GitHub Enterprise Server depends on your organization’s preferences, requirements, and infrastructure capabilities. 🌐🚀

Q. Describe the features in the user profile (metadata, achievements, profile readme, repositories, pinned repositories, stars, etc.)

→ A user profile is a collection of settings and information associated with an individual. It serves as a digital representation of a user’s identity within various contexts, such as operating systems, software applications, and online platforms. Here are some key aspects of user profiles:

1. Personal Information:

• Name: The user’s full name.
• Age: The user’s age or birthdate.
• Portrait Photograph: A picture representing the user.
• Biographical Details: Additional information about the user, such as location, occupation, and interests.

1. Metadata:

• Achievements: Records of accomplishments or milestones attained by the user (e.g., badges, certifications, awards).
• Activity History: A log of the user’s interactions, contributions, and actions within a system or platform.
• Statistics: Metrics related to the user’s usage patterns, engagement, and performance.

1. Profile Readme:

• A customizable section where users can provide a brief introduction, share their interests, and showcase their skills. It often includes markdown-formatted text, links, and images.

1. Repositories:

• A list of code repositories owned or contributed to by the user. These repositories may contain open-source projects, personal experiments, or collaborative work.
• Each repository typically includes a description, code files, and documentation.

1. Pinned Repositories:

• A subset of repositories that the user chooses to highlight on their profile. Pinned repositories appear prominently at the top of their repository list.

1. Stars:

• A count of how many times the user has “starred” or favorited repositories created by other users. Starring indicates interest or appreciation for a particular project.

1. Contributions:

• Information about the user’s contributions to open-source projects, including pull requests, issues, and code reviews.

1. Settings:

• Personalized preferences, such as theme selection, notification settings, and privacy options.
• Language preferences, time zones, and accessibility settings.

1. Social Media Links:

• Links to the user’s profiles on other platforms (e.g., LinkedIn, Twitter, personal website).

1. Privacy Controls:

• Options to control who can view specific profile details and activities.
• Privacy settings related to data sharing and visibility.

User profiles play a crucial role in providing a personalized experience, organizing user-specific data, and facilitating interactions within digital environments. Whether on social media, operating systems, or other platforms, user profiles help define an individual’s digital identity and preferences.

Q. Identify the text formatting toolbar on issue and pull request comments

→ The text formatting toolbar on GitHub issue and pull request comments is a feature that allows you to format your text without needing to learn Markdown syntax. Here are some of the features it includes:

• Markdown Formatting: You can apply basic Markdown formatting like bold and italic styles, creating headers, links, and lists.
• GitHub-specific Features: The toolbar includes features specific to GitHub such as @-mentions, task lists, and links to issues and pull requests.
• Code Formatting: You can format code using fenced code blocks. Just wrap your code blocks in ``` and you won’t need to indent manually to trigger a code block.
• Syntax Highlighting: In your fenced block, you can add an optional language identifier and GitHub will run it through syntax highlighting.

This toolbar makes it easier to write and format text in GitHub, enhancing the overall user experience. It’s especially useful for those who are new to Markdown or prefer a more visual way of formatting text.

Q. Describe Markdown

→ Markdown is a lightweight markup language that you can use to add formatting elements to plaintext text documents. It was created by John Gruber and Aaron Swartz in 2004. Here are some key features of Markdown:

https://www.markdownguide.org/getting-started/

• Easy to Write and Read: Markdown is designed to be easy to write and read. It looks like a plain text document, which can be opened and edited with standard text editor applications.
• Rich Formatting Options: You can use Markdown to format text, create lists, insert links, and images, create tables, and more.
• Convertibility: Markdown files (with .md or .markdown extension) can be converted to many output formats like HTML, PDF, and more.
• Widely Used: Markdown is used in many places such as GitHub, Reddit, Stack Overflow, and Jupyter notebook.

Here’s a brief overview of the basic syntax:

• Headers: You can create a heading by adding one or more # symbols before your heading text. The number of # you use will determine the size of the heading.
• Paragraphs: Paragraphs in Markdown are just one or more lines of consecutive text followed by one or more blank lines.
• Line Breaks: When you do want to insert a <br /> break tag using Markdown, you end a line with two or more spaces, then type return.
• Bold and Italic Text: You can make text bold or italic by wrapping the text in ** or * respectively.
• Links and Images: You can create a link by wrapping the link text in brackets [], and then wrapping the link in parenthesis (). Images are similar, but they include an exclamation mark ! before the brackets.

Remember, the exact syntax can vary slightly depending on the specific implementation of Markdown you’re using.

Q. Identify the basic formatting syntax (headings, links, task lists, comments, etc.)

→ Here’s a brief overview of the basic Markdown syntax for formatting text:

• Headings: You can create a heading by adding one or more # symbols before your heading text. The number of # you use will determine the size of the heading. For example, # Heading 1, ## Heading 2, ### Heading 3, and so on.
• Links: You can create a link by wrapping the link text in brackets [], and then wrapping the link in parenthesis (). For example, GitHub.
• Task Lists: Task lists are lists of items with checkboxes. In Markdown, you create them using the - [ ] syntax for an empty checkbox and - [x] for a checked box. For example:

- [x] Task 1 
- [ ] Task 2 
- [ ] Task 3

• Comments: Markdown doesn’t support comments directly. However, when using Markdown within HTML, you can use HTML comment syntax <!-- Comment -->.
• Bold and Italic Text: You can make text bold or italic by wrapping the text in ** or * respectively. For example, **bold text**, *italic text*
• Blockquotes: You can indicate blockquotes with a >
• Ordered and Unordered Lists: You can create ordered (numbered) lists using numbers followed by periods and create unordered (bulleted) lists using dashes -, asterisks *, or plus signs +.
• Code: You can denote a word or phrase as code by enclosing it in backticks `

Remember, the exact syntax can vary slightly depending on the specific implementation of Markdown you’re using.

Q. Explain where to find and use slash commands

→ Slash commands are a feature in many applications that allow you to perform actions by typing a command preceded by a slash /. Here’s how you can find and use them in application:

• GitHub: In GitHub, you can use slash commands in any description or comment field in issues, pull requests, or discussions where that slash command is supported. You start by typing the command in a comment field, then follow the prompts.

Q. Explain the difference between GitHub Desktop and github.com

→ GitHub Desktop and github.com are both tools provided by GitHub, but they serve different purposes and are used in different contexts:

• github.com: This is the web interface for GitHub. It’s where you can create and manage repositories, collaborate on code, review pull requests, manage issues, and much more. It’s accessible from any web browser and doesn’t require any additional software to be installed.
• GitHub Desktop: This is a Graphical User Interface (GUI) for Git that’s specifically designed for GitHub. It allows you to interact with your repositories in a more visual and intuitive way compared to the command line. With GitHub Desktop, you can clone repositories, create commits, switch between branches, sync with the remote repository, and even resolve merge conflicts. It’s a standalone application that you need to download and install on your computer.

Here are some key differences:

• Ease of Use: GitHub Desktop provides a more user-friendly interface for interacting with repositories, which can be especially helpful for those who are new to Git or prefer a more visual approach. On the other hand, github.com is a web-based platform that can be accessed from anywhere and doesn’t require any installation.
• Functionality: While both allow you to perform most Git operations, there are some tasks that can only be done through github.com, such as managing access permissions, creating wikis, and more.
• Integration: GitHub Desktop is specifically designed for use with GitHub, allowing you to authenticate quickly without needing a separate credential manager. It also allows you to check out pull requests and run checks without needing to open your browser.

In summary, while both GitHub Desktop and github.com allow you to interact with Git repositories, they offer different experiences and are used in different contexts. You can choose to use one or both depending on your needs and preferences.

Q. Describe the available features with GitHub Desktop

→ GitHub Desktop is a free, open-source application that simplifies your development workflow by providing a Graphical User Interface (GUI) for Git. Here are some of the key features of GitHub Desktop:

• Easy Committing: You can easily commit changes, create branches, and sync with the remote repository.
• Pull Requests: You can check out pull requests as if they were a local branch, even if they’re from upstream branches or forks.
• Syntax Highlighted Diffs: The application supports syntax highlighting when viewing diffs for a variety of different languages.
• Image Diff Support: You can easily compare changed images. You can see the before and after, swipe or fade between the two, or look at just the changed parts.
• Co-authoring: Quickly add co-authors to your commit. This is great for pairing and excellent for sending a little love/credit to that special someone who helped fix that gnarly bug of yours.
• Editor & Shell Integrations: You can open your favorite editor or shell from the app, or jump back to GitHub Desktop from your shell.
• Community Supported: GitHub Desktop is open source. You can check out its roadmap, contribute, and help make collaboration even easier.

Remember, GitHub Desktop is specifically designed to work with GitHub, so it integrates seamlessly with it and enhances your GitHub experience.

Q. Describe the available features with GitHub Mobile

→ GitHub Mobile is an application that allows you to interact with GitHub from your mobile device. Here are some of the key features of GitHub Mobile:

• Task Management: You can manage, triage, and clear notifications. You can also organize tasks in a swipe and filter your inbox to find things that are most relevant to you.
• Collaboration: You can read, review, and collaborate on issues and pull requests. Whether you need to review a bug fix or merge code, you can do it from anywhere.
• Workflow Management: If a workflow run did not go as planned, you can manage your pull request checks and re-run jobs, right from the app.
• Project Updates: Stay connected and up to date on your work with Projects on GitHub Mobile.
• Community Engagement: You can explore and connect with GitHub communities. Discover interesting projects, follow your interests, and like new releases in the mobile feed.
• File Editing: You can commit updates to a pull request, or start a new branch to squash a bug at any time, wherever you are.
• Code Navigation: You can easily search for code within repositories on the go.
• Multiple Accounts: You can sign in with work and personal accounts. Easily add and manage accounts from the Profile tab
• Push Notifications: You can get push notifications for each account, maintaining data separation for privacy and convenience.

Remember, GitHub Mobile is designed to help you get work done on the go and keep your projects moving forward.

Q. Explain how to manage notifications through the GitHub Mobile app

→ Managing notifications through the GitHub Mobile app is straightforward and efficient. Here’s how you can do it:

1. Access Notifications: You can view your notifications through the notifications inbox in the GitHub Mobile app.
2. Customize Notification Settings: To customize the types of updates you’d like to receive and where to send those updates, configure your notification settings. You can choose to receive notifications for activity on GitHub.com in the following locations:

• The notifications inbox in the GitHub.com web interface
• The notifications inbox on GitHub Mobile, which syncs with the inbox on GitHub.com

1. Triage Notifications: The notifications inbox on GitHub.com and GitHub Mobile includes triaging options designed specifically for your GitHub notifications flow, including options to

• Triage multiple notifications at once.
• Mark completed notifications as Done and remove them from your inbox.
• Save a notification to review later. Saved notifications are flagged in your inbox and kept indefinitely.
• Unsubscribe and remove a notification from your inbox.

1. Push Notifications: To activate push notifications, head over to Settings->Configure Notifications in the apps (including an option to notify for failed runs only)5.
2. Working Hours: You can specify a timeframe for pausing notifications. This feature allows you to unplug when you need to through the in-app settings.

Remember, the exact steps and options may vary slightly depending on the specific version of the GitHub Mobile app you’re using.

Domain 2: Working with GitHub Repositories

Q. Describe the components of a good README and the recommended repository files (LICENSE, CONTRIBUTING, CODEOWNERS)

→ A good README and other repository files are crucial for managing a project effectively. Here are the components of a good README and the recommended repository files:

README

A README file provides information about the project and usually includes the following sections:

1. Project Title: A brief title for the project.
2. Description: A detailed description of the project and its purpose.
3. Installation: Instructions on how to install and set up the project.
4. Usage: Instructions on how to use the project, with examples if possible.
5. Contributing: Guidelines for contributors, often linking to a separate CONTRIBUTING file.
6. License: Information about the project’s license, often linking to a separate LICENSE file.
7. Contact Information: Contact details for the project maintainers.

LICENSE

A LICENSE file contains the license under which the project is released, allowing others to legally use, modify, and distribute the project. The choice of license can affect how others can use your project. Common licenses include MIT, Apache 2.0, and GNU GPL.

CONTRIBUTING

A CONTRIBUTING file provides guidelines for people who want to contribute to the project. This might include:

1. Code of Conduct: Expected behavior for contributors.
2. Process for Submitting Pull Requests: Steps for creating a good pull request.
3. Styleguides: Coding conventions like naming conventions, comment style, etc.

CODEOWNERS

A CODEOWNERS file is a GitHub feature that allows you to define individuals or teams that are responsible for code in a repository. They will be automatically requested for review whenever a pull request touches the associated code.

Remember, these are just guidelines and the specific needs of your project may require different or additional documentation. It’s always a good idea to look at other similar projects for inspiration.

Q. Explain basic repository navigation

→ Navigating a repository involves understanding the structure and purpose of the files and directories within it. Here’s a basic guide:

1. Root Directory: This is the top-level directory of your repository. It often contains configuration files like .gitignore, README.md, LICENSE, etc.
2. Source Code Directories: These directories contain the source code of your project. The structure and naming of these directories can vary based on the programming language and the project’s architecture.
3. Test Directories: These directories contain test code and test resources. They are often named test or __tests__.
4. Documentation Directories: These directories contain additional documentation for your project, such as design docs or user guides.
5. Build and Distribution Directories: These directories contain compiled code or other artifacts ready for distribution. They are often named build, dist, or target.
6. Dependency Files: These files manage your project’s dependencies. Examples include package.json for JavaScript projects, requirements.txt for Python projects, or pom.xml for Java projects.
7. Version Control Directories: These directories are used by version control systems to track changes in your project. For example, the .git directory is created by Git.
8. Configuration Files: These files are used to configure various tools and services used in your project. Examples include .travis.yml for Travis CI, .eslintrc for ESLint, or Dockerfile for Docker.

Remember, the exact structure can vary based on the project’s needs and the technologies used. Always refer to the project’s README or other documentation for specific navigation instructions.

Q. Explain how to create a new repository

→ Creating a new repository involves a few steps. Here’s a basic guide on how to do it on GitHub:

1. Sign in to GitHub: If you don’t have an account, you’ll need to create one.
2. Create a New Repository: Click the ‘+’ icon at the top right corner of the GitHub homepage, then select ‘New repository’.
3. Name Your Repository: Choose a short, memorable name for your repository. It’s often best to use dashes (-) instead of spaces.
4. Add a Description (Optional): You can add a brief description of your project.
5. Choose to Make the Repository Public or Private: Public repositories are visible to everyone, while private repositories are only visible to you and people you choose.
6. Initialize with README (Optional): If you want to add a README file to your repository (which is recommended), check the box that says ‘Initialize this repository with a README’.
7. Add .gitignore (Optional): If you want to ignore certain files in your repository, you can select a .gitignore template from the dropdown.
8. Add a License (Optional): If you want to include a license in your project, you can select one from the dropdown.
9. Create Repository: Click the ‘Create repository’ button.

Once you’ve created your repository, you can start adding files, inviting collaborators, and more. Remember, the exact steps can vary based on the version control system and platform you’re using.

Q. Describe repository templates

→ Repository templates are a feature provided by platforms like GitHub to help users create new repositories with a pre-defined directory structure, branches, and files. This feature is especially beneficial when you create the same projects multiple times or work in a big team.

Here’s how it works:

1. You can make an existing repository a template.
2. Anyone with access to the template repository can create a new repository based on the template.
3. The new repository will have the same directory structure and files as your default branch.
4. Users can also choose to include all the other branches in your repository.
5. Branches created from a template have unrelated histories, so you cannot create pull requests or merge between the branches.

Please note that your template repository cannot include files stored using Git LFS. Also, the commit history is cleaned, and there is no link to the original repository. This means that your new repository has all the code but there is no history. It will be easier to track your changes, and your work will not be tied to the repository’s other forks.

This feature can increase the speed of your routine tasks, allow you to concentrate on more important aspects of your work, make configuration less manual, and permit to use boilerplate code in multiple codebases.

Q. Describe the different features to maintaining a repository

→ Maintaining a repository involves several features and best practices:

1. Version Control: This is the core feature of any repository. It allows you to track changes, revert to previous versions, and understand what changes were made, when, and by whom.
2. Branching and Merging: These features allow you to work on different parts of a project simultaneously without affecting the main codebase. Once the feature or fix is ready, it can be merged back into the main branch.
3. Pull Requests: This feature allows contributors to propose changes to the codebase. It’s a way to review and discuss proposed changes before they are merged into the project.
4. Issue Tracking: Most repository platforms have built-in issue tracking. This allows you to track bugs, feature requests, and other tasks directly within the repository.
5. Documentation: Good repositories have clear, up-to-date documentation. This includes README files, code comments, and separate documentation files or wikis.
6. Continuous Integration/Continuous Deployment (CI/CD): These practices involve automatically building the project and running tests whenever changes are made, and automatically deploying the project to a staging or production environment.
7. Access Control: Repositories allow you to control who has access to the codebase and what they can do. This includes read/write permissions, as well as administrative permissions.
8. Code Reviews: Before code is merged into the main branch, it can be reviewed by other team members. This helps catch bugs, ensure consistency, and share knowledge within the team.

Remember, maintaining a repository is not just about the technical aspects, but also about communication and collaboration. It’s important to foster a positive and inclusive community where contributors feel welcome and valued.

Q. Describe how to clone a repository

→ Cloning a repository is a simple process that involves copying the repository from a remote server to your local machine. Here’s how you can do it using Git:

1. First, you need to navigate to the directory where you want to clone the repository. You can do this using the cd command in your terminal or command prompt. For example, if you want to clone the repository to your desktop, you would use:

cd ~/Desktop

Once you’re in the desired directory, you can clone the repository using the git clone command followed by the URL of the repository. For example:

git clone https://github.com/username/repository.git

Replace https://github.com/username/repository.git with the URL of the repository you want to clone.

1. After running the command, Git will create a new directory with the same name as the repository. This directory will contain all the files and history of the repository.
2. To navigate into your new local repository, use the cd command again, like so:

cd repository

Replace repository with the name of the repository you just cloned.

And that’s it! You’ve successfully cloned a repository to your local machine. You can now navigate through the files, make changes, and push those changes back to the remote repository if you have the necessary permissions. Remember to always pull the latest changes from the remote repository before starting your work to avoid conflicts.

Q. Describe how to create a new branch

→ Creating a new branch in Git is a straightforward process. Here’s how you can do it:

1. First, navigate to your repository on your local machine using the terminal or command prompt.
2. Before creating a new branch, it’s a good practice to make sure your local repository is up-to-date with the remote repository. You can do this by pulling the latest changes from the remote repository:

git pull origin main

Replace main with the name of the branch you want to update from.

1. Now, you can create a new branch using the git branch command followed by the name of the new branch. For example:

git branch new-feature

Replace new-feature with the name you want to give to your new branch.

1. This command creates a new branch, but it doesn’t switch to it. To switch to your new branch, use the git checkout command:

git checkout new-feature

Again, replace new-feature with the name of your new branch.

1. If you want to create and switch to a new branch in one command, you can use the -b option with the git checkout command:

git checkout -b new-feature

And that’s it! You’ve successfully created a new branch and switched to it. You can now make changes in this branch without affecting the main branch. When you’re ready, you can merge your changes back into the main branch. Remember to always pull the latest changes from the remote repository before starting your work to avoid conflicts.

Q. Explain how to add files to a repository

→ Adding files to a Git repository involves a few steps:

1. Create or Modify Your Files: First, you need to create new files or modify existing ones in your local repository.
2. Stage Your Changes: Git tracks changes to files in your repository, but it doesn’t automatically include every change in your next commit. To include changes in your next commit, you need to stage them using the git add command. You can stage all changes in the repository with git add ., or stage changes to a specific file with git add filename.

git add .

or

git add filename

1. Commit Your Changes: Once you’ve staged your changes, you can commit them to your local repository with the git commit command. This command takes a message describing the changes made in the commit. For example:

git commit -m "Add new feature"

1. Push Your Changes: After committing your changes locally, you can push them to the remote repository with the git push command. If you’re pushing to the main branch, you would use:

git push origin main

Replace main with the name of the branch you want to push to.

And that’s it! You’ve successfully added files to a Git repository. Remember, it’s important to write clear, descriptive commit messages so other contributors (or future you) can understand what changes were made in each commit.

Q. Identify how to view repository insights

→ Repository insights provide valuable information about the activity and health of a project. Here’s how you can view them:

1. Navigate to the Repository: First, go to the main page of the repository on GitHub.
2. Go to Insights Tab: On the repository main page, you’ll see several tabs like Code, Issues, Pull requests, Actions, Projects, Wiki, Security, Insights, Settings. Click on the Insights tab.
3. Explore the Insights: In the Insights section, you’ll find several options:

• Pulse: Gives you a high-level overview of the repository activities such as merged pull requests, proposed pull requests, closed issues, and new issues.
• Graphs: Provides various graphs representing the activity in the repository. These include commit activity, code frequency, the dependency graph, network, forks, etc.
• Contributors: Shows who has contributed to the repository and their contributions.
• Community: Shows community health metrics like a checklist for recommended community standards.
• Traffic: Shows web traffic to the repository, including clones of the repository.
• Dependents: Shows the packages and projects that depend on this repository.

Remember, some of these insights are only available to users with write access to the repository. If you’re just a viewer or a contributor, you might not be able to see all of them.

Q. Explain how to save a repository with stars

→ Starring a repository on GitHub is a simple way to save repositories for quick access later or to show appreciation to the repository’s maintainers. Here’s how you can star a repository:

1. Navigate to the Repository: First, go to the main page of the repository on GitHub.
2. Star the Repository: On the repository main page, you’ll see a Star button at the top right, next to the Watch and Fork buttons. Click on the Star button to star the repository.

Once a repository is starred, it will appear in your Stars list. You can access this list by clicking on your profile picture in the top right corner, then clicking on Your stars. Here, you’ll see a list of all the repositories you’ve starred.

Remember, starring a repository is a public action. Other users can see the number of stars a repository has and who has starred it. If you want to save a repository without this being publicly visible, consider using the Watch feature or saving it to your bookmarks in your web browser. Starring a repository does not grant any additional permissions or ownership over the repository - it’s simply a way to bookmark it for later reference.

Q. Explain feature previews

→ Feature previews are a way for users to test out new features before they are officially released. This allows users to provide feedback and help identify any issues or bugs, which can be fixed before the full release.

Here’s how it generally works:

1. Announcement: The organization developing the software will announce that a new feature is available for preview. This could be through a blog post, an update on their website, or a notification within the software itself.
2. Opt-In: Users typically need to opt-in to use feature previews. This could involve going to the settings and enabling the feature preview, or it could require downloading a special version of the software.
3. Use and Feedback: Users can then use the feature as they normally would and provide feedback. This could be through a built-in feedback tool, a forum, or by contacting the organization directly.
4. Updates and Full Release: The organization will take the feedback into account, make any necessary changes, and then fully release the feature. Users who opted into the feature preview will typically get to continue using the feature without interruption.

Remember, feature previews are a way for organizations to test new features with a wider audience, and your feedback can help improve the feature for all users. However, because these features are still in development, you may encounter bugs or issues, so use them with that understanding.

Domain 3: Collaboration Features

Q. Describe how to link a PR to an issue

→Sure, here’s how you can link a Pull Request (PR) to an issue in GitHub:

1. Using Keywords in PR Description: You can use specific keywords in your PR description to link it to an issue. For example, if your issue number is 123, you could include “Fixes #123” or “Closes #123” in your PR description. When the PR is merged, the issue will automatically be closed. Here are some keywords you can use: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved.
2. Manual Linking: You can manually link a PR to an issue through the GitHub interface. Here’s how:

• Navigate to the PR.
• On the right side, under the section “Linked issues”, click on the text “Link issues”.
• In the resulting dropdown, start typing the title or number of the issue. Matching issues will appear in a list.
• Click on the issue you want to link to the PR.
• The issue is now linked to the PR.

Remember, linking PRs to issues is a good practice as it helps keep track of the changes made and the problems solved by each PR. It also helps in organizing and managing your project effectively.

Q. Describe how to create an issue

→ Creating an issue in GitHub is a straightforward process. Here are the steps:

1. Navigate to the Repository: Go to the main page of the repository where you want to create an issue.
2. Go to the Issues Tab: On the repository page, you’ll see several tabs (like Code, Issues, Pull requests, etc.). Click on the Issues tab.
3. Create a New Issue: Click on the New issue button. This will take you to a new page where you can create your issue.
4. Fill Out the Form:

• Title: Give your issue a short, clear title that explains the problem.
• Comment: In the comment section, provide as much detail as you can about the issue. This might include things like steps to reproduce the issue, what you expected to happen, what actually happened, and any error messages you received.
• Labels: You can optionally assign labels to your issue to help categorize it and make it easier for others to find. This is typically done using pre-existing labels, but repository maintainers can create new ones as needed.
• Assignees: If you know who should handle the issue, you can assign them to it. Otherwise, this can be left blank and someone can self-assign or be assigned by a maintainer later.

1. Submit the Issue: Once you’ve filled everything out, click Submit new issue and your issue will be created.

Remember, issues are a great way to keep track of tasks, enhancements, and bugs for your projects. They’re kind of like email—except they can be shared and discussed with the rest of your team.

Q. Describe the difference between an issue, discussion, and pull request

→Here are the differences between an issue, a discussion, and a pull request on GitHub:

• Issue: An issue is a way to track ideas, enhancements, tasks, or bugs for work on GitHub. Issues are a great way to keep track of tasks, assignments, or ideas for your projects. They can be created by anyone (for public repositories), and are moderated by repository collaborators. Each issue contains its own thread of conversations and can be labeled and assigned to a specific user.
• Discussion: Discussions is a collaborative communication forum for the community around an open source project. It’s a place where the community can have conversations, ask questions, post feedback, or brainstorm new ideas. Discussions promote more open and easy communication than issues. They are categorized into different types (like general, Q&A, show and tell, etc.) and can be converted from issues.
• Pull Request (PR): A pull request is a proposal to change the codebase. It’s the way you contribute your changes to a project. When you create a PR, you’re proposing your changes and requesting that someone review and pull in your contribution and merge them into their branch. PRs show diffs, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red.

In summary, you use issues to track project tasks and bugs, discussions to engage with the community and brainstorm ideas, and pull requests to propose changes to the codebase.

Q. Explain how to create a branch from an issue

→ Creating a branch from an issue in GitHub is a great way to keep your work organized and linked to the task at hand. Here’s how you can do it:

1. Navigate to the Issue: First, go to the main page of the repository where the issue is located. Click on the Issues tab and then click on the issue from which you want to create a branch.
2. Create a New Branch: Once you’re on the issue page, you can create a new branch directly from the issue. To do this, you’ll need to use the command line. Here’s the general format of the command you’ll use:

git checkout -b branch-name

1. Replace branch-name with a name that is relevant to the issue. It’s common to include the issue number in the branch name for easy reference.
2. Push the Branch to GitHub: After creating the new branch on your local machine, push it to GitHub with the following command:

git push origin branch-name

1. Replace branch-name with the name of your new branch.
2. Link the Branch to the Issue: Finally, in your issue comment, mention the branch name. This will create a reference link to the branch from the issue. For example, you can write “I’ve created a new branch for this issue: branch-name.”

Remember, always pull the latest changes from the main branch before creating a new branch to ensure you’re working with the most recent version of the project. Also, regular commits with clear messages will help others understand what changes you’ve made.

Q. Identify how to assign issues

→ Assigning issues in GitHub is a straightforward process. Here’s how you can do it:

1. Navigate to the Issue: First, go to the main page of the repository where the issue is located. Click on the Issues tab and then click on the issue you want to assign.
2. Assign the Issue: On the right side of the issue page, you’ll see a section titled Assignees. Click on the assign yourself link to assign the issue to yourself. If you want to assign the issue to someone else, click on the Assignees section and then start typing their username. Matching usernames will appear in a dropdown menu. Click on the correct username to assign them to the issue.

Remember, you can assign an issue to more than one person if the task requires collaboration. Also, only people with write access to the repository or who have been explicitly added as contributors can be assigned to issues.

Q. Describe how to search and filter issues

→ Searching and filtering issues in GitHub can help you find exactly what you’re looking for. Here’s how you can do it:

1. Navigate to the Issues Tab: Go to the main page of the repository where you want to search or filter issues. Click on the Issues tab.
2. Use the Search Bar: At the top of the issues list, there’s a search bar. You can type any keywords related to the issue you’re looking for here. This search is scoped to the repository you’re in, so it will only return issues from this repository.
3. Filter Issues: Next to the search bar, there’s a Filters dropdown menu. Click on it to see filtering options. You can filter issues based on:

• Assignee: Show only issues assigned to a certain person.
• Author: Show only issues created by a certain person.
• Labels: Show only issues with certain labels.
• Milestones: Show only issues associated with certain milestones.
• Projects: Show only issues associated with certain projects.
• Sort: Sort issues by newest, oldest, most commented, least commented, recently updated, least recently updated, most reactions.

1. Advanced Search: For more advanced search queries, you can use special qualifiers. For example, is:open will show only open issues. You can find more about advanced search syntax in the GitHub Docs.

Remember, effectively searching and filtering issues can help you manage your project more efficiently.

Q. Describe how to pin an issue

→ Pinning an issue in GitHub allows you to highlight it on the repository’s issue page. It’s a great way to draw attention to important issues. Here’s how you can pin an issue:

1. Navigate to the Issue: First, go to the main page of the repository where the issue is located. Click on the Issues tab and then click on the issue you want to pin.
2. Pin the Issue: On the right side of the issue page, you’ll see a Pin issue button next to the New issue button. Click on it.
3. Confirm Pinning: A dialog box will appear asking you to confirm that you want to pin the issue. Click Pin this issue.

The issue will now appear at the top of the issue listing in a section called Pinned Issues. This makes it easy for anyone visiting the repository to see and access the issue.

Please note that only users with write access to the repository can pin issues. Also, you can pin up to 3 issues in a repository.

Q. Explain basic issue management

→ Here are some basic steps for managing issues on GitHub:

1. Creating Issues: Whenever you spot a bug, have an idea for a feature, or identify a task that needs to be done, create an issue for it. Be sure to give it a clear title and a detailed description so that others can understand what the issue is about.
2. Labeling Issues: Use labels to categorize and prioritize issues. Labels can indicate the type of issue (bug, feature request, etc.), the status of the issue (in progress, needs review, etc.), or the difficulty or estimated time to resolve the issue.
3. Assigning Issues: Assign issues to specific team members. The assignee is the person responsible for working on the issue. You can assign an issue to yourself if you plan to work on it, or you can assign it to someone else if you believe they are the best person for the job.
4. Linking Issues: If an issue is related to another issue or a pull request, link them together. This helps to keep track of related work and discussions.
5. Closing Issues: Once the work related to an issue is complete, close the issue. This signals to everyone that the issue has been resolved. If an issue is closed prematurely, it can always be reopened.
6. Searching and Filtering Issues: Use GitHub’s search and filter features to find specific issues. You can search by keyword, status, assignee, label, and more.

Remember, the goal of issue management is to keep your project organized and ensure that all work is tracked and completed efficiently. Effective issue management can lead to better communication, clearer project objectives, and improved project quality.

Q. Explain the difference between issue templates and issue forms

→ Issue Templates and Issue Forms are both features provided by GitHub to help maintain a standard for issue reporting in a repository. They serve similar purposes but have different levels of flexibility and structure.

Issue Templates:

• Issue templates are markdown files that provide guidance for opening issues while allowing contributors to specify the content of their issues.
• They are helpful when you want to provide a general structure for issue reporting, but they don’t enforce any specific format.
• They are more free-form, allowing users to edit and format their issue content as they see fit.

Issue Forms:

• Issue forms, on the other hand, are defined using YAML and provide a more structured and interactive way for contributors to report issues.
• They allow you to define different input types, validations, default assignees, and default labels for your issue forms.
• When a contributor fills out an issue form, their responses for each input are converted to markdown and added to the body of an issue.
• They help ensure that you receive specific, structured information when issues are opened.
• Issue forms are not supported for pull requests.

In summary, if you want a more structured and specific format for issue reporting, issue forms would be the way to go. If you prefer a more flexible and open-ended format, then issue templates would be more suitable. It’s also worth noting that you can use both markdown and YAML issue templates in your repository.

Q. Explain how to use keywords in issues

→ In GitHub, you can use keywords in issues and pull requests to create links between them or to mark an issue or pull request as a duplicate. Here’s how you can do it:

Linking a Pull Request to an Issue: You can link a pull request to an issue to show that a fix is in progress and to automatically close the issue when someone merges the pull request. To do this, type one of the following keywords followed by a reference to the issue in the pull request’s description or in a commit message:

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

For example, if you want to link to issue #10, you could write Closes #10 in your pull request description12.

Marking an Issue or Pull Request as a Duplicate: To mark an issue or pull request as a duplicate, type “Duplicate of” followed by the issue or pull request number it duplicates in the body of a new comment.

Please note that these keywords are interpreted when the pull request targets the repository’s default branch. If the PR’s base is any other branch, then these keywords are ignored, no links are created, and merging the PR has no effect on the issues. If you want to link a pull request to an issue using a keyword, the PR must be on the default branch.

Q. Describe a pull request

→ A Pull Request is a feature provided by version control systems like Git, and it’s heavily used in platforms like GitHub. It’s a proposal to merge a set of changes from one branch into another. Here’s a detailed description:

• Pull Requests let you inform others about changes you’ve pushed to a branch in a repository.
• Once a Pull Request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
• Pull Requests display the differences, or diffs, between the content in the source branch and the content in the target branch.
• They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project.
• In their simplest form, Pull Requests are a mechanism for a developer to notify team members that they have completed a feature.
• Once their feature branch is ready, the developer files a Pull Request via their Bitbucket account.
• This lets everybody involved know that they need to review the code and merge it into the main branch.
• But, the Pull Request is more than just a notification—it’s a dedicated forum for discussing the proposed feature.
• If there are any problems with the changes, teammates can post feedback in the Pull Request and even tweak the feature by pushing follow-up commits.
• All of this activity is tracked directly inside of the Pull Request.
• Compared to other collaboration models, this formal solution for sharing commits makes for a much more streamlined workflow.

In summary, a Pull Request is a key feature in collaborative software development that facilitates code review, discussion about the changes, and eventually merging the changes into the main codebase.

Q. Explain how to create a new pull request

→ Creating a new pull request involves the following steps:

1. Fork the Repository: If you want to contribute to a project, you first need to make a copy of the repository. This is done by forking the repository.
2. Clone the Repository: After forking, you need to clone the repository to your local system. This can be done using the command git clone https://github.com/your-username/repository.git
3. Create a New Branch: It’s a good practice to create a new branch for each new feature or bug fix you’re working on. You can create a new branch using the command git checkout -b branch-name
4. Make Your Changes: Make the changes in your local repository. Be sure to add and commit your changes using git add . and git commit -m "commit message”.
5. Push Your Changes: After committing your changes, push them to your forked repository using the command git push origin branch-name.
6. Create the Pull Request: On GitHub, navigate to the main page of the repository. In the “Branch” menu, choose the branch that contains your commits. Above the list of files, click “Compare & pull request” to create a pull request for the associated branch.
7. Fill Out the Pull Request Form: Provide a title and detailed description for your pull request. This helps maintainers understand what changes you’ve made and why they’re important.
8. Submit the Pull Request: Finally, submit the pull request. The maintainers of the original repository will be notified and can review your proposed changes.

Remember, creating a pull request allows you to propose changes to a project. It’s a way to initiate a discussion about your contributions, and it’s up to the project maintainers to merge your changes.

Q. Describe the `base` and `compare` branches in a pull request

→ In a GitHub pull request, the base and compare branches serve specific roles:

• Base Branch: This is the branch that you want to merge your changes into. It’s the starting point of your comparison. When you create a pull request, you can select which branch should be the base branch. Typically, this is the main branch where the stable version of the project is.
• Compare Branch: This is the branch that contains the changes you’ve made. It’s the endpoint of your comparison. When creating a pull request, you choose the compare branch, which is usually the branch where you’ve made your changes or added new features.

The pull request will display the differences, or diffs, between the content in the compare branch and the content in the base branch. This allows you and others to review and discuss the changes before they’re merged into the base branch.

There are two comparison methods for the git diff command; two-dot (git diff A..B) and three-dot (git diff A...B). By default, pull requests on GitHub show a three-dot diff:

• Three-dot Git diff comparison: The three-dot comparison shows the difference between the latest common commit of both branches (merge base) and the most recent version of the topic branch.
• Two-dot Git diff comparison: The two-dot comparison shows the difference between the latest state of the base branch (for example, main) and the most recent version of the topic branch.

In summary, the base branch is where you want your changes to go, and the compare branch is where those changes currently exist.

Q. Explain the relationship of commits on a pull request

→ In a pull request, commits play a crucial role. Here’s how they relate:

• A commit is a discrete change to one or more files. It’s a critical part of Git. Each commit in a repository has a unique SHA hash and includes the change made to the code, the author, and the timestamp.
• A pull request is a proposal to merge one or more commits into a different branch. It’s not part of Git; it is only part of GitHub (and similar services like BitBucket).
• When you create a pull request, all the commits from the branch (also known as the compare branch) you’re proposing to merge are included in the pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the “Files changed” tab.
• Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request.
• After you’ve created a pull request, you can push additional commits from your topic branch to add them to your existing pull request. This is useful if you need to make changes based on feedback or if you have additional changes to make.
• If you’re working in the shared repository model, it’s recommended that you use a topic branch for your pull request. While you can send pull requests from any branch or commit, with a topic branch you can push follow-up commits if you need to update your proposed changes.

In summary, commits are the building blocks of a pull request. Each commit represents a specific change, and the pull request bundles these changes for review and potential inclusion in the project.

Q. Describe draft pull requests

→ A Draft Pull Request is a feature provided by GitHub that allows you to open a pull request that is not ready to be merged. Here’s a detailed description:

• When you create a Draft Pull Request, it cannot be merged until it is marked as ready for review.
• This is useful because often pull requests are used as conversations, often prior to the work being ready to merge.
• A draft pull request comes about when you raise a pull request to make the work visible to others for early feedback or for awareness but you know that it is not ready for merge (and maybe will never be merged).
• With draft pull requests, you can clearly tag when you’re coding a work in progress.
• Now when you open a pull request, a dropdown arrow appears next to the “Create pull request” button. Toggle the dropdown arrow whenever you want to create a draft instead.
• A draft pull request is styled differently to clearly indicate that it’s in a draft state.
• Merging is blocked in draft pull requests.
• Change the status to “Ready for review” near the bottom of your pull request to remove the draft state and allow merging according to your project’s settings.
• Also, if you have a CODEOWNERS file in your repository, a draft pull request will suppress notifications to those reviewers until it is marked as ready for review.

In summary, a Draft Pull Request is a way to signal to others that your code is a work in progress and is not yet ready to be merged.

Q. Describe the purpose of the pull request tabs (conversation, commits, checks, files changed)

→ In a GitHub pull request, there are several tabs that provide different views and functionalities:

• Conversation Tab: This is where the overall discussion about the pull request takes place. You can see the initial comment made when the pull request was opened, and all subsequent comments. You can also see system messages about commits being added or the pull request being merged or closed. This is where you can review and leave comments, request changes, approve the pull request, or even add more commits.
• Commits Tab: This tab lists all the commits that are included in the pull request. Each commit shows the author, the date, the commit message, and the changes made in that commit. You can click on each commit to see the specific changes made.
• Checks Tab: If the repository has any integrated Continuous Integration (CI) services, like GitHub Actions, Jenkins, or Travis CI, this tab will show the status of these checks. It will indicate whether the checks have passed, failed, or are still in progress. This helps maintainers ensure that the proposed changes do not break any existing functionality.
• Files Changed Tab: This tab shows a diff of all the changes made in the pull request. It displays the differences between the base branch and the compare branch for all the files that have been modified, added, or deleted. You can view the changes in a side-by-side diff or an inline diff. You can also leave review comments on specific lines of code in this tab1.

These tabs help maintainers and contributors review the changes, discuss potential issues, check the status of automated tests, and understand the impact of the changes on the project.

Q. Identify how to link activity within a pull request

→ You can link activity within a pull request in GitHub by following these steps:

1. Linking a pull request to an issue using a keyword: You can link a pull request to an issue by using a supported keyword in the pull request’s description or in a commit message. The pull request must be on the default branch. The keywords you can use are: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved. If you use a keyword to reference a pull request comment in another pull request, the pull requests will be linked. Merging the referencing pull request also closes the referenced pull request.
2. Manually linking a pull request to an issue using the pull request sidebar: Anyone with write permissions to a repository can manually link a pull request to an issue from the pull request sidebar. You can manually link up to ten issues to each pull request. The issue and pull request must be in the same repository.

Please note that when you link a pull request to the issue the pull request addresses, collaborators can see that someone is working on the issue. When you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed.

Q. Explain the different pull request statuses

→ Pull requests in GitHub can have several statuses, each indicating a different stage or state of the review process. Here are the possible statuses:

1. Approved: This status indicates that the pull request has been reviewed and approved, allowing it to be merged.
2. Changes Requested: This status is used when the reviewer has requested changes to be made before the pull request can be approved.
3. Commented: This status is used when a reviewer has added comments to the pull request but has not explicitly approved or requested changes.
4. Dismissed: This status indicates that a review has been dismissed. This can happen if the reviewer who requested changes or made comments is no longer available, or if their feedback has been addressed in a way that doesn’t require their re-review.
5. Pending: This status is used when a review has been started but not yet submitted.

In addition to these, there are also statuses that can be set by external services integrated into the GitHub workflow, such as continuous integration (CI) systems. These statuses can be “success”, “failure”, “error”, or “pending”, and they provide information about the results of tests, builds, or other checks run by the service. For example, a CI system might post a “success” status if all tests pass on the code in the pull request, or “failure” if any tests fail.

Remember, the exact statuses available and their meanings can vary depending on the specific workflow and integrations used in a project.

Q. Recognize how to comment on a posted link to a line or lines of code from a file

→ To comment on a posted link to a line or lines of code from a file in GitHub, you can follow these steps:

1. Navigate to the file in the repository.
2. Click on the line number or hold shift down to select a range of lines. The URL will change and something like #L21-L23 will be added to the URL.
3. Copy the updated URL.
4. Navigate to the conversation where you want to link to the code snippet.
5. Paste your permalink into a comment, and click Comment.

This will create a permanent link to the specific line or range of lines in the code file. When someone clicks on the link, they will be taken directly to the referenced part of the code. Please note that the file or version of the file you want to refer to should be the one you are viewing when you copy the URL. This ensures that the link will always point to the correct place in the code, even if the file changes in the future.

Q. Describe code review with a codeowners file

→ A CODEOWNERS file in GitHub is a tool that helps manage code ownership and review in a repository. Here’s how it works:

1. Defining Code Owners: You can define individuals or teams that are responsible for code in a repository using a CODEOWNERS file. The people you choose as code owners must have write permissions for the repository.
2. Location of the CODEOWNERS File: To use a CODEOWNERS file, create a new file called CODEOWNERS in the .github/, root, or docs/ directory of the repository, in the branch where you’d like to add the code owners.
3. Automatic Review Requests: Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. When you mark a draft pull request as ready for review, code owners are automatically notified.
4. Required Reviews: If a repository administrator has enabled required reviews, they can optionally require approval from a code owner before the author can merge a pull request in the repository.
5. Visibility of Code Ownership: If a file has a code owner, you can see who the code owner is before you open a pull request. In the repository, you can browse to the file and hover over to see a tooltip with code ownership details.

Remember, the CODEOWNERS file is a powerful feature that enables developers to manage ownership of specific files and directories in a repository. It helps ensure that the right people are reviewing the right code, which can improve code quality and reduce the risk of bugs or security vulnerabilities.

Q. Explain the different options for providing a code review on a pull request (comment, approve, request changes, suggested changes)

→ When providing a code review on a pull request in GitHub, you have several options:

1. Comment: This allows you to submit general feedback without explicitly approving the changes or requesting additional changes. You can use this option to ask questions, suggest improvements, or discuss certain parts of the code without blocking the pull request.
2. Approve: This option allows you to submit feedback and approve the merging of the changes proposed in the pull request. When you approve a pull request, you’re saying that you’ve reviewed the changes and you believe they should be merged as they are.
3. Request Changes: This option allows you to submit feedback that must be addressed before the pull request can be merged. If you see issues in the code that need to be fixed or improved, you can use this option to block the pull request until those changes are made.
4. Suggested Changes: This is a feature that allows you to suggest specific changes to a line or block of code within a pull request. The author of the pull request can then accept, reject, or modify the suggested changes.

Remember, the goal of a code review is to ensure the quality of the code and to share knowledge among the team. It’s important to provide clear, constructive feedback and to be respectful and collaborative in your reviews.

Q. Describe the difference between discussions and issues

→ Discussions and Issues are both features of GitHub, but they serve different purposes:

• GitHub Discussions is a feature that brings community forums to your GitHub repositories. It’s designed to foster collaboration and community-building, and is a place where users can have open-ended conversations, ask and answer questions, share updates, and more. Discussions are more spontaneous and free-flowing, covering a wide range of topics, and are not necessarily aimed at resolution or consensus. They are designed for any developer community working on something together.
• GitHub Issues, on the other hand, is a feature that allows users to track ideas, enhancements, tasks, or bugs for work on GitHub. Issues are often characterized by a focused and structured approach, dealing with specific topics or problems. They are the engines of decision-making, driving us towards conclusions and actions with a clear sense of direction.

In summary, while Discussions are used for open-ended conversations and community engagement, Issues are used for tracking tasks, bugs, feature requests, and more. Both of them play crucial roles in project management and community building on GitHub.

Q. Explain the options available with discussions (announcements, ideas, polls, Q&A, show and tell)

→ GitHub Discussions provides several categories to help structure the conversation and make it easier for others to participate and find information. Here are some of the common categories:

• Announcements: This category is typically used for important news or updates related to the project. It’s a great place to share release notes, upcoming changes, or anything else that the community should be aware of.
• Ideas: This is a place for brainstorming and proposing new features or improvements. It’s a great way to gather feedback from the community and gauge interest in new ideas.
• Polls: While not a default category, you can create polls in any discussion post to gather community input. This can be useful for making decisions that affect the project or community.
• Q&A: This category is for asking and answering questions. It’s a great place for community members to help each other and share knowledge.
• Show and Tell: This category is for sharing work that you’ve done related to the project. This could be a feature you’ve built, a tool you’ve developed, or even a story about how you use the project.

Each of these categories serves a different purpose and helps facilitate different types of conversations. They can be customized to suit the needs of your specific project or community.

Q. Identify how to mark a comment as an answer to a discussion

→ Here are the steps to mark a comment as an answer in a GitHub Discussion:

1. Navigate to the main page of the repository or organization on GitHub.com.
2. Under your repository or organization name, click Discussions.
3. In the list of discussions, click the discussion you want to mark as answered.
4. In the discussion, find the comment you want to mark as the answer.
5. Below the comment, click Mark as answer1.

Please note that you can only mark a comment as an answer if the discussion is within a category that accepts answers. When you mark a question as an answer, GitHub will highlight the comment and replies to the comment to help visitors quickly find the answer. You can also unmark a comment as the answer if needed.

Q. Explain how to convert a discussion to an issue

→ Here are the steps to convert a GitHub Discussion to an Issue:

1. Navigate to the main page of the repository on GitHub.com.
2. Under your repository name, click Discussions.
3. In the list of discussions, click the discussion you want to convert to an issue.
4. In the right sidebar of the discussion, click Create issue from discussion.
5. In the “Title” field, type a title for your issue.
6. In the comment body field, type a description of your issue.
7. When you’re finished, click Submit new issue.

Please note that creating an issue from a discussion does not convert the discussion to an issue or delete the existing discussion. The original discussion will remain intact in the Discussions tab.

Q. Recognize how to pin a discussion

→ Here are the steps to pin a discussion in GitHub:

1. Navigate to the main page of the repository or organization on GitHub.com.
2. Under your repository or organization name, click Discussions.
3. In the list of discussions, click the discussion you want to view.
4. In the right sidebar, click Pin discussion.
5. To confirm, click Pin to CATEGORY.

Please note that you can pin a discussion to the top of the list of discussions for the repository or organization. You can also pin a discussion to a specific category. You can pin up to four important discussions above the list of discussions in a specific category.

Q. Describe how to manage notification subscriptions

→ Here are the steps to manage notification subscriptions on GitHub:

1. In the upper-right corner of any page, click your profile photo, then click Settings.
2. In the left sidebar, click Notifications.
3. On the Notifications tab, you can adjust your notification preferences.

You can specify how to receive notifications, the repositories you are interested in, and the types of activity you want to hear about. You can choose the type of activity on GitHub that you want to receive notifications for and how you want these updates delivered.

You can also manage your subscriptions for specific discussions or issues:

1. Navigate to the main page of the repository on GitHub.com.
2. Under your repository name, click Discussions or Issues.
3. In the list of discussions or issues, click the one you want to manage.
4. In the right sidebar, under “Notifications”, you can manage your subscription settings.

Remember, managing your notifications effectively can help you stay informed about the projects you care about without being overwhelmed by updates.

Q. Explain how to subscribe to notification threads

→Here are the steps to subscribe to notification threads on GitHub:

1. Navigate to the main page of the repository on GitHub.com.
2. Under your repository name, click Discussions or Issues.
3. In the list of discussions or issues, click the one you want to manage.
4. In the right sidebar, under “Notifications”, click Subscribe.

By subscribing to a thread, you will receive notifications for specific activity that you are interested in. You can choose to receive ongoing updates about specific activity on GitHub.com through a subscription. If you’re no longer interested in a conversation, you can unsubscribe or customize the types of notifications you’ll receive in the future.

Q. Describe how to find threads where you are at-mentioned

→Here are the steps to find threads where you are at-mentioned on GitHub:

1. Navigate to the main page of GitHub.com.
2. In the upper-right corner, click your profile photo, then click Your notifications.
3. On the Notifications page, you can see a list of all the notifications for the activity that you’re subscribed to.
4. You can filter this list to find issues or pull requests in which you’re mentioned.

You can also view all the issues on Github you have commented on by going to the notifications/subscriptions page and selecting Reason as Comments. This will show all the issues that you’ve commented on.

Remember, managing your notifications effectively can help you stay informed about the projects you care about without being overwhelmed by updates.

Q. Identify the notification filtering options

→ GitHub provides several options to filter your notifications, helping you focus on the updates that matter most to you:

• Inbox Triage Options: The notifications inbox on GitHub.com and GitHub Mobile includes triaging options designed specifically for your GitHub notifications flow. This includes options to triage multiple notifications at once, mark completed notifications as Done, save a notification to review later, unsubscribe and remove a notification from your inbox, and preview the issue or pull request where the notification originates on GitHub.com from within the notifications inbox.
• Custom Filters: You can create custom filters to focus on different notifications when you want.
• Group Notifications: You can group notifications in your inbox by repository or date to get a quick overview with less context switching.
• Organization and Author Filters: You can now filter your web notifications by organization or author on GitHub. This allows you to view notifications from all repositories within an organization or all conversations started by a user.
• Activity Type Filter: To filter notifications for specific activity on GitHub.com, you can use the is query. For example, to only see repository invitation updates, use is:repository-invitation, and to only see Dependabot alerts, use is:repository-vulnerability-alert.

Remember, managing your notifications effectively can help you stay informed about the projects you care about without being overwhelmed by updates.

Q. Explain the different notification configuration options

→ GitHub provides several options to configure your notifications:

• Notification Delivery Options: You can receive notifications for activity on GitHub.com in the following locations:
• The notifications inbox in the GitHub.com web interface
• The notifications inbox on GitHub Mobile, which syncs with the inbox on GitHub.com
• An email client that uses a verified email address, which can also sync with the notifications inbox on GitHub.com and GitHub Mobile
• Inbox Triage Options: The notifications inbox on GitHub.com and GitHub Mobile includes triaging options designed specifically for your GitHub notifications flow. This includes options to:
• Triage multiple notifications at once
• Mark completed notifications as Done and remove them from your inbox
• Save a notification to review later
• Unsubscribe and remove a notification from your inbox
• Preview the issue or pull request where the notification originates on GitHub.com from within the notifications inbox
• Custom Filters: You can create custom filters to focus on different notifications when you want.
• Group Notifications: You can group notifications in your inbox by repository or date to get a quick overview with less context switching.
• Organization and Author Filters: You can now filter your web notifications by organization or author on GitHub.
• Activity Type Filter: To filter notifications for specific activity on GitHub.com, you can use the is query.

Remember, managing your notifications effectively can help you stay informed about the projects you care about without being overwhelmed by updates.

Q. Explain how to create a GitHub gist

→Here are the steps to create a GitHub Gist:

1. Sign in to your GitHub account.
2. Navigate to your gist home page by clicking on your profile picture in the top right corner of the GitHub homepage. From the dropdown menu, select “Your gists”.
3. Click the “+” symbol in the top right hand corner to create a new gist.
4. In the “Gist description” field, you can optionally type a description for your gist.
5. In the “Filename including extension” field, type a file name for your gist, including the file extensions.
6. In the file contents field, type the text of your gist.

Remember, you can create two kinds of gists: public and secret. Create a public gist if you’re ready to share your ideas with the world or a secret gist if you’re not. Every gist is a Git repository, which means that it can be forked and cloned. If you are signed in to GitHub when you create a gist, the gist will be associated with your account and you will see it in your list of gists when you navigate to your gist home page.

Q. Describe how to fork and clone a gist

→ Here are the steps to fork and clone a Gist on GitHub:

Forking a Gist:

1. Navigate to the Gist you want to fork.
2. In the upper right corner of the page, click the Fork button.
3. GitHub will create a copy of the Gist under your account.

Cloning a Gist:

1. Navigate to the forked Gist under your account.
2. Under the repository name, click the Clone or Download button.
3. Copy the URL provided.
4. Open Terminal (or Git Bash if you’re on Windows).
5. Change the current working directory to the location where you want the cloned directory.
6. Type git clone, and then paste the URL you copied earlier. It will look like this: git clone https://gist.github.com/YOUR_USERNAME/...
7. Press Enter. Your local clone will be created.

Now, you have a local copy of your fork of the Gist, and you can make changes to it on your local machine. Remember to push any changes you make to GitHub so that they’re reflected in your Gist on GitHub. If you want to keep your forked Gist updated with the original Gist, you can fetch and merge changes from the original Gist repository.

Q.Explain GitHub Wiki pages

→ GitHub Wiki pages are a section of a GitHub repository used to host documentation for your project. They allow you to share long-form content about your project, such as how to use it, how you designed it, or its core principles.

Here are some key points about GitHub Wiki pages:

• Availability: Wikis are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server.
• Content Creation: You can write content just like everywhere else on GitHub. GitHub uses its open-source Markup library to convert different formats into HTML, so you can choose to write in Markdown or any other supported format.
• Visibility: If you create a wiki in a public repository, the wiki is available to the public. If you create a wiki in a private repository, only people with access to the repository can access the wiki.
• Editing: You can edit wikis directly on GitHub, or you can edit wiki files locally. By default, only people with write access to your repository can make changes to wikis, although you can allow everyone on GitHub.com to contribute to a wiki in a public repository.
• Local Editing: Wikis are part of Git repositories, so you can make changes locally and push them to your repository using a Git workflow.

In summary, GitHub Wiki pages are a useful tool for creating and managing documentation for your projects, allowing others to use and contribute to your project.

Q. Describe how to create, edit, and delete wiki pages

→ There are the steps to create, edit, and delete GitHub Wiki pages:

Creating a Wiki Page

1. Navigate to the main page of the repository on GitHub.com.
2. Under your repository name, click Wiki.
3. In the upper-right corner of the page, click New Page.
4. Optionally, to write in a format other than Markdown, use the Edit mode dropdown to choose a different format.
5. Use the text editor to add your page’s content.
6. In the Edit message field, type a commit message describing the new file you’re adding.
7. To commit your changes to the wiki, click Save Page.

Editing a Wiki Page

1. Navigate to the main page of the repository on GitHub.com.
2. Under your repository name, click Wiki.
3. Using the wiki sidebar on the right, navigate to the page you want to change.
4. In the upper-right corner of the page, click Edit.
5. Use the text editor to edit the page’s content.
6. In the Edit message field, type a commit message describing the changes you’re making.
7. To commit your changes to the wiki, click Save Page.

Deleting a Wiki Page

1. Navigate to the main page of the repository on GitHub.com.
2. Under your repository name, click Wiki.
3. Using the wiki sidebar on the right, navigate to the page you want to delete.
4. In the upper-right corner of the page, click Edit.
5. In the upper-right corner of the page, click Delete.

Please note that the Delete button might not appear for the Home page. If you want to delete the Home page, you need to rename it to something else first. Also, remember that wikis are part of Git repositories, so you can make changes locally and push them to your repository using a Git workflow.

Q. Explain the visibility of wiki pages

→ The visibility of GitHub Wiki pages depends on the visibility settings of the repository where the wiki is hosted:

• Public Repositories: If you create a wiki in a public repository, the wiki is available to the public.
• Private Repositories: If you create a wiki in a private repository, only people with access to the repository can access the wiki.

By default, only people with write access to your repository can make changes to wikis. However, you can allow everyone on GitHub.com to contribute to a wiki in a public repository.

Please note that search engines will only index wikis with 500 or more stars that you configure to prevent public editing. If you need search engines to index your content, you can use GitHub Pages in a public repository.

Remember, you can change the visibility settings of your repository at any time. To do this, navigate to the Settings tab in your repository, then select Pages under the Code and automation section. From there, you can select the desired visibility from the GitHub Pages visibility dropdown menu.

Q. Describe GitHub Pages

→ GitHub Pages is a static site hosting service that takes HTML, CSS, and JavaScript files straight from a repository on GitHub, optionally runs the files through a build process, and publishes a website. Here are some key points about GitHub Pages:

• User or Organization Site: You can create a user or organization site by creating a new repository named username.github.io or organization.github.io, where username or organization is your username or organization name on GitHub.
• Project Site: You can also create a project site for a specific project in your GitHub account.
• Content Creation: You can create and edit the content of your site directly on GitHub or locally on your computer.
• Publishing: Once you push your changes to the repository, GitHub Pages will automatically build and publish your site.
• Custom URLs: You can use your own custom domain for a GitHub Pages site.
• Jekyll Integration: GitHub Pages has built-in support for Jekyll, a static site generator that allows you to write content in Markdown.
• Availability: GitHub Pages is available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server.

In summary, GitHub Pages is a convenient way to create and host a website directly from your GitHub repository.

Domain 4: Modern Development

Q. Describe GitHub Actions (basic understanding)

→ GitHub Actions is a continuous integration/continuous deployment (CI/CD) platform that automates your software development workflows right within your GitHub repository. Here are some key points about GitHub Actions:

• Automation: You can automate, customize, and execute your software development workflows, including building, testing, and deploying your code.
• Workflows: Workflows are configurable automated processes made up of one or more jobs. You define your workflow configuration in a YAML file.
• Actions: Actions are individual tasks that you can combine to create jobs and customize your workflow.
• Events: You can configure your workflows to run when specific activity on GitHub happens, at a scheduled time, or when an event outside of GitHub occurs.
• Runners: Workflows run on runners, which are virtual machines that GitHub provides. Runners can be hosted by GitHub or you can host your own.
• Language Support: GitHub Actions supports Node.js, Python, Java, Ruby, PHP, Go, Rust, .NET, and more.

In summary, GitHub Actions allows you to automate your software workflows, making it easier to ensure consistent and reliable delivery of your project.

Q. Explain where you can use GitHub Actions within GitHub (general event types)

→ GitHub Actions can be used within GitHub to automate a wide variety of tasks. These tasks can be triggered by different types of events. Here are some general event types where you can use GitHub Actions:

• Push: Triggers the workflow when commits are pushed to the repository.
• Pull Request: Triggers the workflow when pull requests are created or updated.
• Schedule: Triggers the workflow at scheduled times.
• Manual: Triggers the workflow manually from the GitHub interface.
• Release: Triggers the workflow when a release is created.
• Fork: Triggers the workflow when a repository is forked.
• Issue Comment: Triggers the workflow when a comment is posted on an issue.
• Check Run: Triggers the workflow when a check run or check suite event occurs.
• Create/Delete: Triggers the workflow when a branch or tag is created or deleted.

These are just a few examples. There are many other events that can trigger workflows in GitHub Actions. You can configure your workflows to run when specific activity on GitHub happens, at a scheduled time, or even when an event outside of GitHub occurs. This makes GitHub Actions a powerful tool for automating all kinds of tasks within your GitHub repositories.

Q. Explain where you can find existing GitHub Actions

→ You can find existing GitHub Actions in the GitHub Marketplace, which is a central location for you to discover actions created by the GitHub community. Here’s how you can find and use them:

1. Browsing Marketplace Actions in the Workflow Editor: In your repository, navigate to the workflow file you want to edit. In the upper right corner of the file view, click to open the workflow editor. To the right of the editor, use the GitHub Marketplace sidebar to browse actions.
2. Adding an Action from GitHub Marketplace: Navigate to the action you want to use in your workflow. Click to view the full marketplace listing for the action. Under “Installation”, click to copy the workflow syntax. Paste the syntax as a new step in your workflow.

Actions with the badge indicate GitHub has verified the creator of the action as a partner organization. You can also search and browse actions directly in your repository’s workflow editor. The GitHub Marketplace page enables you to filter for actions by category.

Remember, you can add an action to your workflow by referencing the action in your workflow file. If the action requires you to provide inputs, set them in your workflow. For information on inputs an action might require, see "Finding and customizing actions".

Q. Describe GitHub Copilot

→ GitHub Copilot is an AI-powered coding assistant that helps you write code faster and with less effort. Here are some key points about GitHub Copilot:

• AI Pair Programmer: GitHub Copilot offers autocomplete-style suggestions as you code. It can provide suggestions for whole lines or entire functions directly within your editor.
• Language Support: GitHub Copilot works with a broad set of frameworks and languages, although its capabilities are strongest for Python, JavaScript, TypeScript, Ruby, Java, and Go.
• Learning from Public Code: GitHub Copilot is trained on a diverse range of public code repositories, which means it can generate code in response to a wide array of prompts.
• Integration with Editors: GitHub Copilot is available as an extension for Visual Studio Code. Once installed, it can provide suggestions directly within the editor.
• Responsible AI: GitHub Copilot includes filters to block offensive language in the prompts and to avoid synthesizing suggestions in sensitive contexts.

In summary, GitHub Copilot is a tool designed to assist developers in writing code, learning new frameworks and languages, and exploring possible solutions to coding problems.

Q. Describe the difference between GitHub Copilot for Individuals and GitHub Copilot for Business

→ GitHub Copilot for Individuals and GitHub Copilot for Business are two different offerings of the GitHub Copilot service, each designed to meet different needs.

GitHub Copilot for Individuals is designed for individual users. It provides access to the AI-powered coding assistant, helping developers write code faster. The pricing for GitHub Copilot for Individuals is $10 USD per month.

GitHub Copilot for Business, on the other hand, is designed for organizations and enterprise accounts. It makes it easier for companies to purchase and manage licenses for their entire team. With Copilot Business, you can manage access to GitHub Copilot for organizations. Once you grant an organization access to GitHub Copilot, the administrators of that organization can grant access to individuals and teams. The pricing for GitHub Copilot for Business is $19 USD per user per month

In summary, while both offerings provide access to the GitHub Copilot service, the key difference lies in the management of access and licenses. GitHub Copilot for Individuals is designed for personal use, while GitHub Copilot for Business provides additional features for managing access at an organizational level.

Q. Explain how to get started using GitHub Copilot

→ Here are the steps to get started with GitHub Copilot:

1. Setting up a GitHub Copilot Subscription

• Before you can start using GitHub Copilot, you will need to set up a free trial or subscription for your personal account1.
• In the upper-right corner of any page, click your profile photo, then click Settings.
• In the Code, planning, and automation section of the sidebar, click GitHub Copilot.
• On the GitHub Copilot settings page, click Enable GitHub Copilot.
• Choose whether you want to pay monthly or yearly, and click Continue to get access to Copilot.

2. Installing the GitHub Copilot Extension in Visual Studio Code

• To use GitHub Copilot, you must first install the GitHub Copilot extension.
• In the Visual Studio Code Marketplace, go to the GitHub Copilot extension page and click Install.
• A popup will appear, asking to open Visual Studio Code. Click Open Visual Studio Code.
• In the Extension: GitHub Copilot tab in Visual Studio Code, click Install.

3. Authorizing GitHub Copilot

• If you have not previously authorized Visual Studio Code in your GitHub account, you will be prompted to sign in to GitHub in Visual Studio Code.
• If you have previously authorized Visual Studio Code for your account on GitHub, GitHub Copilot will be automatically authorized.

4. Seeing Your First Suggestion

• Once you’ve installed and authorized GitHub Copilot, you can start coding in Visual Studio Code. As you type, GitHub Copilot will provide autocomplete-style suggestions.

Remember, GitHub Copilot is a powerful tool that can help you write code faster and with less effort. It’s like having a pair programmer that’s always ready to help.

GitHub Codespaces is a cloud-based development environment that allows you to write, run, debug, test, and deploy code directly from your browser123. Here are some key points about GitHub Codespaces:

• Cloud-Based Environment: A codespace is a development environment that’s hosted in the cloud3. Each codespace you create is hosted by GitHub in a Docker container, running on a virtual machine3.
• Customization: GitHub Codespaces are fully customizable on a per-project basis1. You can customize your project for GitHub Codespaces by committing configuration files to your repository3.
• Instant Access: GitHub Codespaces allows you to start coding instantly with fully configured dev environments in the cloud that start in seconds2.
• Device Independence: You can code from any device with internet access2. All you need is a web browser3.
• Resource Allocation: You can choose from a selection of virtual machine types, from 2 cores, 8 GB RAM, and 32 GB storage, up to 32 cores, 64 GB RAM, and 128 GB storage3.
• Integration with Editors: You can connect to your codespaces from your browser, from Visual Studio Code, from the JetBrains Gateway application, or by using GitHub CLI3.

In summary, GitHub Codespaces provides a convenient, customizable, and powerful cloud-based development environment that allows you to code from anywhere, on any device123.

Q. Describe GitHub Codespaces

→ GitHub Codespaces is a cloud-based development environment that allows you to write, run, debug, test, and deploy code directly from your browser. Here are some key points about GitHub Codespaces:

• Cloud-Based Environment: A codespace is a development environment that’s hosted in the cloud. Each codespace you create is hosted by GitHub in a Docker container, running on a virtual machine.
• Customization: GitHub Codespaces are fully customizable on a per-project basis. You can customize your project for GitHub Codespaces by committing configuration files to your repository.
• Instant Access: GitHub Codespaces allows you to start coding instantly with fully configured dev environments in the cloud that start in seconds.
• Device Independence: You can code from any device with internet access. All you need is a web browser.
• Resource Allocation: You can choose from a selection of virtual machine types, from 2 cores, 8 GB RAM, and 32 GB storage, up to 32 cores, 64 GB RAM, and 128 GB storage.
• Integration with Editors: You can connect to your codespaces from your browser, from Visual Studio Code, from the JetBrains Gateway application, or by using GitHub CLI.

In summary, GitHub Codespaces provides a convenient, customizable, and powerful cloud-based development environment that allows you to code from anywhere, on any device.

Q. Identify how to start a GitHub codespace

→ Here are the steps to start a GitHub Codespace:

1. Navigate to the Repository

• On GitHub.com, navigate to the main page of the repository.
• Under the repository name, select the branch dropdown menu, which is labeled with the name of the current branch, then click the branch you want to create a codespace for.
• Click the Code button, then click the Codespaces tab.

2. Create a New Codespace

• Click New codespace.
• Select the repository and branch that you want to have cloned onto your codespace, as well as the region and machine type to run your codespace.
• Then select Create codespace. You will then see the codespace container being provisioned.

3. Run the Application

• Once your codespace is created, the template repository will be automatically cloned into it.
• Now you can run the application and launch it in a browser.
• When the terminal becomes available, enter the command npm run dev. This example uses a Node.js project, and this command runs the script labeled “dev” in the package.json file, which starts up the web application defined in the sample repository.
• If you’re following along with a different application type, enter the corresponding start command for that project.
• When your application starts, the codespace recognizes the port the application is running on and displays a pop-up message to let you know that the port has been forwarded.
• Click Open in Browser to view your running application in a new tab.

4. Edit the Application and View Changes

• Switch back to your codespace and open the haikus.json file by clicking it in the Explorer.
• Edit the text field of the first haiku to personalize the application with your own haiku.
• Go back to the running application tab in your browser and refresh to see your changes.
• If you’ve closed the browser tab, click the Ports tab in VS Code, hover over the Local Address value for the running port, and click the Open in Browser icon.

5. Committing and Pushing Your Changes

• Now that you’ve made a few changes, you can use the integrated terminal or the source view to publish your work to a new repository.
• In the Activity Bar, click the Source Control view.
• To stage your changes, click next to the haikus.json file, or next to Changes if you’ve changed multiple files and you want to stage them all.
• To commit your staged changes, type a commit message describing the change you’ve made, then click Commit.
• Click Publish Branch.
• In the Repository Name dropdown, type a name for your new repository, then select Publish to GitHub private repository or Publish to GitHub public repository. The owner of the new repository will be the GitHub account with which you created the codespace.

That’s it! You’ve now created and used a GitHub Codespace.

Q. Describe the codespace lifecycle

→ The lifecycle of a GitHub Codespace involves several stages, from creation to deletion:

1. Creating a Codespace: You can create a new codespace or open an existing one when you want to work on a project. You might want to create a new codespace from a branch of your repository each time you develop in GitHub Codespaces or keep a long-running codespace for a feature. If you’re starting a new project, you might want to create a codespace from a template and publish to a repository on GitHub later.

2. Saving Changes in a Codespace: When you connect to a codespace through the web, auto-save is enabled automatically for the web editor and configured to save changes after a delay. When you connect to a codespace through Visual Studio Code running on your desktop, you must enable auto-save.

3. Timeouts for GitHub Codespaces: If you’re inactive in a codespace for a period of time, the codespace will stop to conserve resources. The exact timeout period depends on your GitHub plan.

4. Rebuilding a Codespace: If you need to reset your codespace environment, you can rebuild it. This will delete the codespace and create a new one with the same settings.

5. Stopping a Codespace: You can stop a codespace when you’re done working with it. Stopping a codespace will deallocate the resources but maintain the state, so you can continue where you left off the next time you start the codespace.

6. Deleting a Codespace: When you no longer need a codespace, you can delete it. This will permanently remove the codespace and all its data.

Throughout the lifecycle of a codespace, you can disconnect and reconnect to an active codespace without affecting its running processes. You may stop and restart a codespace without losing changes that you have made to your project.

Q. Describe the different customizations you can personalize with GitHub Codespaces

→ GitHub Codespaces offers a range of customization options to personalize your coding environment according to your preferences. Here are some of the key customizations you can make:

1. Renaming a Codespace: You can rename your codespace to better suit your project or workflow.
2. Changing the Shell in a Codespace: You can change the shell in your codespace, allowing you to use your preferred command-line interface.
3. Changing the Machine Type for Your Codespace: You can change the machine type for your codespace to better match the requirements of your project.
4. Settings Sync: This feature allows you to synchronize your Visual Studio Code settings between the desktop application and the VS Code web client.
5. Dotfiles: You can use a dotfiles repository to specify scripts, shell preferences, and other configurations.
6. Setting the Linux-based Operating System: You can set the Linux-based operating system to use.
7. Automatically Installing Various Tools, Runtimes, and Frameworks: You can customize your codespace to automatically install various tools, runtimes, and frameworks.
8. Setting Your Default Editor: You can set your default editor for GitHub Codespaces.

Remember, these personalizations apply to any codespace you create. Project maintainers can also define a default configuration that applies to every codespace for a repository, created by anyone.

Q. Recognize how to add and configure dev containers

→ Here’s how you can add and configure development containers (dev containers) in GitHub Codespaces:

1. Adding a Dev Container Configuration: You can add a dev container configuration to your repository by accessing the Visual Studio Code Command Palette with Shift + Command + P (Mac) or Ctrl + Shift + P (Windows/Linux). Start typing “add dev” then click Codespaces: Add Dev Container Configuration Files. Click Create a new configuration. Click Show All Definitions. Click the definition you want to use. Follow the prompts to customize your definition. Click OK.
2. Modifying a Dev Container Configuration: To modify an active configuration, access the VS Code Command Palette with Shift + Command + P (Mac) or Ctrl + Shift + P (Windows/Linux). Start typing “add dev” then click Codespaces: Add Dev Container Configuration Files. Click Modify your active configuration. Update your feature selections, then click OK.
3. Customizing Dev Containers: You can customize the dev container configuration for your repository. This includes setting a minimum specification for codespace machines, adding features to a devcontainer.json file, automatically opening files in the codespaces for a repository, and specifying recommended secrets for a repository.
4. Applying Configuration Changes to a Codespace: To apply configuration changes to a codespace, you can add or remove settings from the configuration files and rebuild the container to apply the changes to the codespace you’re working in

Remember, the primary file in a dev container configuration is the devcontainer.json file. You can define a single dev container configuration for a repository, different configurations for different branches, or multiple configurations.

Q. Identify how to share a deep link to a GitHub codespace

→

Sure, here’s how you can share a deep link to a GitHub Codespace:

1. Navigate to the main page of the repository on GitHub.com.
2. If you want to create a link for a branch other than the repository’s default branch, under the repository name, click the button labeled with the name of the current branch. In the dropdown menu, select the branch for which you want to create a link.
3. Click the Code button, then click the Codespaces tab.
4. To open the “Share codespace configuration” window, at the top right of the Codespaces tab, select the ... button, then click Share a deep link.
5. Optionally, to take users to a page where they can quickly resume a recent codespace or create a new one, select Quick start.
6. Optionally, to specify a dev container configuration, select Configuration file, then use the dropdown menu to choose a configuration.
7. Under “Snippets,” you can copy the URL you have built, or copy a Markdown or HTML snippet including an “Open in GitHub Codespaces” badge.

You can use these URLs to link to the codespace creation page for your repository. Replace the text in uppercase letters:

• Create a codespace for the default branch of the repository: https://codespaces.new/OWNER/REPO-NAME
• Create a codespace for a specific branch of the repository: https://codespaces.new/OWNER/REPO-NAME/tree/BRANCH-NAME
• Create a codespace for the topic branch of a pull request: https://codespaces.new/OWNER/REPO-NAME/pull/PR-SHA

Remember, the person who uses the link will be able to choose different options, if they want, before creating the codespace.

Q. Explain how to use the github.dev editor

→ Here’s how you can use the github.dev web-based editor:

1. Opening the github.dev editor: You can open any GitHub repository in github.dev in either of the following ways:

• Press the . key while browsing any repository or pull request on GitHub.
• Change the URL from “github.com” to "github.dev".
• When viewing a file, select the dropdown menu and click github.dev2.

1. Using the github.dev editor: The github.dev editor introduces a lightweight editing experience that runs entirely in your browser. With the github.dev editor, you can navigate files and source code repositories from GitHub, and make and commit code changes. The editor provides many of the benefits of Visual Studio Code, such as search, syntax highlighting, and a source control view.
2. Using Settings Sync: You can also use Settings Sync to share your own VS Code settings with the editor.
3. Saving Your Work: Your work is saved in the browser’s local storage until you commit it. You should commit your changes regularly to ensure that they’re always accessible.
4. Using github.dev behind a firewall: If you’re using github.dev behind a firewall, there are certain considerations to keep in mind1.

Remember, you must be signed in to GitHub.com to use the github.dev editor. Also, the github.dev editor is currently in beta preview, so you can provide feedback in GitHub Discussions.

Q. Explain the differences between the github.dev editor and a GitHub Codespace

→ Here are the key differences between the github.dev editor and a GitHub Codespace:

1. Environment: GitHub Codespaces provides a complete, configurable, and isolated development environment in the cloud. It’s hosted on a virtual machine and runs in a Docker container. On the other hand, the github.dev editor is a lightweight, web-based editor that runs entirely in your browser.
2. Compute Resources: With GitHub Codespaces, you get the power of a dedicated virtual machine on which you can run and debug your application. The github.dev editor, however, does not have associated compute resources, so you won’t be able to build and run your code or use the integrated terminal.
3. Terminal Access: GitHub Codespaces provides terminal access, allowing you to use the terminal exactly as you would in your local environment. The github.dev editor does not provide terminal access.
4. Configuration: GitHub Codespaces allows you to customize your project by committing configuration files to your repository, creating a repeatable codespace configuration for all users of your project. The github.dev editor does not support this level of customization.
5. Cost: GitHub Codespaces has a free monthly quota of usage for personal accounts, but beyond that, there is a cost associated with its usage. The github.dev editor is available to everyone for free on GitHub.com.
6. Startup Time: github.dev opens instantly with a key-press and you can start using it right away, without having to wait for additional configuration or installation. When you create or resume a codespace, the codespace is assigned a VM and the container is configured based on the contents of a devcontainer.json file. This setup may take a few minutes to create the environment.

Remember, both github.dev and GitHub Codespaces allow you to edit your code straight from your repository, but they offer slightly different benefits depending on your use case.

Domain 5: Project Management

Q. Describe GitHub Projects

→ GitHub Projects is an adaptable, flexible tool for planning and tracking work on GitHub. Here are some key features:

• Adaptable Spreadsheet, Task-Board, and Road Map: A project integrates with your issues and pull requests on GitHub to help you plan and track your work effectively.
• Customization: You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team.
• Integration: Information is synced automatically to your project as you make changes, updating your views and charts. This integration works both ways, so that when you change information about a pull request or issue in your project, the pull request or issue reflects that information.
• Adding Metadata: You can use custom fields to add metadata to your issues, pull requests, and draft issues and build a richer view of item attributes.
• Automation: Built-in workflows allow you to automatically set fields when items are added or changed, and you can also configure your project to automatically archive items when they meet certain criteria and automatically add items from a repository when they match set criteria.
• API and GitHub Actions: You can use the GraphQL API and GitHub Actions to take even greater control of your project.

In summary, GitHub Projects is a powerful tool that can be tailored to fit your team’s needs and processes, making it an excellent choice for managing and tracking work on GitHub.

Q. Explain the layout options for projects

→ GitHub Projects provides three layout options for your project views:

1. Table: This is a high-density layout that displays your project’s items in a tabular format. It’s ideal for when you want to see a lot of information at once and perform bulk actions.
2. Board: This layout arranges your project’s items over customizable columns, similar to a Kanban board. It’s great for visualizing the flow of work and understanding the status of tasks at a glance.
3. Roadmap: This timeline-style layout allows you to view your project’s items on a timeline. It’s useful for planning and tracking progress over time.

You can switch between these layouts at any time to suit your needs2. Each layout provides different perspectives on your project’s data, helping you plan, track, and manage your work effectively.

Q. Describe the configuration options for projects

→ GitHub Projects provides a variety of configuration options to help you customize your project to suit your needs:

1. Project Description and README: You can set your project’s description and README to share the purpose of your project, provide instructions on how to use the project, and include any relevant links.
2. Adding Issues and Draft Issues: You can add existing issues from repositories owned by your organization (for organization projects) or by you (for user projects) to your new project.
3. Custom Fields: You can create custom fields to track specific information about your tasks. For example, you can create a field to track the priority of each task.
4. Saved Views: You can create saved views that help you communicate priorities and progress with your collaborators.
5. Built-in Workflows: You can set up built-in workflows to manage the items in your project. For example, you can configure your project to automatically archive items when they meet certain criteria.
6. Layouts: You can choose between Table, Board, and Roadmap layouts for your project.

Remember, these are just some of the configuration options available in GitHub Projects. The tool is highly customizable and can be tailored to fit your team’s needs and processes.

Q. Explain the difference between projects and projects classic

→ GitHub Projects and GitHub Projects Classic are both project management tools offered by GitHub, but they have some differences in terms of features and usage:

GitHub Projects:

• Offers three layout options: Table, Board, and Timeline.
• Allows you to create and customize multiple views by filtering, sorting, grouping your issues and pull requests.
• Provides built-in workflows to automate certain tasks.
• Supports custom fields to track specific information about your tasks.
• Information is synced automatically to your project as you make changes.
• Supports integration with the GraphQL API and GitHub Actions.

GitHub Projects Classic:

• Organizes work into boards with columns, and items are represented as cards that can be moved between columns.
• Cards can represent issues, pull requests, or notes.
• Allows for the creation of notes within columns to serve as task reminders, references to issues and pull requests, or to add information related to the project.
• Supports three types of projects: User-owned projects (can contain issues and pull requests from any personal repository), Organization-wide projects (can contain issues and pull requests from any repository that belongs to an organization), and Repository projects (scoped to issues and pull requests within a single repository).

In summary, while both versions allow for project management within GitHub, the newer GitHub Projects provides more flexibility and customization options compared to GitHub Projects Classic.

Q. Explain the use of labels

→ Labels in GitHub are tags that can be applied to issues, pull requests, and discussions to categorize and organize them. Here’s how they are used:

1. Categorization: Labels help you manage your work by categorizing issues, pull requests, and discussions. Once a label is created in a repository, it can be used on any issue, pull request, or discussion within that repository.
2. Default Labels: GitHub provides default labels in every new repository to help create a standard workflow. These include labels like bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, question, and wontfix.
3. Creating Labels: Anyone with write access to a repository can create a label. This involves specifying a name and description for the label, and optionally customizing its color.
4. Applying Labels: Labels can be applied to issues, pull requests, and discussions by anyone with triage access to a repository.
5. Editing Labels: Labels can be edited by anyone with write access to a repository. This can involve changing the label’s name, description, or color.
6. Searching: Labels can be used to locate a particular type of issue. For example, you can click on a label to see a filtered list of open issues in the repository.

In summary, labels are a powerful tool for managing and organizing your work on GitHub.

Q. Explain the use of milestones

→ Milestones in GitHub are used to track progress on groups of issues or pull requests in a repository. Here’s how they are used.

1. Grouping Issues and Pull Requests: When you create a milestone, you can associate it with issues and pull requests. This helps in tracking the progress of related tasks.
2. Tracking Progress: Each milestone has a progress bar that shows the completion percentage based on the number of open and closed issues and pull requests associated with it.
3. Setting Deadlines: You can set a due date for a milestone to help manage timelines and expectations.
4. Prioritizing Tasks: You can prioritize open issues and pull requests in a milestone by dragging and dropping them in the order you prefer.
5. Viewing Details: From the milestone page, you can see a user-provided description of the milestone, the milestone’s due date, the milestone’s completion percentage, and a list of the open and closed issues and pull requests associated with the milestone.

In summary, milestones are a useful tool for organizing and tracking work in a GitHub repository.

Q. Describe how to use and create template repos

→ GitHub template repositories are a great way to share and reuse code or other project structures. Here’s how you can use and create them:

Using a Template Repository:

1. Go to https://github.com/new.
2. Above the file list, choose your Repository template.
3. Select whether you want to include all branches, not just the default one.
4. Choose the owner.
5. Add a name to the new repo and an optional description.
6. Set the visibility of a repository.

Creating a Template Repository:

1. Navigate to the main page of the repository you want to make a template.
2. Under your repository name, click Settings.
3. If you cannot see the Settings tab, select the dropdown menu, then click Settings.
4. Select Template repository.

After you make your repository a template, anyone with access to the repository can generate a new repository with the same directory structure and files as your default branch. They can also choose to include all the other branches in your repository.

Please note that branches created from a template have unrelated histories, so you cannot create pull requests or merge between the branches. Also, your template repository cannot include files stored using Git LFS.

Q. Explain how to create, edit, and delete saved replies

→ Here’s how you can create, edit, and delete saved replies on GitHub:

Creating a Saved Reply:

1. In the upper-right corner of any page, click your profile photo, then click Settings.
2. In the “Code, planning, and automation” section of the sidebar, click Saved replies.
3. Under “Add a saved reply”, add a title for your saved reply and the content you want to save.
4. Click Add saved reply.

Editing a Saved Reply:

1. In the upper-right corner of any page, click your profile photo, then click Settings.
2. In the “Code, planning, and automation” section of the sidebar, click Saved replies.
3. Under “Saved replies”, next to the saved reply you want to edit, click the pencil icon.
4. Under “Edit saved reply”, edit the title or content of the saved reply as needed.
5. Click Update saved reply.

Deleting a Saved Reply:

1. In the upper-right corner of any page, click your profile photo, then click Settings.
2. In the “Code, planning, and automation” section of the sidebar, click Saved replies.
3. Under “Saved replies”, next to the saved reply you want to delete, click the trash bin icon.

Remember, saved replies are tied to your personal account and can be used across repositories and organizations. They’re a great way to save time if you find yourself frequently typing the same responses.

Q. Describe the benefits of using a saved reply

→ Saved replies in GitHub offer several benefits:

1. Efficiency: Saved replies allow you to respond quickly to common questions or requests. This can save you a significant amount of time if you often find yourself typing out the same responses.
2. Consistency: By using saved replies, you can ensure that your responses are consistent across different issues and pull requests. This can be particularly useful in maintaining a consistent tone and style across your project.
3. Organization: Saved replies can help you manage and organize your responses. You can create different saved replies for different types of issues or requests, making it easier to manage your communications.
4. Reusability: Once you’ve created a saved reply, you can use it across different repositories and organizations. This means you don’t have to recreate the same responses for each new project.
5. Customization: Saved replies can be customized to fit your needs. You can create, edit, and delete saved replies as needed.

In summary, saved replies are a powerful tool that can help you communicate more effectively and efficiently on GitHub.

Q. Recognize how to add assignees to issues and pull requests

→ Here’s how you can add assignees to issues and pull requests on GitHub:

Assigning an Individual Issue or Pull Request:

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click Issues or Pull requests.
3. Open the issue or pull request that you want to assign to someone.
4. In the right side menu, click Assignees.
5. To assign the issue or pull request to a user, start typing their username, then click their name when it appears. You can select and add up to ten assignees to an issue or pull request.

Assigning Multiple Issues or Pull Requests:

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click Issues or Pull requests.
3. Select the items you want to assign to someone.
4. In the upper-right corner, click Assign.
5. To assign the items to a user, start typing their username, then click their name when it appears. You can select and add up to ten assignees to an issue or pull request.

Remember, anyone with write access to a repository can assign issues and pull requests.

Q. Explain how to use project workflows

→ Project workflows in GitHub are a powerful tool for automating tasks related to project management. Here’s how you can use them:

1. Creating and Managing Workflows: You can create workflows that contain a series of tasks that are performed automatically every time the workflow runs. For example, you can create a workflow that runs every time an issue is created to add a label, leave a comment, and move the issue onto a project.
2. Triggering a Workflow: You can configure your workflows to run on a schedule or be triggered when an event occurs. For example, you can set your workflow to run when someone creates an issue in a repository.
3. Workflow Actions: Workflows can perform many actions, such as commenting on an issue, adding or removing labels, moving cards on projects, and opening issues.
4. Reusing Workflows: You can reuse workflows across different projects to ensure consistency and save time.
5. Built-in Automations: GitHub Projects also provides built-in workflows that you can enable or disable for your project. You can edit these workflows to apply to issues, pull requests, or both.

Remember, to use project workflows effectively, it’s important to plan your workflows carefully and test them thoroughly before implementing them.

Q. Describe project insights

→ Project Insights in GitHub is a feature that allows you to view and customize charts built from your project’s data. Here are some key features:

• Current Charts: You can create current charts to visualize your project items. For example, you can create charts to show how many items are assigned to each individual, or how many issues are assigned to each upcoming iteration.
• Historical Charts: You can create historical charts to visualize your project items over time. Historical charts track changes to the state of your project items. You can see “Open” items with open issues and pull requests, “Completed” items with issues that were closed as completed or merged pull requests, “Closed pull requests”, and “Not planned” items with issues that were closed as not planned.
• Burn Up Chart: The default “Burn up” chart allows you to visualize the progress of your issues over time, showing how much work is completed and how much is left to do. You can use this chart to view progress, spot trends, and identify bottlenecks to help move the project forward.
• Filtering: You can apply filters to the default chart and also create your own charts. When you create a chart, you set the filters, chart type, the information displayed, and the chart is available to anyone that can view the project.
• Access: People with write or admin access to a project can use Insights1. Insights is available for the new Projects experience, you cannot use Insights with projects (classic).

Please note that Insights does not track items you have archived or deleted.

Domain 6: Privacy, Security, and Administration

Q. Explain how to secure your account with 2FA

→ Two-Factor Authentication (2FA), also known as Multi-Factor Authentication (MFA), adds an extra layer of security to your online accounts by requiring two types of identification before you can access them. Here’s a general guide on how to secure your account with 2FA:

1. Choose a 2FA Method: The most common methods are SMS text messages, authentication apps, and hardware tokens. Authentication apps, such as Google Authenticator, Microsoft Authenticator, or Authy, generate a constantly rotating set of numeric codes to use for login.
2. Enable 2FA in Account Settings: This usually involves going to the security settings of your account and turning on 2FA. For example, in Google Account, you can select Security in the navigation panel, then under How you sign in to Google, select 2-Step Verification Get started.
3. Follow the On-Screen Instructions: This typically involves entering your password, receiving a code on your chosen device or app, and then entering that code into a form.
4. Backup Your 2FA: Most services will give you backup codes or allow you to set up alternative 2FA methods in case you lose access to your primary method. It’s important to store these safely.
5. Test Your 2FA: Sign out and sign back into your account to make sure the 2FA is working correctly.

Remember, using 2FA significantly increases the security of your online accounts by ensuring that even if someone obtains your password, they won’t be able to access your account without the second factor.

Q. Describe the different access permissions

→ Access permissions regulate who can access what in a digital system1. They are typically categorized based on the objects to which they can be applied2. Here are some common types of access permissions:

1. Role-Based Permissions: These permissions are assigned to roles, and users are then assigned these roles1. For example, an “Admin” role might have permissions to read, write, and delete data, while a “User” role might only have read permissions.
2. Permission-Based Access Control: This technique defines specific permissions for every entity using a system. Each permission typically is a tuple indicating both a resource and an operation. Usual permissions relate to reading, editing, and deleting operations of a given digital resource.
3. Device-Based Permissions: These permissions are based on the device being used to access the system. For example, a user might have different permissions when accessing a system from a company-owned device versus a personal device.
4. Location-Based Privileges: These permissions change based on the user’s current location. For example, a user might have more access permissions when they are at their workplace compared to when they are accessing the system remotely.
5. Application Permissions: These permissions control what resources an application can access on a device. For example, an application might request permission to access a user’s camera, microphone, or location data.

Remember, the exact types and granularity of access permissions can vary greatly depending on the specific system or platform.

Q. Explain EMUs (Enterprise Managed Users)

→ Enterprise Managed Users (EMUs) is a feature in GitHub Enterprise Cloud that allows enterprise administrators to centrally manage identity and access for their enterprise members on GitHub from their identity provider (IdP). Here are some key points about EMUs:

1. Lifecycle and Authentication Management: With EMUs, you manage the lifecycle and authentication of your users on GitHub.com from an external identity management system, or IdP. You can provide access to GitHub Enterprise Cloud to people who have existing identities and group membership on your IdP.
2. User Account Control: Your IdP provisions new user accounts with access to your enterprise on GitHub.com. You control usernames, profile data, team membership, and repository access for the user accounts from your IdP.
3. Roles: On your IdP, you can give each managed user account a role, such as member, enterprise owner, or guest collaborator. Managed user accounts can own organizations within your enterprise and can add other managed user accounts to the organizations and teams within.
4. Restrictions: Managed user accounts have read-only access to the wider GitHub community. These visibility and access restrictions for users and content apply to all requests, including API requests. Managed user accounts authenticate using only your identity provider, and have no password or two-factor authentication methods stored on GitHub.
5. Usernames and Profile Information: The usernames of your enterprise’s managed user accounts and their profile information, such as display names and email addresses, are set by through your IdP and cannot be changed by the users themselves.
6. Auditing: Enterprise owners can audit all of the managed user accounts’ actions on GitHub.

Remember, to use Enterprise Managed Users, you need a separate type of enterprise account with Enterprise Managed Users enabled. Also, there are multiple options for identity and access management with GitHub Enterprise Cloud, and Enterprise Managed Users is not the best solution for every customer.

Q. Explain how to enable and disable features

→ Here’s how you can enable and disable features in GitHub administration:

1. Enabling Features for Your Repository: You can enable, configure, and disable optional features for your repository. This includes disabling issues if you do not accept contributions or bug reports, disabling projects in a repository if you or your team choose not to use projects, managing GitHub Actions settings for a repository, enabling or disabling GitHub Discussions for a repository, and managing security and analysis settings for your repository.
2. Managing Your Repository’s Settings and Features: You can customize your repository, enable or disable optional features for your repository, and manage your repository’s settings. This includes customizing your repository, about READMEs, licensing a repository, displaying a sponsor button in your repository, customizing your repository’s social media preview, classifying your repository with topics, about code owners, about repository languages, about CITATION files, enabling features for your repository, disabling issues, disabling projects in a repository, managing GitHub Actions settings for a repository, enabling or disabling GitHub Discussions for a repository, managing security and analysis settings for your repository, managing repository settings, setting repository visibility, managing teams and people with access to your repository, managing the forking policy for your repository, managing pull request reviews in your repository, managing the commit signoff policy for your repository, managing the push policy for your repository, managing Git LFS objects in archives of your repository, about email notifications for pushes to your repository, configuring autolinks to reference external resources, and configuring tag protection rules.
3. Managing GitHub Advanced Security Features for Your Enterprise: In the enterprise account sidebar, click Settings. In the left sidebar, click Code security & analysis. Optionally, enable or disable a feature for all existing repositories. To the right of the feature, click Disable all or Enable all.

Remember, the exact steps to enable or disable features may vary depending on the specific feature and the level of access you have in the repository or organization.

Q. In github administration Recognize repository permission levels

→ Here are the repository permission levels in GitHub:

1. Personal Account Repositories: A repository owned by a personal account has two permission levels:

• Owner: The repository owner has full control of the repository. They can invite collaborators, change the visibility of the repository, limit interactions with the repository, rename a branch, merge a pull request on a protected branch, delete the repository, manage the repository’s topics, manage security and analysis settings for the repository, enable the dependency graph for a private repository, delete and restore packages, customize the repository’s social media preview, create a template from the repository, control access to Dependabot alerts, dismiss Dependabot alerts in the repository, manage data use for a private repository, define code owners for the repository, archive the repository, create security advisories, display a sponsor button, allow or disallow auto-merge for pull requests, manage deploy keys, and manage webhooks.
• Collaborator: Collaborators have access to the repository but with more limited permissions1.

1. Organization Account Repositories: Organization members can have owner, billing manager, or member roles. You can manage access permissions for multiple members at a time with teams. For more information, see “Roles in an organization”, “Project (classic) permissions for an organization”, “Repository roles for an organization”, and "About teams".

Remember, the exact permissions associated with these roles can vary depending on the specific settings of the repository.

Q. Identify the options for repository visibility

→ In GitHub, you have three options for repository visibility:

1. Public Repositories: These repositories are visible to anyone on the internet, and GitHub users can interact with them in ways such as forking the repository, creating issues or pull requests, etc.
2. Private Repositories: These repositories are only visible to the repository owner and collaborators that the owner specifies. Only those with access can interact with the repository.
3. Internal Repositories: These repositories are available to all members of an enterprise account. Only enterprise members can view or make changes to the repository.

To change a repository’s visibility, navigate to the main page of the repository, click Settings, then in the Danger Zone section, click Change visibility. Select a visibility and confirm the change.

Remember, changing a repository’s visibility may have implications for certain features and integrations. Always review the implications and ensure you understand them before changing a repository’s visibility.

Q. Explain repository privacy setting options (branch protections, codeowners, required reviewers)

→Here’s an explanation of these GitHub repository settings:

1. Branch Protections: Branch protection rules prevent certain actions on the protected branches. The rules can enforce certain workflows, such as requiring an approving review or passing status checks for all pull requests merged into the protected branch. You can create a branch protection rule in a repository for a specific branch, all branches, or any branch that matches a name pattern you specify.
2. Codeowners: A CODEOWNERS file defines individuals or teams that are responsible for code in a repository. Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. You can specify code owners by creating a file named CODEOWNERS in the repository’s root directory (or in .github/ if you prefer) with a specific format.
3. Required Reviewers: If your repository requires reviews, pull requests must have a specific number of approving reviews from people with write or admin permissions in the repository before they can be merged4. You can set up mandatory reviewers meaning that the PR can’t get merged until certain people give their approval. For example, if you have reviewers A, B, C, D, E, and F, you can make it so that this PR cannot get merged until reviewers A and B have approved it.

Remember, these settings help maintain the quality and security of your code by ensuring that changes are reviewed and approved by the appropriate individuals.

Q. Describe the main features and options in the Security tab

→ The Security tab in GitHub provides a range of features to help keep your code and secrets secure in your repositories. Here are some of the main features and options:

1. Security Policy: This makes it easy for users to confidentially report security vulnerabilities they’ve found in your repository.
2. Security Advisories: These allow you to privately discuss and fix security vulnerabilities in your repository’s code. You can then publish a security advisory to alert your community to the vulnerability and encourage community members to upgrade.
3. Dependabot Alerts and Security Updates: These provide alerts about dependencies that are known to contain security vulnerabilities. You can choose whether to have pull requests generated automatically to update these dependencies. You can also use default Dependabot auto-triage rules curated by GitHub to automatically filter out a substantial amount of false positives.
4. Dependabot Version Updates: This feature uses Dependabot to automatically raise pull requests to keep your dependencies up-to-date. This helps reduce your exposure to older versions of dependencies.
5. Code Scanning: This feature automatically detects security vulnerabilities and coding errors in new or modified code.
6. Secret Scanning Alerts for Users: This feature automatically detects tokens or credentials that have been checked into a repository.

Remember, some features are available for repositories on all plans, while additional features are available to enterprises that use GitHub Advanced Security. Also, you can manage the security and analysis settings for your repository by navigating to the main page of the repository, clicking Settings, then in the Security section of the sidebar, clicking Code security and analysis.

Q. Define repository insights

→ Repository Insights in GitHub provide a visual representation of the activity in your repository. They include several features:

1. Traffic: This shows the number of clones and visitors to your repository over the past 14 days1. It also shows referring sites and popular content.
2. Pulse: This provides a summary of repository activity, including opened issues, proposed pull requests, and merged pull requests.
3. Contributors: This shows a list of contributors to the repository and their contributions.
4. Projects Insights: This feature allows you to view and customize charts that are built from your project’s data. You can create current charts to visualize your project items and historical charts to visualize your project items over time.

Remember, you can access these insights by navigating to the main page of the repository, clicking Insights, and then selecting the relevant section.

Q. Explain how to manage collaborators

→ Here’s a general guide on how to manage collaborators:

1. Invite Collaborators: The first step is to invite people to collaborate. This could be done through an email invitation or by sharing a collaboration link. Make sure to clearly communicate the purpose and goals of the collaboration.
2. Set Permissions: Not all collaborators need the same level of access. Some might need read-only access, while others might need the ability to edit or even manage the project. Make sure to set permissions that align with each collaborator’s role.
3. Communicate Regularly: Regular communication is key in any collaboration. This could be through regular meetings, email updates, or a collaboration platform. Make sure everyone is on the same page and aware of any updates or changes.
4. Track Progress: Use a project management tool or a task list to track the progress of the collaboration. This helps ensure that everyone knows what needs to be done and who is responsible for what.
5. Provide Feedback: Constructive feedback is important in a collaboration. It helps collaborators improve and makes the collaboration more effective. Make sure to provide regular feedback and encourage others to do the same.
6. Resolve Conflicts: Conflicts are inevitable in any collaboration. It’s important to address them promptly and constructively. Try to understand all sides of the issue and work together to find a solution.
7. Review and Reflect: Once the collaboration is complete, take the time to review and reflect on it. What went well? What could be improved? Use these insights to improve future collaborations.

Remember, every collaboration is unique, so these steps might need to be adapted to fit your specific situation. Hope this helps!

Q. Explain how to manage organization settings

→ Managing organization settings in GitHub involves several steps and options. Here’s a high-level overview:

1. Accessing Organization Settings: To access your organization’s settings, select your profile photo in the upper-right corner of GitHub.com, then click “Your organizations”. Next to the organization, click "Settings".
2. Managing Settings: Once you’re in the organization settings, you can manage various aspects:

• Verifying or Approving a Domain: You can verify or approve a domain for your organization.
• Renaming an Organization: You can change the name of the organization.
• Transferring Organization Ownership: You can transfer the ownership of the organization to another user.
• Restricting Repository Creation: You can set permissions for who can create repositories in your organization.
• Setting Permissions for Deleting or Transferring Repositories: You can set who has the ability to delete or transfer repositories.
• Restricting Repository Visibility Changes: You can restrict who can change the visibility of repositories.
• Managing the Forking Policy: You can manage the policy for forking repositories in your organization.
• Managing Pull Request Reviews: You can manage how pull request reviews are handled in your organization.
• Disabling or Limiting GitHub Actions: You can disable or limit the use of GitHub Actions for your organization.
• Configuring the Retention Period for GitHub Actions Artifacts and Logs: You can set how long artifacts and logs from GitHub Actions are retained.
• Allowing People to Delete Issues: You can allow members of your organization to delete issues.
• Enabling or Disabling GitHub Discussions: You can enable or disable GitHub Discussions for your organization.
• Managing the Commit Signoff Policy: You can manage the policy for commit signoffs in your organization.
• Setting Team Creation Permissions: You can set who can create teams within your organization.
• Managing Scheduled Reminders: You can manage reminders for your organization.
• Managing the Default Branch Name for Repositories: You can set the default branch name for new repositories in your organization.
• Managing Default Labels for Repositories: You can manage the default set of labels for new repositories in your organization.
• Managing the Display of Member Names: You can manage whether to display members’ full names in your organization.
• Managing Updates from Accounts Your Organization Sponsors: You can manage updates from accounts that your organization sponsors.
• Managing the Publication of GitHub Pages Sites: You can manage the publication of GitHub Pages sites for your organization.
• Archiving an Organization: You can archive your organization.
• Deleting an Organization Account: You can delete your organization and all of its repositories.
• Converting an Organization into a User: You can convert your organization into a user.
• Upgrading to the GitHub Customer Agreement: You can upgrade to the GitHub Customer Agreement.
• Disabling Projects in Your Organization: You can disable the Projects feature for your organization.
• Disabling Insights for Projects in Your Organization: You can disable the Insights feature for projects in your organization.
• Managing Base Permissions for Projects: You can manage the base permissions for projects in your organization.
• Allowing Project Visibility Changes in Your Organization: You can allow changes to project visibility in your organization.
• Managing Custom Properties for Repositories in Your Organization: You can manage custom properties for repositories in your organization.

Please note that only organization owners and billing managers can see and change the billing information and the full set of account settings for an organization. For more detailed instructions, you can refer to the GitHub Docs.

Q. Describe members, teams, and roles in a GitHub organization

→ GitHub Organization is a shared workspace where businesses and open-source projects can collaborate across many projects at once. Owners and administrators can manage member access to the organization’s data and projects with sophisticated security and administrative features.

Members are users who have been invited to join an organization. A user can be a member of any number of organizations.

Teams are groups of organization members that reflect your company or group’s structure with cascading access permissions and mentions.

Here are the different roles in a GitHub organization:

1. Owners: They have complete administrative access to your organization. While every organization is different, the owner role is often given to the person responsible for managing the organization’s settings, billing, and members.
2. Billing managers: They are responsible for managing the billing settings for your organization, including upgrading or downgrading your GitHub plan, reviewing invoices, and overseeing the spending limit for GitHub Actions and Packages.
3. Members: They are collaborators on an organization’s repositories. They can be granted read, write, or admin permissions.
4. Outside collaborators: They are individuals who aren’t explicitly affiliated with your organization but have been given access to one or more of your organization’s repositories.
5. Team maintainers: They are organization members who have been given specific access to maintain team membership, repositories, and settings.

Remember, teams are a flexible way to manage projects and could reflect the company’s structure, cross-functional teams, or even breakout groups for events. Teams can have different levels of access to different repositories. This way, you can ensure members have appropriate access needed for the projects they’re working on.

Domain 7: Benefits of the GitHub Community

Q. Describe open source

→ Open source refers to a type of software whose source code is publicly accessible. Here are some key aspects:

• Modifiability and Sharing: Open source software is designed to be modified and shared because its design is publicly accessible. This means that anyone can inspect, modify, and enhance the source code.
• Collaborative Participation: Open source software is developed in a decentralized and collaborative way, relying on peer review and community production. This promotes principles of open exchange, collaborative participation, rapid prototyping, transparency, meritocracy, and community-oriented development.
• Licenses: Open source software is released under an open source license, which affects the way people can use, study, modify, and distribute the software. In general, open source licenses grant computer users permission to use open source software for any purpose they wish.
• Contrast with Proprietary Software: Unlike proprietary or closed source software, where only the original authors can legally copy, inspect, and alter the software, open source software allows anyone to view or modify the source code. Examples of open source software include LibreOffice and the GNU Image Manipulation Program, while examples of proprietary software include Microsoft Office and Adobe Photoshop.
• Benefits: Open source software is often cheaper, more flexible, and has more longevity than its proprietary peers because it is developed by communities rather than a single author or company. It also promotes innovation and transparency.

In summary, open source is not just a type of software, but also a philosophy and a way of working that reaches beyond software production.

Q. Describe GitHub Sponsors

→ GitHub Sponsors is a program that allows the developer community to financially support the people and organizations who design, build, and maintain the open source projects they depend on, directly on GitHub. Here are some key features:

• Invest in Open Source: GitHub Sponsors allows you to invest in the open source projects you depend on and make open source careers possible by sponsoring open source contributors and their projects.
• Support Developers: You can make payments through GitHub to a developer or organization who designs, creates, or maintains open source projects you depend on.
• Global Availability: GitHub Sponsors is available in 103 regions. Anyone can sponsor, but you must reside in a supported region to receive funds.
• Tax Information: Sponsored developers and organizations must submit tax information to GitHub and are responsible for evaluating and paying their own taxes.
• Partnerships: GitHub works with companies across the world to make working on open source more sustainable.

In summary, GitHub Sponsors is a new way to contribute to open source: financially supporting the people who build and maintain it.

Q. Describe how GitHub advances open source projects

→ GitHub plays a crucial role in advancing open source projects in several ways:

1. Collaborative Platform: GitHub provides a platform where developers from around the world can collaborate on open source projects. It allows developers to work together, review each other’s code, and build upon each other’s work.
2. Version Control: GitHub uses Git for version control, which helps manage changes to projects without overwriting any part of the project. This makes it easier for multiple people to work on the same project at the same time.
3. Issue Tracking: GitHub has an issue tracking feature that allows bugs to be logged and tracked, feature requests to be made, and tasks to be organized. This helps maintainers manage their work and contributors find ways to participate.
4. Pull Requests: GitHub’s pull request feature allows contributors to propose changes to a project. These changes can be reviewed and discussed before being merged into the project.
5. GitHub Sponsors: This program allows the community to financially support the people and organizations who design, build, and maintain the open source projects they depend on.
6. Documentation: GitHub allows for easy documentation alongside the code, which helps maintainers explain how to use the project, and contributors understand how to contribute.
7. Community Building: GitHub provides features like discussions, wikis, and social coding events to help build and foster communities around projects.
8. Learning and Contributing: GitHub provides guides and collections to help new contributors find projects that need help and start making impactful contributions.

In summary, GitHub provides the tools and features that enable collaboration, contribution, and community building, all of which are essential for the advancement of open source projects.

Q. Identify how to follow people (receive notifications, discover projects in their community)

→ GitHub plays a crucial role in advancing open source projects in several ways:

1. Collaborative Platform: GitHub provides a platform where developers from around the world can collaborate on open source projects. It allows developers to work together, review each other’s code, and build upon each other’s work.
2. Version Control: GitHub uses Git for version control, which helps manage changes to projects without overwriting any part of the project. This makes it easier for multiple people to work on the same project at the same time.
3. Issue Tracking: GitHub has an issue tracking feature that allows bugs to be logged and tracked, feature requests to be made, and tasks to be organized. This helps maintainers manage their work and contributors find ways to participate.
4. Pull Requests: GitHub’s pull request feature allows contributors to propose changes to a project. These changes can be reviewed and discussed before being merged into the project.
5. GitHub Sponsors: This program allows the community to financially support the people and organizations who design, build, and maintain the open source projects they depend on.
6. Documentation: GitHub allows for easy documentation alongside the code, which helps maintainers explain how to use the project, and contributors understand how to contribute.
7. Community Building: GitHub provides features like discussions, wikis, and social coding events to help build and foster communities around projects.
8. Learning and Contributing: GitHub provides guides and collections to help new contributors find projects that need help and start making impactful contributions.

In summary, GitHub provides the tools and features that enable collaboration, contribution, and community building, all of which are essential for the advancement of open source projects.

Q. Explain how to follow organizations (receive notifications about their activity)

→ Here’s how you can follow organizations on GitHub to receive notifications about their activity:

1. Go to the organization page you want to follow.
2. In the top-right corner, click Follow.

Once you follow an organization, you’ll see their public activity on your personal dashboard. This activity includes new discussions, sponsorships, and repositories.

If you want to unfollow an organization, you can do so by going to the organization page you want to unfollow and clicking Unfollow in the top-right corner.

Please note that the ability to follow organizations is currently in public beta and subject to change.

Q. Describe the GitHub Marketplace and its purpose

→ GitHub Marketplace is a platform where you can discover and purchase tools that extend your workflow. It connects developers to tools that can enhance and improve their GitHub workflows. Here are some key features:

• Discover and Purchase Tools: You can find apps to use across your development process, from continuous integration to project management and code review. You can start using these tools without setting up multiple accounts or payment methods.
• List Your Apps: If you’ve developed an app, you can list it on the GitHub Marketplace, making it available to all GitHub users. You can list both free and paid tools.
• Two Types of Tools: GitHub Marketplace offers developers two types of tools: GitHub Actions and Apps. Each tool requires different steps for adding it to the GitHub Marketplace.
• Publishing an App: When you have finished creating your app, you can share it with other users by publishing it to GitHub Marketplace.

In summary, GitHub Marketplace is a platform that allows developers to extend their GitHub workflows by discovering, purchasing, and using various tools.

Q. Describe InnerSource

→ InnerSource is a software development strategy where companies adopt an open source approach and culture to collaborate more effectively. Here are some key aspects:

• Open Source Practices: InnerSource applies open source practices to proprietary code within an organization. This means that even though the software is not open to the public, the development methodologies of open source, such as transparency, collaboration, and community, are utilized.
• Collaboration and Efficiency: By adopting InnerSource, teams within an organization can work and collaborate more effectively. It helps to increase visibility, strengthen collaboration, and break down silos.
• Reuse and Innovation: InnerSource enables the reuse of existing solutions and minimizes redundancy. It empowers team collaboration and leverages talent across the workforce. This can lead to more innovative and efficient solutions.
• Learning from Open Source: Organizations can continuously incorporate modern software development practices by learning from large-scale open source projects.

In summary, InnerSource is about taking the lessons learned from developing open source software and applying them to the way companies develop software internally.

Q. Identify the differences between InnerSource and open source

→ InnerSource and open source both leverage the principles of transparency, collaboration, and community to develop software. However, they differ in their scope and application:

Open Source:

• Open source software is publicly available and can be used, modified, and distributed by anyone.
• It is developed by a community of contributors from around the world.
• Open source projects are licensed under open source licenses that support free distribution of the source code.
• Open source promotes collaborative development, where developers from different backgrounds and organizations work together.

InnerSource:

• InnerSource applies the principles of open source to proprietary code within an organization.
• The “openness” of the project extends across many teams within the organization.
• InnerSource remains within the view and control of a single organization.
• It encourages open sharing for systems, software modules, templates, and sample code that fulfills best practice guidelines.
• InnerSource promotes the practice of transparency in the Government.

In summary, while open source is about public collaboration and sharing, InnerSource is about applying these principles within the boundaries of an organization.

Q. Describe forking

→ Forking in GitHub is a process that allows you to create a personal copy of another user’s repository. Here are some key aspects:

• Creating a New Repository: When you fork a repository, a new repository is created under your GitHub account. This new repository shares the code and visibility settings with the original repository.
• Proposing Changes: Forks are often used to propose changes to the original repository. You can make changes to your forked repository and then submit a pull request to the original repository, asking the owner to merge your changes.
• Iterating on Ideas: Forking allows you to iterate on ideas or changes before they are proposed back to the original repository. This is particularly useful in open source projects or when a user does not have write access to the original repository.
• Starting Point for Your Own Idea: You can also use someone else’s project as a starting point for your own idea.
• Forking Process: To fork a repository, you simply navigate to the repository you want to fork and click the Fork button. The newly forked repository gets created under your GitHub account.

In summary, forking is a fundamental aspect of collaboration on GitHub, allowing users to make changes to projects and contribute to their development.

Q. Describe the components of a discoverable repository

→ A discoverable repository in GitHub typically includes several key components:

1. Descriptive Name: The repository name should be descriptive and give an idea of what the project is about.
2. Clear README: A README file provides essential information about the project, including its purpose, how to set it up, how to use it, and how to contribute.
3. License: A license file (LICENSE or LICENSE.md) specifies the terms under which others can use, copy, or modify your project.
4. Contribution Guidelines: A CONTRIBUTING file provides guidelines for how others can contribute to the project.
5. Code of Conduct: A CODE_OF_CONDUCT file sets expectations for contributors to the project and outlines the consequences for unacceptable behavior.
6. Issue and Pull Request Templates: These templates help contributors provide the necessary information when reporting bugs or proposing changes.
7. Topics: Topics are labels that you can add to your repository to make it more discoverable They can include the repository’s intended purpose, subject area, community, or language.
8. Insights: The Insights tab provides a wealth of information about the repository, including a dependency graph that shows the packages your project depends on.

Remember, the goal of making a repository discoverable is to make it easy for others to understand what your project is about, how they can use it, and how they can contribute.

Q. Describe when to use issue templates

→ Issue templates in GitHub are used to standardize and streamline the process of reporting bugs or proposing enhancements. Here are some scenarios when they are particularly useful:

1. Standardizing Issue Reports: If you’re maintaining a project with many contributors, issue templates help ensure that all necessary information is provided when an issue is opened.
2. Guiding Contributors: Issue templates can guide contributors to frame their issues or feature requests in a way that’s most helpful for the maintainers.
3. Improving Efficiency: By providing a structure for issues, templates can save time for both contributors and maintainers, making the process more efficient.
4. Encouraging Useful Issues: Templates can encourage contributors to open actionable issues by prompting them to provide specific, structured information.

In summary, issue templates are a valuable tool for managing a project’s issues effectively and efficiently.

Q. Describe when to use pull request templates

→ Pull request templates in GitHub are used to standardize and streamline the process of proposing changes to a project. Here are some scenarios when they are particularly useful:

1. Standardizing Pull Requests: If you’re maintaining a project with many contributors, pull request templates help ensure that all necessary information is provided when a pull request is opened.
2. Guiding Contributors: Pull request templates can guide contributors to frame their proposed changes in a way that’s most helpful for the maintainers.
3. Improving Efficiency: By providing a structure for pull requests, templates can save time for both contributors and maintainers, making the process more efficient.
4. Encouraging Useful Pull Requests: Templates can encourage contributors to open actionable pull requests by prompting them to provide specific, structured information.

In summary, pull request templates are a valuable tool for managing a project’s pull requests effectively and efficiently.

APPENDIX

1. (5) How to use GitHub Desktop: The easy tutorial(Part1) — YouTube
2. Learn more at docs.github.com
3. Learn more at stackoverflow.com
4. Learn more at freecodecamp.org
5. Learn more at reflectoring.io
6. Learn more at pluralsight.com
7. Learn more at github.com