GitHub Foundations key terms

A free, open-source distributed version control system that records snapshots of a project's files over time so you can review, compare, and undo changes.

A cloud platform that hosts Git repositories and adds collaboration and automation features such as pull requests, issues, code review, Actions, and access control.

A project's home on GitHub containing its files, the complete history of every commit, and settings; it also gathers issues, pull requests, and other collaboration data.

A saved snapshot of the changes you staged, stored with a message, author, timestamp, and unique hash, and linked to the commit that came before it.

A lightweight movable pointer to a line of commits that lets you work on a feature or fix separately and later combine it with other work.

A named bookmark for another copy of a repository, usually hosted on GitHub, that you fetch from to get others' work and push to share your own.

Copying a remote repository, including its branches and complete history, onto your own computer so you can work locally and synchronize later.

The holding area, also called the index, where you place specific changes so that the next commit records exactly those changes and nothing else.

A state Git reports when two branches change the same lines of a file, or one deletes a file the other edits, so a person must choose the final content.

The long hexadecimal hash Git computes for each commit from its content and metadata; it uniquely identifies that snapshot anywhere in the repository.

A named reference pointing at one specific commit, conventionally used to mark release points such as v1.4.0 so they are easy to find later.

A GitHub page that bundles a Git tag with written release notes and optional downloadable files such as compiled binaries or source archives.

A markdown file, usually named README.md, displayed automatically on the repository's main page to explain what the project is and how to use it.

A setting controlling who can see a repository: public repositories are visible to everyone, while private ones are visible only to the owner and invited collaborators.

A repository marked as a template so that others can generate new repositories starting with the same files, folders, and settings.

A text file, usually at the repository root, listing patterns for files Git should skip, such as build output, dependency folders, and local environment files.

A personal copy of another person's repository created under your own account, which lets you propose changes without having write access to the original.

A request to merge changes from one branch into another that shows the diff, hosts review comments, and runs automated checks before merging.

The process where collaborators read a pull request's changes and leave line comments, suggestions, or an approval or change request before it merges.

A pull request opened in draft state that is clearly marked as not ready for review and cannot be merged until its author marks it ready.

A configuration file that maps file paths to users or teams so GitHub automatically requests their review when a pull request touches those paths.

A repository setting that enforces conditions on a branch, such as required approvals, passing status checks, or a linear history before merges are allowed.

A forum-style conversation area in a repository for open-ended questions, ideas, and announcements that are not tied to a specific issue or pull request.

GitHub's automation service that runs workflows triggered by repository events such as pushes, pull requests, schedules, or manual starts.

A YAML file stored under .github/workflows that defines when automation runs, which jobs it runs, and the steps each job performs.

The machine that executes a workflow's jobs; it can be hosted by GitHub or self-hosted on infrastructure that you manage yourself.

A practice where every push is automatically built and tested so integration problems and regressions are detected quickly instead of at release time.

An encrypted value stored in repository, organization, or environment settings and passed to workflows at run time without being printed in logs.

A GitHub feature that monitors a project's dependencies and opens pull requests to upgrade outdated packages or fix known security vulnerabilities.

Automated analysis, often run with GitHub's CodeQL engine, that inspects code for security weaknesses and coding errors and raises alerts in the repository.

A hosting service that publishes static files straight from a repository as a website, commonly used for project documentation, blogs, and portfolios.

A trackable item in a repository used to report bugs, request features, or record tasks, with a title, description, comments, labels, and an open or closed state.

A colored, named tag attached to issues and pull requests to group them by type, priority, or status, such as bug, enhancement, or help wanted.

A collection of issues and pull requests with an optional due date that measures progress toward a shared goal such as an upcoming release.

The specific person accountable for moving an issue or pull request forward, shown in the item's sidebar and usable as a filter.

GitHub's planning tool that collects issues and pull requests into customizable boards, tables, or roadmaps with fields, saved views, and built-in automation.

A checklist written inside an issue or pull request body with checkbox syntax, letting contributors tick off sub-tasks as they are completed.

A prewritten form or markdown file stored in the repository that prompts people to supply the details needed when they open a new issue.