GitHub

Every project I’ve ever seen go sideways had one thing in common: nobody could answer the question “what changed?”

A client’s site breaks after a deployment. Someone overwrites a colleague’s work. A feature that was working last Tuesday now isn’t. A contractor disappears mid-project and takes the only copy of the code with them.

GitHub solves all of this. It’s where your code lives, where your team collaborates, where deployments originate, and increasingly where AI agents do actual work on your behalf. In 2026, it’s not optional for technical teams. It’s infrastructure.

What GitHub is

The problem it solves is familiar to anyone who’s worked on anything with other people. Imagine writing a document with five people without any coordination — you’d email versions back and forth and inevitably someone would overwrite someone else’s changes. Google Docs solved this for documents by tracking every change and letting you revert to any version.

GitHub is Google Docs for code. Except it’s far more powerful, because code has different needs. Code changes need to be tested before they go live. Multiple people need to work on different features simultaneously without breaking each other’s work. And when something breaks, you need to pinpoint exactly which change caused it.

Under the hood, GitHub is built on Git, a version control system created by Linus Torvalds in 2005. Git is the protocol. GitHub is the platform built on top of it. Think of it this way: Git is to GitHub what email is to Gmail. Alternatives exist (GitLab, Bitbucket), but GitHub’s gravity — 180 million developers, 420 million repositories — makes it the default.

The core concepts

A repository is a project folder with a built-in time machine. It contains all your files plus the complete history of every change ever made.

A commit is a save point. When you commit changes, you’re recording them permanently with a message describing what changed and a unique ID.

A branch is a parallel universe for your project. You create a branch to work on something without affecting the main version. When you’re done and the work is tested, you merge it back. The default branch is called main — it represents the current official version.

A pull request (PR) is a formal proposal to merge your branch’s changes into main. It’s where code review happens. Your teammates see exactly what you changed, leave comments, suggest improvements, and approve or request changes. Pull requests are GitHub’s killer feature. They turn code changes from “someone pushed something and we hope it works” into a structured review process.

The entire workflow in one sentence: create a branch, make changes, open a pull request, get it reviewed, merge it. Everything else is a variation on this loop.

Branches and pull requests in practice

The feature branch workflow is what most teams use. Start from an up-to-date main, create a feature branch with a descriptive name, do your work, push, open a PR, get it reviewed, merge, and delete the branch.

Branch naming conventions matter for team sanity. Use prefixes: feature/add-oauth-login, fix/null-pointer-on-checkout, hotfix/critical-auth-bypass.

When you merge a PR, GitHub gives you three choices. Merge commit preserves every commit plus adds a merge commit — full history but noisy. Squash and merge collapses your entire PR into a single clean commit on main — this is what most product teams should use. Rebase and merge replays commits linearly. My recommendation: squash and merge for product teams, merge commits for open source.

Code review is where pull requests earn their keep. As a reviewer: check design fit first, then functionality, then code quality. Ask questions instead of dictating. Distinguish between must-fix and nice-to-have. As an author: keep PRs small and focused, review your own PR before requesting review, write a clear description.

GitHub Issues and Projects

GitHub Issues is a surprisingly capable task management system. Each issue is a trackable unit of work with assignees, labels, milestones, and linked PRs. Use keywords like “Closes #42” in your PR description, and GitHub automatically closes the issue when the PR merges. As of 2025, Issues supports sub-issues (up to 8 levels) and org-wide issue types, making it competitive with Linear and Jira for many teams.

Projects v2 pulls issues and PRs into customizable views: Kanban boards, spreadsheet-style tables, and timeline roadmaps. For small teams, GitHub Issues + Projects can replace Jira entirely.

GitHub Actions

This is where your repository stops being passive storage and starts doing things. Every time something happens — a push, a pull request, a schedule — Actions automatically runs tasks: build your code, run tests, deploy to production, scan for security.

You configure workflows with YAML files. Events trigger jobs on runners (GitHub-hosted VMs or your own machines). Steps either run shell commands or use pre-built actions from a marketplace with thousands of community options.

