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.
- Github Glossary
- Github Docs
- GitHub Foundations Learning Path
- GitHub Foundations Certification – Exam Prep Guide
- Introduction to Git and GitHub
- Working with GitHub Repositories
- Collaboration Features
- Modern Development
- Project Management
- Privacy, Security, and Administration
- Benefits of the GitHub Community
This exam is targeted towards GitHub users who want to validate their understanding of the foundational topics, products, and concepts of collaborating, contributing, and working on GitHub.
To increase your chances of success, the recommended learning paths for this exam provide you with an in-depth study of the learning content, followed by hands-on exercises and preparation assessment questions.
- Describe version control
- A version control system (VCS) is a program or set of programs that tracks changes to a collection of files.
- Define distributed version control
- Is a form of version control in which the project's complete history is stored both on the client and on the server.
- Describe Git
- Git is a distributed version control system that tracks changes in any set of computer files.
- Describe GitHub
- is a cloud-based platform that uses Git, a distributed version control system, at its core.
- a web-based hosting service for Git repositories.
- Explain the difference between Git and GitHub
- The difference is the type of the technology; GitHub is a platform and Git is a technology;
- Describe a GitHub repository
- a storage location where all your project files and their version history are kept
- The directory, located at the top level of a working tree, where Git keeps all the history and metadata for a project.
- Describe a commit
- When used as an object, commit means a change to one or more files on a branch - a snapshot of the changes you've made to your files in the repository at a specific point in time
- When used as a verb, commit means to make a commit object
- Describe branching
- A branch is a named series of linked commits, a safe place to experiment with new features or fixes.
- Branching is the practice of creating branches
- Define a remote in Git terminology
- A remote is a named reference to another Git repository
- Describe the GitHub flow
- GitHub flow is a lightweight, branch-based workflow; a set of actions that must be executed in the following order: create a branch > make changes > create a pull request > address review comments > merge your pull request > delete your branch
- What is version control?
- What is GitHub?
- Git Website
- Github Flow
- Components of the GitHub flow
- The purpose and importance of version control
- About commits
- Describe the different GitHub accounts (personal, organization, enterprise)
- Personal: is your identity on GitHub.com and has a username and profile. It can own an unlimited number of public and private repositories, with an unlimited number of collaborators on those repositories
- Organization: shared accounts where an unlimited number of people can collaborate across many projects at once, but only organization owners and security managers can manage the settings
- Enterprise: shared accounts for enterprise members to collaborate across many projects at once, and owners can invite existing organizations to join in their enterprise account, transfer organizations between enterprise accounts, or create new organizations.
- Describe GitHub’s products for personal accounts (free, pro)
- Github Free: unlimited public and private repositories and unlimited collaborators. Features: GitHub Community Support; 500 MB GitHub Packages storage; 20 GitHub Codespaces core hours per month; 2,000 Github Actions minutes per month.
- Github Pro: includes all of the features of a GitHub Free account plus more Github Actions minutes, more codespace hours, more Github Packages storage, GitHub support, and advanced tools and insight within their personal repositories.
- Describe GitHub’s products for organization accounts (free for organizations, teams)
- GitHub Free for organizations: unlimited public repositories with a full feature set or unlimited private repositories with a limited feature set. It has all the features available with GitHub Free for personal accounts, plus Team access controls for managing groups.
- GitHub Team: is the version of GitHub Pro for organizations. It provides increased GitHub Actions minutes and extra GitHub Packages storage.
- Describe the different deployment options for GitHub Enterprise
- GitHub Enterprise Server: a self-hosted solution that allows organizations to have full control over their infrastructure.
- GitHub Enterprise Cloud: infrastructure managed by Github. Includes a dramatic increase in both GitHub Actions minutes and GitHub Packages storage
- Describe the features in the user profile (metadata, achievements, profile readme, repositories, pinned repositories, stars, etc.)
- Profile readme: a place to share information about yourself with the community on GitHub.com; GitHub will display it if you have a public repository with your username and a README.md file with any content;
- Repositories: It's a place where you can store your code, your files, and each file's revision history. Can be public or private.
- Pinned repositories: up to 6 public repository that you own or contributed last year; Once you pin items to your profile, the "Pinned" section replaces the "Popular repositories" section on your profile.
- Badges: When you participate in certain programs, GitHub automatically displays a badge on your profile.
- Achievements: appear as small badges listed in the sidebar of your profile that celebrates specific events and actions
- Stars: Starring makes it easy to find a repository or topic again later, makes Github recommend similar repositories, and raises the project in Github's repository rankings.
- GitHub accounts and plans
- Types of GitHub accounts
- Customizing your profile
- Saving repositories with stars
- Viewing contributions on your profile / Pinned
- About repositories
- Identify the text formatting toolbar on issue and pull request comments
- Every comment field on GitHub contains a text formatting toolbar, which allows you to format your text without learning Markdown syntax.
- Describe Markdown
- Markdown is a markup language that offers a lean approach to content editing with a concise, lightweight syntax that strips out the overhead inherent to HTML, providing a more approachable creation experience.
- Identify the basic formatting syntax (headings, links, task lists, comments, etc.)
- Headings:
- Italics: surround the target text with single asterisks (*) or single underscores (_)
- Bold: surround the target text with two asterisks (**) or two underscores (__).
- Literal asterisk: precede it with an escape character (\)
- Headings: use one # for each heading level from 1-6. Ex: ###### This is H6 text
- Images and Links:
- Lists: ordered lists start with numbers Unordered lists can use asterisks ( /* ) or dashes ( - ); add whitespaces to nest them.
- Tables: construct tables using a combination of pipes (|) for column breaks and dashes (-) to designate the prior row as a header.
- Quotes: create blockquotes using the greater than (>)
- Inline code blocks: delimite it with the backtick (`) character. Ex: This is `code`.
- Multiple lines code blocks: use three backticks (```) before and after to create a fenced code block; Add support to syntax highlighting for popular languages by specifying the language name as part of the first tick sequence.
- Issues and Pull requests: use the format #ID, such as #3602. There are also additional conventions you can follow.
- Specific commits: You can link to a commit by either pasting in its ID or simply using its secure hash algorithm (SHA).
- Mention users and teams: Typing an @ symbol followed by a GitHub username or team
- Task lists: using the syntax - [x] or - [ ]
- Explain where to find and use slash commands
- Use slash commands to insert a Markdown code block
- Explain the difference between GitHub Desktop and github.com
- The difference is the solution type: GitHub Desktop is an application that works with data from GitHub.com, a platform hosted on cloud.
- Describe the available features with GitHub Desktop
-
- Add and clone repositories;
- Add changes to your commit interactively;
- Quickly add co-authors to your commit;
- Check out branches with pull requests and view CI statuses; Compare changed images.
- Compare changed images.
- Describe the available features with GitHub Mobile
- Secure your GitHub.com account with two-factor authentication; Verify your sign in attempts on unrecognized devices; Search for, browse, and interact with users, repositories, issues, pull requests and organizations; Edit files in pull requests; Receive and schedule push notifications; Manage, triage, and clear notifications from github.com.
- Explain how to manage notifications through the GitHub Mobile app
- In the bottom menu, tap Profile > To view your settings, tap the gear icon > tap Configure Notifications and then use the toggles to enable or disable your preferred types of push notifications.
- You can choose also whether to watch or unwatch an individual repository. To choose what activities you receive notifications for, tap your preferred watch settings.
- GitHub Mobile and GitHub Desktop
- Configuring notifications
- Choosing your notification settings
- Managing your notification settings with GitHub Mobile
- Understanding GitHub Repositories
- It's a place where you can store your code, your files, and each file's revision history. Repositories can:
- have multiple collaborators
- be either public or private.
- have issues to report bugs and organize tasks
- have discussions to ask and answer questions
- have change proposals (pull requests)
- have Projects to organize and prioritize your issues and pull requests
- be public or private, or internal (for enterprise accounts that uses GitHub Enterprise Cloud)
- Describe the components of a good README and the recommended repository files (LICENSE, CONTRIBUTING, CODEOWNERS)
- code of conduct: defines standards for how to engage in a community.
- CONTRIBUTING: communicates how people should contribute to your project
- FUNDING: displays a sponsor button in your repository to increase the visibility of funding options for your open source project.
- GOVERNANCE: lets people know about how your project is governed.
- SECURITY: gives instructions on how to report a security vulnerability in your project.
- SUPPORT: lets people know about ways to get help with your project.
- LICENSE:
- CODEOWNERS: use a CODEOWNERS file to define ***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. To use a CODEOWNERS file, create a new file called CODEOWNERS in the .github/, root, or docs/ directory.
- Explain basic repository navigation
- In the upper-right corner of any page, select the dropdown, then click New repository.
- Explain code navigation
- Code navigation uses the open source tree-sitter library to help you to read, navigate, and understand code by showing and linking definitions of a named entity corresponding to a reference to that entity. 
- Explain how to create a new repository
- Web UI: Sign in to GitHub, go to your dashboard, and select the plus ("+") icon in the upper-right corner.
- GitHub CLI: `gh repo create`
- From a template: navigate to the main page of the repository, click Use this template, and Select Create a new repository.
- From a URL query: use query parameters to pre-fill form fields when creating a new repository - https://github.com/new?name=test-repo&owner=avocado-corp&visibility=public
- *Owners can restrict repository creation permissions in an organization
- Describe repository templates
- A way to generate new repositories with the same directory structure, branches, and files of an existing repository (*except files stored using Git LFS).
- Describe how to clone a repository
- Cloning a repository pulls down a full copy of all the repository data that GitHub.com has at that point in time:
> On GitHub.com, navigate to the main page of the repository
> Above the list of files, click Code
> Copy the URL for the repository
> Open Git Bash
> Change the current working directory to the location where you want the cloned directory.
> Type git clone, and then paste the URL you copied earlier. > Press Enter to create your local clone.
Alternatively, to clone your repository in Desktop, click "Set up in Desktop" and follow the prompts to complete the clone.
- Describe how to create a new branch
- Creating a branch via the branches overview: From the file tree view on the left, select the branch dropdown menu, then click View all branches > Click New branch.
- create a branch directly from the issue page: navigate to the issue that you would like to create a branch for > In the right sidebar under "Development", click Create a branch.
- Note: You can only create a branch in a repository to which you have push access.
- Explain how to add files to a repository
- Adding a file to a repository on GitHub: navigate to the main page of the repository > Above the list of files, select the Add file dropdown menu and click Upload files.
- Adding a file to a repository using the command line: Open Git Bash > Change the current working directory to your local repository > Stage the file for commit to your local repository > Commit the file that you've staged in your local repository > Push the changes in your local repository to GitHub.com
- Adding a file not tracked by any VCS:
> Initialize the local directory as a Git repository
> Add the files in your new local repository
> Commit the files that you've staged in your local repository.
> Add the URL for the remote repository where your local repository will be pushed (git remote add origin REMOTE-URL)
> OR use the `gh repo create` subcommand from GitHub CLI and Follow the interactive prompts - Identify how to view repository insights
- You can view an overview of a repository's activity through Pulse: On GitHub.com, navigate to the main page of the repository > Under your repository name, click Insights.
- Explain how to save a repository with stars
- Starring makes it easy to find a repository or topic again later: On GitHub.com, navigate to the main page of the repository > In the top-right corner of the page, click Star.
- Explain feature previews
- You can use feature preview to see products or features that are available in beta and to enable or disable each feature for your personal account.
- Get started with GitHub
- About Repositories
- Creating a new repository
- Creating a repository from a template
- Creating a template repository
- About READMEs
- Setting up your project for healthy contributions
- Creating a default community health file
- Adding a license to a repository
- About code owners
- Navigating code on GitHub
- Adding a file to a repository on GitHub
- Adding a file to a repository using the command line
- Viewing activity and data for your repository
- Saving repositories with stars
- Exploring early access releases with feature preview
- Issues
- Issues are for tracking ideas, feedback, tasks, or bugs for work on GitHub
- Describe how to link a PR to an issue
- You can link an issue to a pull request manually or using a supported keyword in the pull request description. When you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed:
- Manually: In the list of pull requests, click the pull request that you'd like to link to an issue > In the right sidebar, click Development > Click the issue you want to link to the pull request.
- using a supported keyword: close; closes; closed; fix; fixes; fixed; resolve; resolves; resolved. Example : Closes #10
- Describe how to create an issue
- Under your repository name, select Issues and then select New Issue
- Describe the difference between an issue, discussion, and pull request
- The difference is their purpose.
- Issues: for ideas, feedback, tasks, or bugs related to code
- Discussions: for conversations that need to be accessible to everyone and aren't related to code
- Pull request: to propose changes to the codebase.
- Explain how to create a branch from an issue
- create a branch directly from the issue page: navigate to the issue that you would like to create a branch for > In the right sidebar under "Development", click Create a branch
- Identify how to assign issues
- Open the issue or pull request that you want to assign to someone. In the right side menu, click Assignees.
- Describe how to search and filter issues
- Go to the GitHub repository where you want to search or filter issues. Click on the 'Issues' or 'Pull Requests' tabs and use the search bar with the selected filter.
- Describe how to pin an issue
- On the issues tab, click the issue to pin, then on the right sidebar click 'Pin Issue'.
- Explain basic issue management
- Creating Issues: click on the 'Issues' tab in the repository and then on 'New issue'.
- Labeling Issues: Labels are a useful way to categorize issues. Common labels include 'bug', 'feature request', and 'help wanted'. They can be customized to fit the needs of the project. Labels help in organizing and prioritizing issues.
- Assigning Issues: indicate who is responsible for working on the issue. It helps in distributing tasks among team members.
- Milestones: group issues together, often for a specific release or project phase. This helps in tracking the progress towards a particular goal.
- Issue Comments: Team members can comment on issues to discuss them in more detail.
- Closing Issues: Once an issue has been resolved, it should be closed.
- Searching and Filtering Issues: GitHub provides tools to search and filter issues. This can be done using keywords, labels, assignees, or other criteria.
- Linking Pull Requests to Issues: indicates that the code changes in the pull request address the issue.
- Explain the difference between issue templates and issue forms
- Issue Templates are markdown files that create a predefined structure for users to fill out when they open a new issue.
- Issue Forms: a more structured, more interactive and user-friendly forms alternative to issue templates using YAML configuration files.
- Explain how to use keywords in issues
- Keywords are used in pull requests and commit messages to link the pull request or commit to an issue, and optionally to close the issue when the pull request is merged:
- To link a pull request or commit: use keywords like "refers to", "addresses", or "re:", followed by the issue number. For example, "Refers to #123". - To close an issue automatically when a pull request is merged: use keywords such as "close", "closes", "closed", "fix", "fixes", "fixed", "resolve", "resolves", or "resolved";
- When creating a pull request or making a commit: include the chosen keyword followed by the issue number in the pull request description or the commit message.
- If your pull request or commit addresses several issues, you can use multiple keywords. For example: "This commit closes #123, resolves #124, and refers to #125".
- GitHub is a collaborative platform
- Linking a pull request to an issue
- Assigning issues and pull requests to other GitHub users
- Describe a pull request
- a request to merge the changes you made in a branch to another branch of the repository.
- Explain how to create a new pull request
- Web Browser:
- Desktop:
- Codespaces:
- Github CLI: use the `gh pr create` subcommand
- From Fork:
- Navigate to the original repository where you created your fork.
- Above the list of files, in the yellow banner, click Compare & pull request to create a pull request for the associated branch.
- On the page to create a new pull request, click compare across forks.
- In the "base branch" dropdown menu, select the branch of the upstream repository you'd like to merge changes into.
- In the "head fork" dropdown menu, select your fork, then use the "compare branch" drop-down menu to select the branch you made your changes in
- Type a title and description
- Note: If you want to create a new branch for your pull request and do not have write permissions to the repository, you can fork the repository first.
- Describe the `base` and `compare` branches in a pull request
- the base branch is where changes should be applied, the head branch (compare) contains what you would like to be applied.
- Explain the relationship of commits on a pull request
- commits will appear in chronological order within your pull request and the changes will be visible in the "Files changed" tab.
- Describe draft pull requests
- If you're not ready to get feedback on your pull request you can create Draft pull requests, because they cannot be merged, and code owners are not automatically requested to review it.
- Describe the purpose of the pull request tabs (conversation, commits, checks, files changed)
- Conversation: view all of the reviews a pull request has received
- Commits:
- Checks: Checks let you know if your commits meet the conditions set for the repository. view detailed build output from checks and rerun failed checks.
- Files changed:
- Identify how to link activity within a pull request
- Referencing Issues: include phrases like fixes #issue_number, closes #issue_number, or resolves #issue_number in your PR description or in a commit message.
- Mentioning Other Pull Requests or Discussions: use the # followed by the PR/discussion number
- Linking to Commits: To reference a specific commit in your discussion, use its SHA.
- Mentioning Team Members: Use @username to grab their attention.
- Using Markdown for Additional Context
- Checklist to Track Progress: In the PR description, you can include a task list using - [ ].
- Explain the different pull request statuses
- Draft: Cannot be merged and code owners ***are not*** automatically requested to review it.
- Open pull request (Ready for review): Can be merged and code owners are automatically requested to review it.
- Closed pull request: You can choose to close a pull request without merging it into the base/main branch.
- Merged pull request: means that the updates and commits from the compare branch were combined with the base branch.
- Recognize how to comment on a posted link to a line or lines of code from a file
- While reviewing a pull request, Hover over the line of code where you'd like to add a comment, and click the blue comment icon. To add a comment on multiple lines, click and drag to select the range of lines, then click the blue comment icon.
- To comment directly on a file, to the right of the file, click and type your comment.
- Describe code review with a codeowners file
- The CODEOWNERS file can be placed in the root, docs/, or .github/ directory of a repository. It specifies individuals or teams responsible for code in certain parts of the repository.
Features:
- Automatic Review Requests: GitHub automatically requests a review from the specified owners.
- Mandatory Reviews for Protected Branches: enforce that changed code is reviewed by its owners before it’s merged.
- Flexibility and Documentation: serves as a clear documentation of responsibilities
- Integration with GitHub Actions - Explain the different options for providing a code review on a pull request (comment, approve, request changes, suggested changes)
- Comment: Submit general feedback without explicitly approving the changes or requesting additional changes
- Approve: Submit feedback and approve merging the changes proposed in the pull request.
- Request changes: Submit feedback that must be addressed before the pull request can be merged.
- Suggested changes: Suggest specific changes to lines of code, which the author can apply directly from the pull request.
- Components of the GitHub flow
- The purpose and importance of version control
- About pull requests
- Creating a Pull Request
- Changing the stage of a pull request
- Reviewing proposed changes in a pull request
- About comparing branches in pull requests
- Describe the difference between discussions and issues
- The difference is what they are related to: discussions area for conversations that aren't related to code, and issues are for conversations that are related to code (bugs, tasks, etc.)
- Explain the options available with discussions (announcements, ideas, polls, Q&A, show and tell)
- Announcements: Updates and news from project maintainers
- General: Anything and everything relevant to the project
- Ideas: ideas to change or improve the project
- Polls: polls with multiple options for the community to vote for and discuss
- Q&A: Questions for the community to answer, with a question/answer format
- Show and tell: Creations, experiments, or tests relevant to the project
- Identify how to mark a comment as an answer to a discussion
- >Under your repository or organization name, click Discussions
> In the discussion, find the comment you want to mark as the answer
> Below the comment, click Mark as answer. - Explain how to convert a discussion to an issue
- click the discussion you want to view > In the right sidebar, click Create issue from discussion
- Recognize how to pin a discussion
- In the list of discussions, click the discussion you want to view > In the right sidebar, click Pin discussion.
- GitHub is a collaborative platform
- Moderating discussions
- Creating an issue from discussion
- Pinning a discussion
- Describe how to manage notification subscriptions
- Explain how to subscribe to notification threads
- Identify the notification filtering options
- Explain the different notification configuration options
- Explain Gists
- Gists provide a simple way to share code snippets with others. Every gist is a Git repository, which means that it can be forked and cloned.
- Explain how to create a GitHub gist
- Navigate to the *[gist.github.com page](gist.github.com) page > Click Create secret Gist or Create public gist.
- Describe how to fork and clone a gist
- To fork a gist, acess the gist page and click on "Fork this gist".
- To clone a gist, select the Embed dropdown menu on your gist page, then click Clone via HTTPS or Clone via SSH.
- Explain GitHub Wiki pages
- Every repository on GitHub.com comes equipped with a section for hosting documentation, called a wiki. You can use your repository's wiki to share long-form content about your project.
- Describe how to create, edit, and delete wiki pages
- On GitHub.com: navigate to the main page of the repository > Under your repository name, click Wiki. > In the upper-right corner of the page, click New Page.
- Locally: Wikis are part of Git repositories, so you can make changes locally and push them to your repository using a Git workflow. `$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.wiki.git`
- Explain the visibility of wiki pages
- 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. dd>
- Note: 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.
- 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.
Describe how to find threads where you are at-mentioned
- Describe GitHub Actions (basic understanding)
- Explain where you can use GitHub Actions within GitHub (general event types)
- GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline.
- Explain where you can find existing GitHub Actions
- Describe GitHub Copilot
- GitHub Copilot is a service that provides you with an AI pair programmer tool that draws context from comments and code to suggest individual lines and whole functions instantly.
Some features:
- suggest individual lines and whole functions;
- in-depth analysis and explanations of what code blocks are intended to do;
- generate unit tests;
- get proposed fixes to bugs;
- Describe the difference between GitHub Copilot for Individuals and GitHub Copilot for Business
- The differences are the cost, the type of account that can use it, and the features available. Enterprise has all business features, plus Copilot Chat in Github and Pull Request summaries. Business has all individual features plus audit logs, exclude specified files and Organization-wide policy management.
- Explain how to get started using GitHub Copilot
- First, set up a free trial or subscription for your personal account on Code, planning, and automation menu. Then, install an extension for your preferred environment.
- Note: Network restrictions, firewalls, or your proxy may cause issues when connecting to GitHub Copilot.
- Describe GitHub Codespaces
- GitHub Codespaces is an instant, cloud-based development environment that uses a container to provide you with common languages, tools, and utilities for development. When you create a GitHub Codespace, four processes occur:
1. VM and storage are assigned to your Codespace.
2. A container is created.
3. A connection to the Codespace is made.
4. A post-creation setup is made.
 - Identify how do to start a GitHub codespace
- You can create a new Codespace each time you develop in GitHub Codespaces or keep a long-running Codespace for a feature. There are four ways to create a Codespace:
- From a GitHub template or any template repository
- From a branch in your repository for new feature work
- From an open pull request to explore work-in-progress
- From a commit in a repository's history to investigate a bug at a specific point in time
*Important: there are limits to the number of Codespaces you can create and run at the same time. - Describe the codespace lifecycle
- With lifecycle you can have a repeatable Codespace configuration for all users of your project. The Codespace's lifecycle starts when we click on create: Creating a Code Space > Rebuilding a Codespace > Stopping a Codespace (manually or automatically due to inactivity) > Deleting a Codespace
- Describe the different customizations you can personalize with GitHub Codespaces
- There are many ways you can customize your Codespace:
- Settings Sync: You can synchronize your Visual Studio Code (VS Code) settings;
- Dotfiles: You can use a dotfiles repository to specify scripts, shell preferences, and other configurations.
- Rename a Codespace: You can change the autogenerated display name;
- Change your shell: You can change your shell in a Codespace to keep the setup you're used to;
- Change the machine type: You can change the type of machine that's running your Codespace;
- Configure automatic deletion: You can choose how long your stopped Codespaces are retained. - Recognize how to add and configure dev containers
- Identify how to share a deep link to a GitHub codespace
- Explain how to use the github.dev editor
- Explain the differences between the github.dev editor and a GitHub Codespace
- The differences are the costs, resources and features available. GitHub.dev doesn't have compute in it, while with GitHub Codespaces, you get the power of a personal Virtual Machine (VM) with terminal access. Github.
- Describe GitHub Projects
- Projects is an adaptable, flexible tool for planning and tracking work on GitHub.
- Explain the layout options for projects
- Table: adaptable spreadsheet comprised of your issues, pull requests, and draft issues with metadata from GitHub and the custom fields you've added to your project
- Board: spreads your issues, pull requests, and draft issues across customizable columns
- Roadmap: a high-level visualization of your project across a configurable timespan, and allows you to drag items to affect their start and target dates or selected iteration
- Describe the configuration options for projects
- Custom fields:
- Group view:
- Timelines:
- Iterations: An iteration field enables you to set up phases for your tasks in a tangible timeframe.
- Layout options:
- Visibility and access: control whether or not your Project is public or private
- Close and delete: Closing a Project enables you to remove it from the list of Projects but retain the content and ability to re-open it; Deleting a Project, however, permanently removes your Project from the platform along with his data;
- Explain the difference between projects and projects classic
- The main difference is the number of features available. The new GitHub Projects provide a richer experience with more automation options, insights, data, and layouts.
- Explain the use of labels
- Used to classify and categorize issues, pull requests, and discussions. GitHub provides manageable default labels in every new repository, but you can create new ones.
- Explain the use of milestones
- You can use milestones to track progress on groups of issues or pull requests in a repository by associating issues and pull requests to them. From the milestone page you can see his metadata and the number and list of the open and closed issues and pull requests associated.
- Describe how to use and create template repos
- 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.
- Explain how to create, edit, and delete saved replies
- Create: click your profile photo, then click Settings. In the "Code, planning, and automation" section of the sidebar, click Saved replies. Add title and content and save it.
- Edit: Under "Saved replies," next to the saved reply you want to edit, click on the pencil icon. Then, edit the title or content and click on update.
- Delete: Under "Saved replies", click on the X icon next to the saved reply you want to delete,.
- Describe the benefits of using a saved reply
- Saved replies allow you to Save time by creating a saved reply for the responses you use most frequently.
- Recognize how to add assignees to issues and pull requests
- Adding an existing issue and pull request: copy the url of an existing issue or pull request and paste it in the bottom row of the Project, right next the + icon.
- Searching for an existing issue and pull request: Enter #, Select the repository where the pull request or issue is located and then Select the issue or pull request.
- Bulk adding issues and pull request: in the bottom row of the Project, click +, and Next, click Add item from repository. Then, select all or select the ones you want to include.
- Automatically adding issues and pull requests: You can configure a built-in workflow to automatically add issues and pull requests from a repository when they meet specific filter criteria
- Assigning a project from within an issue or pull request: Navigate to the issue or pull request that you want to add to a project. In the side bar, click Projects and Select the project that you want to add.
- Explain how to use project workflows
- Projects includes built-in workflows that you can use to update the Status of items based on certain events. Navigate to your project, select Workflows in the menu and edit the workflow that you want. *The auto-add workflow is limited per plan.
- Describe project insights
- nsights with Projects enables you to view, create and customize current charts and historical charts that use items added to your Project as source data.
- About Projects
- Manage your work with GitHub Projects
- Insight and automation with projects
- Changing the layout of a view
- Automating your project
- Using labels and milestones to track work
- About saved replies
- Creating a template repository
- Explain how to secure your account with 2FA
- With 2FA, you have to log in with your username and password and provide another form of authentication that only you know or have access to. You can configure two-factor authentication (2FA) using a TOTP app on mobile or desktop or via text message:
> In the upper-right corner of any page, click your profile photo, then click Settings.
> In the "Access" section of the sidebar, click Password and authentication
> In the "Two-factor authentication" section of the page, click Enable two-factor authentication and follow the instructions; - Describe the different access permissions
- permission is the ability to perform a specific action. A role is a set of permissions you can assign to individuals or teams.
- Personal accounts: has two permission levels: the repository owner and collaborators; - Organization accounts: can have owner, billing manager, or member roles; - Enterprise account: can have enterprise owner, billing manager, enterprise member and guest collaborator (currently in public beta) - Explain EMUs (Enterprise Managed Users)
- With Enterprise Managed Users, you manage the lifecycle and authentication of your users on GitHub.com from an external identity management system, or IdP. On your IdP, you can give each managed user account a role.
- Securing your account with two-factor authentication (2FA)
- Configuring two-factor authentication
- Access permissions on GitHub
- Roles in an enterprise
- About Enterprise Managed Users
- Explain how to enable and disable features
- In the repositories settings you can enable and disable the following features: Wikis, Issues, Sponsorships, Discussions, Projects, and the ability to Preserve this repository via the GitHub Archive Program.
- Recognize repository permission levels
- Read: Allows users to clone the repository and pull updates. They can view issues, pull requests, wikis, and the project's settings.
- Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access.
- Write: Includes all Read permissions. Additionally, users can push changes to the repository, merge pull requests, and manage issues and pull requests.
- Maintain: Includes Write permissions. Users can manage the repository without access to sensitive or destructive actions.
- Admin: Full control over the repository.
- Identify the options for repository visibility
- Private: When you change a private repository to public, all the commits in that repository, including any commits made in the repositories it was forked into, will be visible to everyone, plus Each private fork will become a separate private repository and create its own independent network of repositories.
When you delete a private repository, all of its private forks are also deleted. - Internal: All enterprise members have read permissions to the internal repository, but internal repositories are not visible to people outside of the enterprise. If you change the visibility of an internal repository, any fork owned by an organization or personal account will remain private. When you delete the repository, the forks will continue to exist in a separate network.
- Public: Everyone has read access. If a public repository is made private, its public forks are split off into a new network. When you delete a private repository, all of its private forks are also deleted.
- Explain repository privacy setting options (branch protections, codeowners, required reviewers)
- Branch Protections: Used to protect important branches. Defines whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch.
- Describe the main features and options in the Security tab
- policies: allow you to specify how to report a security vulnerability in your project by adding a SECURITY.md file to your repository.
- Advisories: use to privately discuss, fix, and publish information about security vulnerabilities in your repository.
- Dependabot: alert you when GitHub detects that your repository is using a vulnerable dependency or malware.
- Code scanning: helps you find, triage, and fix vulnerabilities and errors in your code.
- Define repository insights
- provide a range of analytical data and visualizations about the activity and health of a repository.
- Pulse: Provides a summary of the activity in the repository over a specific period (daily, weekly, monthly).
- Contributors: Shows the number of contributions (commits) from each contributor over time.
- Community: Shows contribution activitity to Discussions, Issues, and PRs.
- Community Standards: Compares the repository to the recommended community standards.
- Traffic: Shows number of clones and visitors over time.
- Commits: Visualizes commit activity over time.
- Code frequency: Displays the frequency of additions and deletions to the codebase over time.
- Dependency Graph: Shows the repository’s dependencies and the projects that depend on it.
- Network: Timeline of the most recent commits to this repository and its network ordered by most recently pushed to.
- Forks: Who has forked the repo, either in tree or list form.
- Explain how to manage collaborators
- To Add Collaborators: Click on the "Settings" tab near the top of the repository page. Click on "Collaborators". Click on the "Add people" button.
- Remove Collaborator: To remove a collaborator, click on the “Remove” button next to their name.
- Approving Requests: If someone requests access to your repository, you will receive a notification. You can approve or deny these requests in the "Manage access" section.
- Describe open source
- Open source software is software that can be freely used, modified, and shared (in both modified and unmodified form) by anyone.
- Describe GitHub Sponsors
- allows the developer community to financially support directly on GitHub the people and organizations from a range of sponsorship tiers in one-time or monthly payments. 100% of these sponsorships go to the sponsored developer or organization.
- Describe how GitHub advances open source projects
- Discovering relevant projects
- Making open source more secure
- Identify how to follow people (receive notifications, discover projects in their community)
- Navigate to the user's profile page and under the user's profile picture, click Follow.
- Explain how to follow organizations (receive notifications about their activity)
- Go to the organization page you want to follow. In the top-right corner, click Follow.
- Describe the GitHub Marketplace and its purpose
- It connects you to developers who want to extend and improve their GitHub workflows. You can list free and paid tools (Actions and Apps) for developers to use. *only apps owned by organizations can sell their app.
- Open Source
- About GitHub Sponsors
- Following organizations
- Following people
- GitHub Marketplace Overview
- Open source’s impact on the world’s 100 million developers
- Finding ways to contribute to open source on GitHub
- Describe InnerSource
- Innersource is a development methodology where engineers build proprietary software using best practices from large-scale open source projects. It's the practice of applying open-source patterns to projects with a limited audience.
- Identify the differences between InnerSource and open source
- Innersource helps teams build software faster and work better together. As with open source, transparent collaboration mobilizes a community’s collective knowledge and skills to create better software. An innersource community, in contrast, contains the knowledge, skills, and abilities of people and tools within a single enterprise.
- Describe forking
- A fork is a new repository that shares code and visibility settings with the original “upstream” repository. It's best suited for accepting contributions from people that are unaffiliated with a project. This is the common workflow: Fork the repository > Make the fix > Submit a pull request to the project owner.
- To keep your fork synced with the upstream repository add an upstream to the original owner repository URL.
- Describe the components of a discoverable repository
- - Use a descriptive repository name
- Include a concise description
- License your repository
- Include a README.md file
- Describe when to use issue templates
- when you want to provide guidance (specific, structured information) for opening issues while allowing contributors to specify the content of their issues.
- Describe when to use pull request templates
- To receive proposed changes according to the repository's contributing guidelines. *To enable it, you must create templates on the repository's default branch.
- Explain how to manage organization settings
- The organization account settings page provides several ways to manage the account, such as billing, team membership, and repository settings: In the upper-right corner of GitHub.com, select your profile photo, then click Your organizations. Next to the organization, click Settings.
- Describe members, teams, and roles in a GitHub organization
- Members: You can invite anyone to become a member of your organization using their username or email address for GitHub.com: In the upper-right corner of GitHub.com, select your profile photo, then click Your organizations > Under your organization name, click People > Click Invite member.
- Teams: You can use teams to manage access for people in an organization, and for sending notifications. They can be visible or secret, and they can also be nested to reflect your group or company's hierarchy within your GitHub organization. *Important: Teams can only be made up of members of your organization.
- Roles: A role is a set of permissions you can assign to individuals or teams. Role levels: Repository-level, Team-level and Organization-level.
- Organization owners
- Organization members
- Organization moderators
- Billing managers
- Security managers
- GitHub App managers
- Outside collaborators
- An introduction to innersource
- Fork a repository
- How to manage a successful InnerSource program
- About issue and pull request templates
- Configuring issue templates for your repository
- Creating a pull request template for your repository
- Managing organization settings
- Inviting users to join your organization
- About teams
- Roles in an organization