Getting Started with GitHub

Before you write a single line of app code, you need a way to track it. That's what Git and GitHub are for. This chapter walks you through everything from creating your first account to opening your first pull request. By the end, your code will be backed up in the cloud, version-controlled, and ready for collaboration — even if you're working alone.

This knowledge is more relevant than ever in the AI-assisted coding era. Tools like Claude Code work directly with Git: they read your project history, suggest commits, and operate on branches. Understanding Git means you stay in control of what the AI produces — reviewing changes, rolling back mistakes, and building a clear record of every decision.

What Are Git and GitHub?#

Git is a version control system. It runs on your computer and keeps a complete history of every change you make to your project — what changed, when, and by whom. Think of it as a time machine for your code: if something breaks, you can go back to any earlier version.

GitHub is a website that hosts your Git repositories in the cloud. It adds collaboration features on top of Git: you can share your code with others, propose changes through pull requests, report bugs with issues, and automatically run tests on every change.

A simple way to remember the difference:

Why Version Control Matters#

Imagine writing an essay in a word processor with no undo button, no revision history, and no way to back it up. If you accidentally deleted a section, it would be gone forever.

Version control solves that problem for code. It lets you:

• Recover anything — roll back to any earlier version of your project instantly
• Experiment safely — try a new approach in a separate branch; if it doesn't work, just delete the branch without affecting your main code
• See the full story — every commit records what changed and why, creating a readable history of every decision
• Collaborate without chaos — multiple people can work on the same project at the same time without overwriting each other's work
• Review AI-generated changes — when an AI tool modifies your code, Git shows you exactly what changed, so you can accept, adjust, or revert with confidence

Even if you're building something solo, version control is worth it. It turns "I hope I didn't break anything" into "I know exactly what changed and I can undo it."

Step 1: Create a GitHub Account#

1. Go to github.com
2. Click Sign up and follow the prompts
3. Choose the Free plan — it includes unlimited public and private repositories

Once you're in, take a moment to set a profile picture and username. Your username appears in every repository URL you create (e.g., github.com/yourname/your-project), so pick something professional.

Step 2: Install Git and Configure Your Identity#

Install Git#

Mac: Git comes with the Xcode Command Line Tools. Run this in your terminal and follow the prompts:

xcode-select --install

Alternatively, download the installer from git-scm.com/downloads.

Windows: Download and run the installer from git-scm.com/downloads. During installation, keep the default options — they work well for most setups.

Linux: Install via your package manager:

# Ubuntu / Debian
sudo apt install git

# Fedora
sudo dnf install git

Verify the installation worked:

git --version
# git version 2.x.x

Configure Your Identity#

Git attaches your name and email to every commit you make. This is how collaborators (and AI tools) know who made which change. Run these two commands once — you never need to repeat them:

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

Use the same email you signed up with on GitHub. The --global flag means this configuration applies to every project on your machine. To confirm your settings were saved:

git config --list

You should see user.name and user.email in the output.

Core Concepts#

Before running any commands, it helps to understand what Git is actually doing under the hood. There are five key concepts:

The key insight is that Git uses a three-step flow: you edit files in the working tree, stage the specific changes you want to save, and then commit them into the permanent history. The staging step exists so you can group related changes into a single, focused commit — rather than being forced to commit everything at once.

Step 3: Your First Repository#

Let's create a Git repository from scratch.

Create a Local Repository#

Make a new folder for your project and turn it into a Git repository:

mkdir my-project
cd my-project
git init

git init creates a hidden .git/ folder inside your project. That folder is where Git stores the entire history. Don't delete it.

Check What Git Sees#

Create a file and then ask Git what it knows about the project:

echo "# My Project" > README.md
git status

You'll see output like:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

"Untracked" means Git sees the file but isn't recording changes to it yet. The git status output is divided into three sections:

• Changes to be committed — staged changes ready for your next commit
• Changes not staged for commit — files you've modified but haven't staged yet
• Untracked files — new files Git isn't watching yet

Stage and Commit#

Stage the file, then commit it:

git add README.md
git commit -m "Initial commit"

The -m flag lets you write the commit message inline. A good commit message is short (under 72 characters) and describes what changed and why — not how. For example: "Add user login page" is better than "Changed some files".

