GitHub

What is GitHub?

GitHub is where code lives. It is a cloud-based platform built on top of Git — an open-source version control system — that lets you store code, track every change ever made to it, and collaborate with other developers without overwriting each other's work.

If you have ever worked with a developer, had an app built, or deployed a website, there is a near-certainty that GitHub was involved somewhere in that chain. It is the backbone of modern software development, used by over 100 million developers and hosting over 420 million repositories.

GitHub is also the glue that connects most AI coding tools. When you deploy to Vercel, you connect your GitHub repo. When Claude Code or Cursor work on your project, they read the files from your local git repository. When you use GitHub Copilot, it reads context from your repo. Understanding GitHub unlocks the entire ecosystem.

Git vs GitHub — what's the difference?

This confuses a lot of people.

Git is the underlying technology — a tool that runs on your computer and tracks changes to files. It's free, open-source, and has nothing to do with GitHub.

GitHub is a website that hosts your Git repositories in the cloud, adds a web interface, and layers collaboration tools (pull requests, issues, actions) on top.

Think of it like this: Git is the filing system. GitHub is the office building where everyone stores and shares their filing cabinets.

You can use Git without GitHub (storing repos locally or on other platforms like GitLab or Bitbucket). But in practice, almost everyone uses GitHub.

Core concepts

Repository (repo) — A folder that contains your project and the complete history of every change ever made to it. Think of it as a project folder that never forgets anything.

Commit — A saved snapshot of your files at a specific point in time. Every commit has a message describing what changed. Your commit history is a complete record of your project's evolution.

Branch — A parallel version of your code. You create a branch to work on a new feature without touching the main codebase. When it's ready, you merge it back in.

Pull request (PR) — A proposal to merge one branch into another. It shows exactly what changed, line by line, and gives teammates a place to comment, review, and approve before the merge happens.

Clone — Downloading a copy of a repository to your local machine so you can work on it.

Push — Uploading your local commits to GitHub so they're saved in the cloud and others can see them.

Fork — Creating your own copy of someone else's public repository so you can modify it independently.

Step-by-step setup

1. Create a GitHub account

Go to github.com and sign up for free. No credit card required.

2. Install Git on your machine

• Mac: Git is usually pre-installed. Check with git --version in Terminal. If not, install it via git-scm.com.
• Windows: Download Git from git-scm.com — it includes Git Bash.

3. Configure Git with your identity

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

This stamps your name on every commit you make.

4. Create your first repository

On GitHub, click the + icon → New repository. Give it a name, choose Public or Private, and click Create repository.

5. Connect your local project

In your project folder:

git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/yourusername/your-repo.git
git push -u origin main

Your code is now on GitHub.

The daily workflow

Once you're set up, most day-to-day work follows this loop:

1. Make changes to your files
2. git add .                         — stage the changes
3. git commit -m "describe what changed"  — save the snapshot
4. git push                          — upload to GitHub

For feature work:

1. git checkout -b feature/my-feature   — create a new branch
2. Make your changes, add, commit
3. git push origin feature/my-feature  — push the branch
4. Open a Pull Request on GitHub
5. Review, approve, and merge

Connecting to Vercel (automatic deploys)

One of the most powerful GitHub integrations: every time you push code to your main branch, Vercel automatically rebuilds and redeploys your site — no manual step required.

1. Go to vercel.com and create a project
2. Click Import Git Repository and authorise GitHub
3. Select your repo
4. Vercel detects your framework and deploys automatically

From that point, git push = your site is live with the new code within ~30 seconds. Every branch you push also gets its own preview URL automatically.

GitHub Actions — automated workflows

GitHub Actions is a built-in automation engine that runs scripts in response to events in your repo. The most common use: run your tests automatically every time someone pushes code, and block merges if tests fail.

Example: run tests on every push (.github/workflows/test.yml):

name: Run tests
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm test

Commit this file to your repo and GitHub will run npm test on every push. If tests fail, GitHub shows a red ✗ on the commit — and you can configure PRs to block merging until they pass.

Other things people automate with Actions:

• Deploy to cloud providers (AWS, GCP, DigitalOcean)
• Send Slack notifications when a PR is opened
• Auto-label issues based on keywords
• Run security scans on every pull request
• Publish packages to npm

GitHub Issues — tracking work

Issues are GitHub's built-in task tracker. Each issue can have:

• A title and description
• Labels (e.g. bug, feature, good first issue)
• An assignee
• A milestone
• Comments and a full discussion thread

For a solo project or small team, Issues replaces the need for a separate project management tool. For larger teams, it integrates with GitHub Projects — a Kanban-style board built into GitHub.

Linking commits to issues: If you include Fixes #42 in a commit message, GitHub automatically closes Issue #42 when that commit is merged into main.

GitHub for non-developers

You don't need to write code to get value from GitHub.

Business owners working with developers — GitHub is where your development team's work lives. Understanding pull requests means you can see exactly what changed before it goes live — no more "we deployed some updates" with no visibility into what.

Content and marketing teams — Many documentation sites and content-heavy projects (like knowledge bases) are maintained as Markdown files in a GitHub repo. With a basic understanding of git, you can edit docs directly and open a PR for review.

Project managers — GitHub Issues and Projects give you real-time visibility into what's being built, what's blocked, and what's shipped — directly in the same tool your developers use, with no translation layer.

GitHub and AI tools

GitHub is the connection point for the entire AI coding ecosystem:

If you're using any AI to build software, you'll interact with GitHub constantly — even if you never touch the command line directly.

GitHub vs alternatives

Use GitHub unless you have a specific reason not to — it has the largest community, the best AI tool integrations, and the most tutorials and resources online.

Common mistakes to avoid

Don't commit secrets. API keys, passwords, and .env files should never be in a git repo. Add .env to your .gitignore file before your first commit. If you accidentally commit a secret, rotate it immediately — it's now public, even if the repo is private (git history persists).

Commit often, in small chunks. A commit that changes 50 files is hard to understand and hard to revert. Commits that change one thing with a clear message are easy to reason about.

Write useful commit messages. "fix stuff" is useless. "fix: correct null check in payment handler" tells you exactly what happened and why.

Always pull before you push. If you're collaborating, run git pull before starting work each day to get the latest changes from your teammates.