Tech & AI, Explained

github

9 min read

GitHub

Status: 🟩 COMPLETE (🟦 LIVING — GitHub ships changes weekly) Last updated: 2026-06-20 Plain-English tagline: Git hosting plus a suite of collaboration tools on top. Where Git lives on the internet for most of the world.

In plain English

Git is the tool that tracks code history. GitHub is the website that hosts Git repositories online, plus an enormous suite of tools layered on top: pull requests, issues, code review, project boards, CI/CD (GitHub Actions), discussions, releases, sponsorships, and more.

GitHub is to Git what Vercel is to Next.js. Git works without GitHub (you can keep your repos on your laptop, on a shared server, or self-hosted). GitHub works without Git only barely (it’s the wrapping). In practice, ~99% of public open-source code lives on GitHub.

GitHub is owned by Microsoft (since 2018). The free tier is generous enough that solo developers and small teams rarely pay anything. Your Bible Quest project lives there, in a private repo.

There are alternatives: GitLab, Bitbucket, Codeberg, Gitea (self-hosted), Forgejo (self-hosted). They work the same way; GitHub is just the default.

Why it matters

Three reasons:

  1. Hosting. Your code lives in the cloud, accessible from any device. Your laptop dying is no longer a catastrophe.

  2. Collaboration. Pull requests, code review, comments, issues, project boards — all the structure around writing code with others.

  3. CI/CD and ecosystem integration. Vercel deploys on git push because Vercel listens to GitHub. Many other tools (Sentry, Statsig, security scanners) integrate with GitHub by default.

For solo developers, GitHub is still worth using even when you’re alone — for backup, discoverability, and habit-formation around modern workflows.

The anatomy of a GitHub repo

When you visit https://github.com/user/repo, you see:

TabWhat’s there
CodeFiles, README, branch switcher, commit history
IssuesBug reports, feature requests, todos — tracked discussions
Pull requestsProposed changes awaiting merge
ActionsCI/CD workflows (automated runs)
ProjectsKanban-style project boards
WikiProject-specific docs
SecurityVulnerability alerts, secrets scanning
InsightsContributors, traffic, dependency graph
SettingsVisibility, collaborators, integrations

The README at the project root is special: GitHub renders it at the top of the repo’s main page. Most projects’ README is the first thing visitors read — invest in making it good.

Visibility: public, private, internal

A repo is one of three:

  • Public — anyone on the internet can view (and clone). Cannot push without permission.
  • Private — only people you explicitly grant access can see it. Default for personal/work projects.
  • Internal (only on Enterprise plans) — visible to everyone in your organization.

Public repos are how open source happens. Private repos are how proprietary code stays private. You can switch visibility at any time, though changing public → private after the world has seen it doesn’t un-leak anything.

Your Bible Quest repo is private, which is the right default for personal projects.

SSH keys vs HTTPS authentication

To push to GitHub, you need to authenticate. Two options:

HTTPS + token

git push   # prompts for username/password

Modern Git uses a personal access token (PAT) instead of a password. You generate one at github.com → Settings → Developer settings → Personal access tokens.

You generate an SSH keypair, upload the public key to GitHub, and authenticate without typing anything:

ssh-keygen -t ed25519 -C "your-email@example.com"
# Then copy ~/.ssh/id_ed25519.pub to GitHub → Settings → SSH keys

After this, you use SSH URLs (git@github.com:user/repo.git) and push silently.

For new setups, SSH keys are the cleaner path. Once configured, it just works.

Cloning, forking, and watching

Three different operations:

  • Clone — make a local copy you can edit. You can push back if you have permission.
  • Fork — make a copy of someone else’s repo on GitHub under your own account. You can edit your fork freely, then propose changes back via a pull request.
  • Watch/Star — track a repo (notifications) or bookmark it (a star). Stars are GitHub’s main reputation metric for projects.

For open-source contribution, the flow is usually: fork → clone your fork → make changes → push to your fork → open a PR against the original repo.

Pull requests — the heart of collaboration

A pull request (PR) is a proposed change: “I have these commits on this branch; please consider merging them into your branch.”

A typical PR has:

  • Title — short summary
  • Description — longer explanation: what changed, why, how to test
  • Diff — line-by-line view of the changes
  • Comments — discussion (general and per-line)
  • Reviewers — people who can approve
  • Status checks — automated CI runs (tests, builds, linting)
  • Approvals — formal sign-off

When all checks pass and reviews approve, you can merge the PR. The branch’s commits become part of the target branch’s history.

PRs are how code review happens at scale. Even solo developers benefit — opening a PR against your own main branch gives you a clean review surface and a place for the deploy preview link to land.