To see your commit in the history:

git log --oneline

Output:

a1b2c3d Initial commit

Each commit gets a unique ID (the letters and numbers on the left). That ID is permanent — you can always reference any commit by it.

The Core Workflow#

Most of your day-to-day Git use comes down to a handful of commands:

A typical session looks like this:

# 1. Check what changed
git status

# 2. Stage your changes
git add .

# 3. Commit with a message
git commit -m "Add contact form"

# 4. Push to GitHub
git push

git pull is the reverse of git push — it fetches changes from GitHub and merges them into your local branch. You'll use it frequently when collaborating with others, or when you work on the same project from multiple computers.

When working with AI coding tools, this same workflow applies. After the AI suggests or writes changes, you run git status and git diff to review exactly what was modified before staging and committing. You are always in control of what gets recorded in the history.

Step 4: Connect to GitHub with SSH#

When you push code to GitHub, it needs to verify that you are who you say you are. There are two ways to do this:

• HTTPS — uses a username and token (simpler to set up, but prompts for credentials)
• SSH — uses a cryptographic key pair (takes a few minutes to set up, then never asks again)

SSH is the recommended approach. Once configured, you can push and pull without any password prompts.

How SSH Keys Work#

SSH uses a pair of keys: a private key that stays on your computer and a public key that you share with GitHub. When you connect, GitHub checks whether your private key matches the public key it has on file. You never send your password over the network. The private key never leaves your machine — that's what makes it secure.

Generate Your SSH Key#

Run this command, replacing the email with the one you used for GitHub:

ssh-keygen -t ed25519 -C "you@example.com"

When prompted:

• File location: Press Enter to accept the default (~/.ssh/id_ed25519)
• Passphrase: Enter a passphrase for extra security, or press Enter to skip

This creates two files:

• ~/.ssh/id_ed25519 — your private key. Never share this with anyone.
• ~/.ssh/id_ed25519.pub — your public key. This is what you give to GitHub.

Add the Key to the SSH Agent#

The SSH agent is a background program that holds your loaded keys in memory. Once you add your key to it, you won't need to type your passphrase on every push or pull.

Mac:

eval "$(ssh-agent -s)"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Also create (or edit) the file ~/.ssh/config and add:

Host github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

Linux:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Windows (PowerShell, run as Administrator):

Get-Service -Name ssh-agent | Set-Service -StartupType Manual
Start-Service ssh-agent
ssh-add C:\Users\YourName\.ssh\id_ed25519

Note for Windows users: To open PowerShell as Administrator, right-click the PowerShell icon in the Start menu and choose Run as administrator.

Add Your Public Key to GitHub#

Copy your public key to the clipboard:

# Mac
pbcopy < ~/.ssh/id_ed25519.pub

# Linux
cat ~/.ssh/id_ed25519.pub
# Then manually select and copy the output

# Windows
clip < C:\Users\YourName\.ssh\id_ed25519.pub

Then on GitHub:

1. Click your profile picture (top right) → Settings
2. In the left sidebar, under Access, click SSH and GPG keys
3. Click New SSH key
4. Give it a descriptive title (e.g., Personal MacBook)
5. Leave Key type as Authentication Key
6. Paste your public key into the Key field
7. Click Add SSH key

Test that it worked:

ssh -T git@github.com
# Hi yourname! You've successfully authenticated...

If you see that message, SSH is configured correctly.

Step 5: Create a Repo on GitHub and Push Your Code#

Now let's put your local project on GitHub.

Create the Repository#

1. On GitHub, click the + button in the top right → New repository
2. Give it a name (e.g., my-project)
3. Leave everything else at the defaults — do not check "Add a README" or "Add .gitignore" if your project already has files. Initializing a repo with those files when you already have local commits creates a conflict you'll have to resolve manually.
4. Click Create repository

GitHub will show you a page with setup instructions. You want the section labeled "…or push an existing repository from the command line".

Link and Push#

Back in your terminal, inside your project folder:

# Add GitHub as the remote destination (use your actual URL from GitHub)
git remote add origin git@github.com:your-username/my-project.git