Common workflows worth setting up: linting and formatting (catch style issues before review), auto-deploy on merge to main, dependency updates with Dependabot, and security scanning with CodeQL. The free tier gives you 2,000 minutes per month on private repos, unlimited on public repos.

GitHub as the deployment trigger

Every modern deployment platform uses GitHub as the trigger. Vercel, Render, Netlify, Cloudflare Pages — connect your repo and every push creates a preview deployment. Merge to main and it deploys to production. Preview URLs are automatically commented on every PR.

The pattern is universal: your git push is the deployment intent, your branch is the environment, and the PR preview URL is the review artifact. “Deploying” becomes “merging a pull request.” No FTP, no SSH, no manual steps.

GitHub in the AI era

As of 2026, GitHub is the platform where AI agents do real development work.

GitHub Copilot has evolved from code autocomplete into a family of AI agents: code completion, conversational chat in your IDE, Agent Mode for multi-file changes, and most significantly — the coding agent. Assign an issue to Copilot, and it spins up a cloud environment, writes code, runs tests, and opens a draft PR. You review and merge. Free tier gets 2,000 completions/month and 50 chat messages.

Claude Code + GitHub is the integration I use daily. When Claude Code is running in a project with the GitHub CLI installed, it can create issues, open PRs, read comments, respond to reviews, and manage branches — all through natural language. Tell it to commit changes and open a PR, and it writes a message, pushes the branch, and opens a PR with a detailed description.

The first time I saw this work, I was skeptical. I gave Claude Code a vague instruction about a refactor, expecting it to ask for clarification. Instead, it read the codebase, planned changes, implemented them across four files, ran tests, wrote a commit message that accurately described what it had done, and opened a PR with a summary I would have been happy to write myself. I merged it in under a minute. That was the moment GitHub stopped being a code host for me and became a collaboration platform where one of my collaborators doesn’t sleep.

As a GitHub Action, the official integration lets you trigger Claude Code from GitHub events. When someone comments “@claude fix this bug” on an issue, Claude reads the issue, creates a branch, writes the fix, runs tests, and opens a PR.

AI code review is the emerging layer. CodeRabbit is the most-installed AI review GitHub App (2M+ repos), reviewing every PR automatically with inline comments. The best practice emerging is AI review first (catches style issues, common bugs, documentation gaps), then human review focused on architecture and business logic. This reduces human review time by 30–50% while catching more issues.

Security basics

GitHub has excellent built-in security features. Most are free. Most teams don’t enable them.

Secret scanning and push protection blocks commits that contain API keys or tokens before they reach GitHub. Dependabot monitors dependencies for vulnerabilities and automatically opens PRs to update them. CodeQL analyzes your code for security issues. Never store secrets in code — use GitHub’s encrypted secrets, referenced in workflow files and automatically masked in logs.

One critical lesson from our client work: a .gitignore file only prevents untracked files from being added. If someone already committed .env with API keys, those keys are in the full git history even after the file is removed. I’ve seen this happen to three different teams. If it happens to you, rotate the exposed keys immediately.

The bottom line

GitHub is the single most important tool in a modern development workflow. Not because it’s glamorous. Because everything else plugs into it. Your IDE connects to it. Your deployment platform triggers from it. Your CI/CD runs on it. Your AI agents operate through it.

The core workflow hasn’t changed in fifteen years: branch, commit, push, open a PR, review, merge. But what happens around that workflow has been transformed by AI. In 2026, you can assign a bug to an AI agent, have it write a fix, get it reviewed by another AI agent, and deploy to production — all through GitHub primitives that have existed since 2008.

Start small. Create a repository. Make a commit. Open a pull request. Get comfortable with the loop. Then layer in Actions for CI/CD, Dependabot for security, and Claude Code for AI-assisted development.

---

This is the free web edition of Chapter 5. The full text — with Git installation walkthroughs, first-repo tutorials, workflow YAML examples, Dependabot configurations, and Claude Code GitHub Action setup — is available in 42: The AI Builder’s Stack, coming Q3 2026 on Amazon in hardcover, paperback, and digital.