GitHub Foundations cheat sheet

Git is a distributed version control system: every clone holds the complete commit history, so log, diff, and commit work offline without a server.

GitHub is a hosting and collaboration platform built on Git; it adds pull requests, issues, Actions, Projects, and access control on top of the Git protocol.

Files pass through three states: working directory (modified), staging area or index (staged), and local repository (committed).

Core local commands: git init creates a repository, git add stages changes, git commit records a snapshot, git status reports the state of each file.

Synchronization commands: git clone copies a remote repository, git fetch downloads commits without merging, git pull fetches then integrates, git push uploads local commits.

git diff shows unstaged changes, git diff --staged shows what is staged for the next commit, and git log lists commit history.

A branch is a movable pointer to a commit, so creating or switching branches is cheap; HEAD identifies the commit checked out on the current branch.

Each commit is addressed by a hash (SHA-1 by default) and is immutable; rewriting history requires a force push that other clones must reconcile.

Visibility options: public repositories are readable by anyone, private repositories are limited to the owner plus explicitly granted collaborators, and internal repositories are limited to enterprise members.

Key root files: README.md renders on the repository home page, LICENSE states legal terms, and .gitignore lists path patterns Git should not track.

A new repository can be initialized with a README, a .gitignore template, and a license, or an existing local project can be published with git remote add origin followed by git push -u origin main.

Forking creates a copy of another account's repository under your account; the original is tracked as the upstream remote for syncing changes.

The default branch is the branch cloned and displayed first; it is changed in repository settings and renaming it requires updating local remotes and open pull requests.

The .github directory holds workflows, issue and pull request templates, and community health files consumed by GitHub features.

Releases are built on Git tags and can include release notes and binary assets; the most recent non-prerelease is labeled Latest.

GitHub Pages publishes static sites from a branch, a /docs folder, or an Actions deployment; repository topics improve discoverability in search.

HTTPS remotes authenticate with a personal access token or credential manager, while SSH remotes authenticate with a key pair; account passwords are not accepted for Git operations over HTTPS.

A pull request proposes merging commits from a head branch into a base branch and carries review comments, status checks, and merge controls.

Merge methods are configurable per repository: merge commit preserves all commits plus a merge commit, squash merge produces one commit, rebase merge replays commits without a merge commit.

A draft pull request cannot be merged until its author marks it ready for review.

Review states are Comment, Approve, and Request changes; when required reviews are enforced, a request-changes review blocks merging.

Repository roles in increasing capability: read, triage, write, maintain, admin; triage can manage issues and pull requests without pushing code.

A CODEOWNERS file maps path patterns to users or teams, automatically requesting review from those owners on pull requests touching those paths.

Branch protection rules and rulesets can require approving reviews, passing status checks, signed commits, linear history, and can block force pushes.

Writing closes, fixes, or resolves followed by an issue number in a pull request links and automatically closes that issue on merge to the default branch.

@mentions notify individual users or teams, and GitHub Discussions provides threaded conversations separate from actionable issues.

A GitHub Actions workflow is a YAML file in .github/workflows with on triggers, jobs, and steps that use either reusable actions (uses) or shell commands (run).

Common triggers include push, pull_request, schedule with cron syntax, and workflow_dispatch for manual runs.

Jobs run on GitHub-hosted runners (ubuntu, windows, macos) or self-hosted runners; jobs run in parallel unless a needs key declares dependencies, and steps inside a job share the workspace.

Secrets are encrypted values scoped to a repository, organization, or environment, referenced through expressions and masked in logs.

Environments attach protection rules such as required reviewers and wait timers to deployment jobs and hold environment-scoped secrets.

Dependabot version updates are configured in .github/dependabot.yml and open pull requests; security alerts and security updates respond to advisory database matches.

Code scanning with CodeQL and secret scanning report findings as alerts that can be required to pass as pull request checks.

GitHub Codespaces provides cloud development environments defined by a devcontainer configuration, and github.dev opens a browser editor for a repository.

GitHub Packages and the container registry host npm, Maven, NuGet, and Docker artifacts with permissions inherited from the associated repository.

GitHub Projects collects issues and pull requests from one or more repositories, and the same items appear across Table, Board, and Roadmap layouts.

Projects support custom fields of type text, number, date, single select, and iteration; views can filter, sort, and group items by those fields.

Built-in project workflows automate transitions, for example setting status to Done when an item is closed or a pull request is merged.

Milestones group issues and pull requests under one due date and display a percentage-complete bar for release or sprint tracking.

Labels are colored tags used to categorize issues and pull requests by type, priority, or status and can be combined in search filters.

Task list checkboxes in an issue or pull request body track subtasks and display a completed-versus-total counter.

An issue supports up to 10 assignees, one milestone, and multiple labels; sub-issues and issue types express hierarchy.

Project (classic) is the legacy kanban board; the current Projects experience adds tables, custom fields, and cross-repository items.