# Confirm the remote was added
git remote -v

# Push your commits to GitHub
git push -u origin main

The -u flag sets origin main as the default destination, so from now on you can just type git push without any extra arguments.

Refresh the GitHub page — your files are now there.

Step 6: The .gitignore File#

Not every file in your project should go to GitHub. API keys, passwords, generated build files, and installed dependencies don't belong there — and some of them (like .env.local containing your secret keys) are a serious security risk if shared publicly.

The .gitignore file tells Git which files and folders to permanently ignore.

Create It#

At the root of your project, create a file named .gitignore (the dot at the start is important — it makes it a hidden file on Mac and Linux):

touch .gitignore

Open it in your editor and add patterns for what to ignore. Here's a good starting template for a Next.js project:

# Dependencies (can be regenerated with npm install)
node_modules/

# Build output (generated by npm run build)
.next/
out/
dist/

# Environment variables (contains secrets — never commit these)
.env
.env.local
.env.*.local

# OS-generated files
.DS_Store
Thumbs.db

# Editor files
.vscode/
.idea/

# Logs
*.log
npm-debug.log*

Commit the .gitignore file itself so that everyone working on the project shares the same ignore rules:

git add .gitignore
git commit -m "Add .gitignore"
git push

Common .gitignore Patterns#

If you already committed a file you want to ignore: Adding a pattern to .gitignore won't un-track a file that's already been committed. To stop tracking it, run git rm --cached filename and then commit that change. The file stays on your disk — it just won't be included in future commits.

Step 7: Branches and Pull Requests#

Branches are how you safely develop new features without disturbing your working code. The workflow is: create a branch, make your changes, push the branch to GitHub, open a pull request, and merge.

Why Use Branches?#

The main branch should always contain working, deployable code. When you want to add a feature or fix a bug, you create a new branch. If the work goes sideways — or if an AI-generated approach turns out to be the wrong direction — you delete the branch and main remains untouched.

Create a Branch#

# Create a new branch and switch to it
git switch -c feature/contact-form

You may also see the older equivalent:

git checkout -b feature/contact-form

git switch is the modern command introduced in Git 2.23; git checkout -b does the same thing and is still widely used. Both are correct — you'll encounter both in tutorials and team codebases.

The feature/contact-form naming convention (category/description) is common but not required. Whatever you name it, keep it short and descriptive.

Confirm you're on the new branch:

git branch
# * feature/contact-form
#   main

The * marks your current branch.

Make Changes and Push the Branch#

Make your changes, stage them, and commit as usual:

git add .
git commit -m "Add contact form"

Push the branch to GitHub:

git push -u origin feature/contact-form

Open a Pull Request#

1. Go to your repository on GitHub
2. You'll see a yellow banner: "feature/contact-form had recent pushes" — click Compare & pull request
3. Make sure the base branch is main and the compare branch is your feature branch
4. Write a clear title and description explaining what changed and why
5. Click Create pull request

A pull request (PR) is a formal proposal to merge your branch into main. It's also a place for code review: teammates can leave comments on specific lines, suggest changes, and approve the work before it merges. Even when working solo, opening a PR gives you a chance to review the full diff before it becomes part of your permanent history.

Merge the Pull Request#

Once the PR is approved (or if you're working alone and you're satisfied), click Merge pull request → Confirm merge.

After merging, click Delete branch to clean up. The commits are now part of main.

Back in your terminal, sync up:

git switch main
git pull

Reading a Repository on GitHub#

When you open someone else's (or your own) repository on GitHub, here's what each tab does:

Navigating a File#

Click any file in the Code tab to open it. From there:

• Raw — see the plain text without formatting
• Blame — see who wrote each line and in which commit
• History — see every commit that touched this file

The commit hash shown at the top of the file (e.g., a1b2c3d) is a permanent link to that exact version. You can share it, and it will always show the file exactly as it was at that point in time.

Summary#

Here's a condensed reference for everything covered in this chapter:

You now have the foundation for every project you'll build. Version control is running, your code is backed up on GitHub, and you know how to use branches to keep your main code safe while you experiment — whether the changes come from you or from an AI tool.

Head to the next chapter to create your first Next.js project.