See Pull requests for the full picture.

Issues

A space for asking questions, reporting bugs, suggesting features, or tracking todos. Each issue has:

  • A title and description
  • Comments / discussion
  • Labels (e.g. “bug,” “enhancement”)
  • Assignees
  • Milestones
  • A status: open or closed

Issues are the most common project-management surface on GitHub. Many open-source projects use them as their only PM tool.

You can link issues and PRs (PR description “fixes #123” auto-closes issue 123 when the PR merges).

GitHub Actions — CI/CD

GitHub Actions is GitHub’s built-in automation. You write workflow files in .github/workflows/*.yml:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm install
      - run: npm test

This runs tests on every push and PR. You can build, test, deploy, run linters, send notifications, anything — all triggered by git events.

For most modern web projects, you might rely entirely on Vercel’s deploy pipeline instead of writing Actions. But Actions is what you reach for when you need automation Vercel doesn’t provide (e.g. running tests in a specific way, syncing to a third-party tool).

Free tier: ~2000 minutes/month for private repos. Plenty for most personal use.

gh CLI — GitHub from the terminal

The official gh CLI lets you do GitHub things without leaving the terminal:

gh pr create --title "Add search" --body "Fuzzy search for notes"
gh pr list
gh pr view 123
gh pr merge 123 --squash
gh issue create --title "Login is broken"
gh repo clone user/repo

Install: from cli.github.com. Authenticate once with gh auth login. Then everything just works.

For Claude Code specifically, gh is the easiest way to make Claude interact with GitHub (open PRs, look at issues, check CI status) without setting up complex MCP servers.

GitHub-specific features worth knowing

  • README.md — rendered at the top of the repo. Markdown.
  • CONTRIBUTING.md — how outsiders should contribute. Linked from the “contribute” button.
  • CODEOWNERS — file that auto-assigns reviewers for specific paths.
  • GitHub Pages — free static site hosting from a repo. Useful for docs.
  • Releases — versioned snapshots with downloadable assets and release notes.
  • Discussions — threaded conversations, separate from issues.
  • Projects (v2) — kanban/spreadsheet hybrid for project management.
  • Dependabot — auto-PRs to bump vulnerable dependencies.
  • CodeQL / Code scanning — security analysis on every push.
  • Codespaces — a full dev environment in the browser, on GitHub’s infrastructure.
  • Copilot — GitHub’s AI coding assistant (separate product, but available here).
  • Sponsors — accept recurring donations.

You don’t need to use most of these to be productive. Knowing they exist means you can reach for them when relevant.

A concrete example: pushing a new local project to GitHub

# 1. Make sure your local project is a Git repo
cd my-project
git init
git add .
git commit -m "Initial commit"
 
# 2. Create a new empty repo on GitHub (via the web UI or gh CLI)
gh repo create my-project --private --source=. --remote=origin
 
# 3. Push
git branch -M main
git push -u origin main

Three commands, repo is live. Vercel can now import it. CI can run on it. The world (or your team) can see it.

Common gotchas

  • Pushing secrets. A .env file committed to a public repo is essentially a leak — GitHub scanners may find it, but even if not, anyone watching can. Use .gitignore aggressively.

  • Force-pushing to shared branches. git push --force can overwrite teammates’ work. For shared branches, use --force-with-lease (refuses if someone else has pushed since your last fetch).

  • Deleted branches with merged PRs. GitHub will offer to “delete branch” after merging a PR. Usually correct, but if you have downstream tooling that referenced the branch name, it might break.

  • Authentication confusion. “Permission denied (publickey)” usually means SSH isn’t set up. “Could not authenticate via HTTPS” usually means your PAT expired or the wrong username is configured.

  • Large files in Git. Git is great for text. For large binaries (designs, videos), use Git LFS (Large File Storage) or store them elsewhere. Repos with big binaries become painful fast.

  • Public vs private switching. Going private after public doesn’t un-leak. Going public after private exposes everything in your history.

  • Free-tier private CI limits. Actions minutes are limited per account on the free tier. Heavy CI use can hit the cap.

  • Branch protection rules. On important branches, set up protection so direct pushes are blocked and PRs are required. Easy to forget; costs nothing.

  • Two-factor authentication. GitHub now requires it for almost everything. Set up an authenticator app early; emergency recovery codes too.

  • Stale forks. Forks don’t auto-sync. If you forked a project, manually sync occasionally or the fork falls behind.

  • PRs from forks have limited Actions access. Workflows triggered by PRs from forks can’t access secrets — a security measure. Plan around it.

See also

Sources

Graph View

Backlinks