Back to docs
09Week 1

GitHub Basics

Version control, collaboration, and keeping your work safe

Key Concepts

Git is a version control system that tracks changes to your files over time. GitHub is a platform that hosts your Git repositories online. Together, they let you save your work, collaborate with others, and undo mistakes.

ConceptWhat It Means
repoA repository — your project folder, tracked by Git. Contains all files and their history.
commitA snapshot of your project at a point in time. Like a save point you can return to.
branchA parallel version of your project. Work on features without affecting the main code.
remoteThe online version of your repo (usually on GitHub). Your local repo syncs with it.
pushUpload your local commits to the remote (GitHub). Makes your work available online.
pullDownload changes from the remote to your local repo. Gets updates others have made.
cloneDownload a complete copy of a remote repo to your local machine.
statusShows which files have changed, which are staged, and which are untracked.
diffShows the exact lines that changed between versions. Red = removed, green = added.

Initial Setup

Before using Git for the first time, configure your name and email. These are attached to every commit you make:

# Set your name (appears in commit history)
git config --global user.name "Your Name"

# Set your email (should match your GitHub account)
git config --global user.email "you@example.com"

# Verify your config
git config --list

Starting a Project

Option A: Start From Scratch

# Create a new project folder
mkdir my-project
cd my-project

# Initialize Git tracking
git init

# Create your first file
echo "# My Project" > README.md

# Stage the file
git add README.md

# Create your first commit
git commit -m "Initial commit"

# Connect to GitHub (create a repo on GitHub first)
git remote add origin https://github.com/yourusername/my-project.git

# Push to GitHub
git push -u origin main

Option B: Clone an Existing Project

# Clone a repo from GitHub
git clone https://github.com/username/project-name.git

# Move into the project folder
cd project-name

# You're ready to work — Git is already initialized

The Daily Workflow

This is the workflow you’ll use every day. It has 7 steps, but it becomes muscle memory quickly:

# 1. Check what's changed
git status

# 2. See the actual changes (line by line)
git diff

# 3. Stage the files you want to commit
git add src/components/Button.tsx
git add src/components/Card.tsx
# Or stage everything:
git add .

# 4. Commit with a descriptive message
git commit -m "Add Button and Card components with all variants"

# 5. Pull any changes from GitHub (in case someone else pushed)
git pull

# 6. Push your commits to GitHub
git push

# 7. Verify everything is clean
git status

Writing Good Commit Messages

Commit messages are a log of your project’s history. Write them for your future self — you’ll thank yourself when you need to find when something changed.

Bad Commit Messages

"fixed stuff"
"updates"
"wip"
"asdf"
"changes"

Good Commit Messages

"Add Button component with primary, ghost, and danger variants"
"Fix hover state on Card component — was using wrong color token"
"Update LoginForm to validate email format before submission"
"Remove unused import in Header component"
"Refactor design tokens to use CSS custom properties"

Commit Message Verbs

VerbWhen to UseExample
AddNew feature or file“Add search bar to header”
FixBug fix“Fix button alignment on mobile”
UpdateEnhance existing feature“Update card shadow to use new token”
RemoveDelete code or features“Remove deprecated tooltip component”
RefactorRestructure without changing behavior“Refactor form validation into custom hook”
StyleVisual changes only“Style login page to match new mockups”
DocsDocumentation changes“Docs: add usage examples to README”

Branching — Working in Parallel

Branches let you work on new features without affecting the main codebase. When your feature is ready, you merge it back into main.

# Create a new branch and switch to it
git checkout -b feature/login-form

# Do your work... make changes, add files, etc.

# Stage and commit your changes
git add .
git commit -m "Add LoginForm component"

# Push the branch to GitHub
git push -u origin feature/login-form

# When the feature is done, switch back to main
git checkout main

# Pull latest changes
git pull

# Merge your feature branch
git merge feature/login-form

# Push the merged main branch
git push

# Delete the feature branch (optional cleanup)
git branch -d feature/login-form

Undoing Things

Everyone makes mistakes. Here’s how to undo them:

CommandWhat It DoesWhen to Use
git restore filenameDiscard changes to a specific fileYou made changes you don’t want to keep
git reset HEAD filenameUnstage a file (keep the changes, just remove from staging)You staged a file by accident
git stashTemporarily save all changes and revert to clean stateYou need to switch branches but aren’t ready to commit

Warning: Be very careful with git reset --hard. This permanently deletes all uncommitted changes. There is no undo. Always commit or stash your work before running destructive Git commands.

The .gitignore File

The .gitignore file tells Git which files to ignore — files that shouldn’t be tracked or pushed to GitHub. Create it in the root of your project:

# Dependencies
node_modules/

# Environment variables (SECRETS!)
.env
.env.local
.env.production

# Build output
.next/
out/
dist/

# OS files
.DS_Store
Thumbs.db

# Editor files
.vscode/
.idea/

# Debug logs
npm-debug.log*
yarn-debug.log*

Warning: Never commit .env files to Git. They contain API keys, database passwords, and other secrets. If you accidentally commit a .env file, the secrets are in your Git history forever — even if you delete the file later. Rotate any exposed keys immediately.