Git, GitHub & GitHub Actions
by Sergey Okinchuk
GitHub FundamentalsRepositories on GitHub
GitHub Fundamentals
Topic 31

What GitHub Is

GitHub

GitHub is a hosting and collaboration layer built on top of Git. Git is the version control engine that runs entirely on your machine; GitHub stores your remote repositories on a server and wraps them in pull requests, issues, reviews, and access control — concepts Git itself has no notion of.

The distinction matters because almost everything that frustrates people about GitHub is actually Git, and almost everything that makes a team productive on GitHub is the platform, not Git. Keep the line between the two clear and you know which tool to reach for when something breaks.

Git vs the GitHub Platform

Git handles commits, branches, history, and merging, and it does all of that with no server at all. GitHub adds the server that holds a shared copy, a web UI to browse and review it, permissions that decide who can push, and the social workflow — pull requests, reviews, mentions — layered around the repository.

Your repository is not locked to GitHub. Because every clone holds the full history, you can push the same repo to GitLab, Bitbucket, or your own server tomorrow. GitHub is one remote among many, which is worth remembering before you build a process that assumes it can never be replaced.

The Account Model

Repositories are owned either by a personal account or by an organization. Organizations exist so ownership and billing belong to the company rather than one person's login, and they hold teams — named groups you grant repository access to in bulk instead of adding collaborators one at a time.

Adding individual collaborators to a personal repo works for a side project, but it does not scale: when someone leaves you have to remember every repo they touched. An organization with teams makes access a property of the group, so membership changes propagate everywhere at once.

Collaboration Primitives

Issues track bugs and tasks, pull requests propose changes, reviews gate those changes, and discussions hold longer conversation. They reference each other with lightweight syntax: #123 links to an issue or PR, and @mention pulls a person or team into the thread.

These cross-references are what keep the conversation next to the work. A PR that says Fixes #123 closes that issue on merge and leaves a permanent link in both directions, so six months later the reasoning is one click away.

Access and Authentication

GitHub disabled password authentication over HTTPS in August 2021, so daily push and pull use either an SSH key or a personal access token. SSH keys (ssh-ed25519) are the lowest-friction option once configured; tokens come in two forms — classic tokens with broad scopes, and fine-grained tokens scoped to specific repositories.

Token scope is a blast radius, not a convenience setting. A classic token with full repo scope handed to a third-party tool grants write access to every private repository you own, so the gap between what a tool needs and what the token grants is the gap an attacker exploits.

What Lives on GitHub Beyond Code

The platform extends past the repository into Actions for CI/CD, Packages for artifacts, Pages for static sites, and Releases for versioned downloads, all reachable through a REST and GraphQL API and the gh CLI. These are GitHub features, not Git features — they stop working the moment the repo lives somewhere else.

Git vs GitHub

Git — the distributed version control system you can run with zero servers. Commits, branches, merges, and full history all work offline on your own disk, with no account and no network.

GitHub — one of several hosts for a Git repository, adding the server, web UI, permissions, and the pull-request workflow. Useful to know your repo is not locked to it: the same history pushes to any other host unchanged.

Common Mistakes
  • Treating GitHub as a backup and never running git fetch, so you discover your branch has diverged only when git push is rejected.
  • Committing a secret to a public repo and force-pushing to remove it — the commit survives in forks, caches, and the event feed, so you must rotate the credential, not just rewrite history.
  • Authenticating with a password over HTTPS and getting silent failures, missing that GitHub removed password auth in August 2021 and you need a PAT or SSH key.
  • Granting a classic PAT with full repo scope to a tool that only needs read access, so one leaked token exposes write access to every private repo you own.
  • Assuming deleting a repository deletes every copy, when existing forks and clones persist independently of the original.
Best Practices
  • Issue fine-grained personal access tokens scoped to the specific repositories a tool needs, rather than classic tokens with broad scopes.
  • Enable two-factor authentication on your account, which GitHub now mandates for contributors to most code.
  • Add an ssh-ed25519 key for daily push and pull instead of pasting tokens on every operation.
  • Turn on secret scanning with push protection in repository settings to block credential commits before they land.
  • Use an organization with teams for any shared work instead of adding collaborators to a personal repo one by one.
Comparable toolsGitLab Git host with built-in CI and merge requestsBitbucket Git host with PRs and Jira integrationGitea lightweight self-hosted Git hostAzure DevOps Repos Git host inside the Azure DevOps suite

Knowledge Check

What would still work if GitHub the platform went offline but Git stayed installed?

  • Commits, branches, merges, and full history — all of Git is local; only pull requests, issues, and reviews are GitHub features
  • Nothing at all — Git reaches out to GitHub's server on every single commit, so the entire tool stalls completely without it
  • Only reading the existing history and switching between branches would still work; you could not record any new commits at all without reaching the remote
  • Pull requests and code reviews, since GitHub mirrors all of them down into the local .git directory on every clone

You committed a secret to a public repo and force-pushed to remove it. Is the secret safe?

  • No — the commit persists in forks, caches, and the event feed, so the credential must be rotated
  • Yes — a force-push overwrites the commit everywhere it ever existed, including forks and caches
  • Yes, as long as you also delete the branch it was on and run garbage collection on the remote
  • Only if the repo stayed public for more than the 24-hour window crawlers index in

Why is a classic PAT with full repo scope risky to hand to a read-only tool?

  • The token grants write access to every private repo you own, so one leak exposes all of them
  • Classic tokens expire on a fixed 30-day clock, so the read-only tool breaks without warning
  • It only ever reads, so the broad scope sits unused and carries no real risk
  • Full repo scope silently disables two-factor authentication on the whole account

Why does never running git fetch cause a surprise at push time?

  • Your local view of the remote goes stale, so you only learn your branch diverged when the push is rejected
  • GitHub automatically deletes any remote branch that has not been fetched by anyone at all within the last seven days
  • A push requires a short-lived fetch token that quietly expires exactly one hour after your last fetch
  • Without a recent fetch, none of your local commits are ever actually written down to disk

You got correct