Getting Started with Git & GitHub

Picture this: you're working on a feature. It's going well. Then you make a change that breaks everything, and you can't remember what the code looked like an hour ago. Or worse: your teammate overwrites your changes because you were editing the same file. Or worse still: the production server goes down and nobody knows which code change caused it.

Version control eliminates all of these problems. Every change is tracked. Every version is recoverable. Every team member works in their own space without stepping on each other's toes.

Git is the version control system used by virtually every software team on the planet. It was created by Linus Torvalds (yes, the Linux guy) in 2005, and it won the version control wars for two key reasons:

• It's distributed — Every developer has a complete copy of the entire project history. No central server bottleneck. No single point of failure.
• Branching is instant — Creating, switching, and merging branches takes milliseconds. This makes experimentation cheap and safe.

Git vs GitHub — Git is the tool that runs on your machine. GitHub is a cloud platform that hosts Git repositories and adds collaboration features: pull requests, code reviews, issue tracking, CI/CD, and more. GitLab and Bitbucket are alternatives to GitHub, but they all use Git underneath.

Installing Git:

• macOS: Open Terminal and type git --version. If it's not installed, macOS will prompt you to install Xcode Command Line Tools. Alternatively: brew install git.
• Windows: Download from git-scm.com. The installer includes Git Bash, a terminal that gives you a Linux-like command line experience on Windows.
• Linux: sudo apt install git on Ubuntu/Debian or sudo dnf install git on Fedora.

Configure your identity — Git attaches your name and email to every commit:

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

Create your first repo:

mkdir my-project
cd my-project
git init

That git init creates a hidden .git directory that stores your entire version history. The three zones you need to understand: your working directory (the actual files you see), the staging area (files marked for the next commit), and the repository (the permanent history of committed snapshots).

Git has hundreds of commands, but you'll use about ten of them 95% of the time:

# Check what's changed
git status

# Stage specific files (prepare for commit)
git add index.html styles.css

# Stage everything that's changed
git add .

# Commit staged changes with a message
git commit -m "Add homepage layout and base styles"

# View commit history
git log --oneline

# See what changed in unstaged files
git diff

# See what's staged for commit
git diff --staged

Undoing mistakes (you'll need these, trust me):

# Discard changes to a file (revert to last commit)
git checkout -- styles.css

# Unstage a file (keep the changes, just remove from staging)
git reset HEAD styles.css

# Undo the last commit but keep the changes
git reset --soft HEAD~1

# Create a new commit that reverses a previous one
git revert abc123f

Golden rule: commit early, commit often. Each commit should be a logical unit — "Add user login form" or "Fix null check in payment handler." Not "WIP" or "stuff." Your commit history is documentation. Make it useful.

Branches are what make Git powerful for teams. They let you work on a feature in isolation — your changes don't affect anyone else until you explicitly merge them back.

# See all branches (the * marks your current branch)
git branch

# Create and switch to a new branch in one step
git checkout -b feature/user-dashboard

# Work normally — add, commit, repeat
git add .
git commit -m "Add dashboard sidebar navigation"

# When the feature is done, merge it back into main
git checkout main
git merge feature/user-dashboard

# Clean up the branch
git branch -d feature/user-dashboard

Merge conflicts happen when two branches modify the same lines. Git can't decide which version to keep, so it marks the conflict and asks you to resolve it:

<<<<<<< HEAD
const theme = 'light';
=======
const theme = 'dark';
>>>>>>> feature/dark-mode

You manually choose the right version (or combine them), delete the conflict markers, then git add and git commit. Conflicts sound scary but they're usually straightforward — most are 2–5 lines.

Branching strategies for teams:

• GitHub Flow — Simple and popular. Create feature branches from main, open PRs, merge after review. Works for most teams.
• Trunk-based development — Everyone commits to main frequently with very short-lived branches. Requires strong CI/CD and automated testing.

GitHub adds a collaboration layer on top of Git. Here's the workflow most teams follow:

# Connect your local repo to GitHub
git remote add origin https://github.com/your-username/my-project.git

# Push your main branch to GitHub for the first time
git push -u origin main

# Create a feature branch, do work, and push it
git checkout -b feature/search
git add .
git commit -m "Add search functionality"
git push origin feature/search

After pushing a branch, GitHub shows a prompt to create a Pull Request. This is where collaboration happens:

1. You describe what the PR does and why
2. Teammates review the code — they can comment on specific lines, suggest changes, or approve
3. You address feedback with additional commits (they automatically appear in the PR)
4. Once approved, you merge the PR into main
5. Delete the feature branch

PR best practices that will make you popular with reviewers:

• Keep PRs small — under 300–400 lines of changes. Large PRs get rubber-stamped, not reviewed.
• Write descriptive titles and descriptions. "Add search" tells nothing. "Add full-text search to course catalog with debounced input and result highlighting" tells everything.
• Add screenshots for UI changes
• Self-review your own PR before requesting review — you'll catch obvious issues

Working with a team introduces one key challenge: keeping your branch up to date with changes other people are merging into main.

Start-of-day routine:

# Get the latest changes from the remote
git checkout main
git pull origin main

# Create your feature branch from the updated main
git checkout -b feature/notifications

Keeping a long-lived branch current:

# Option 1: Merge main into your branch
git checkout feature/notifications
git merge main

# Option 2: Rebase (replays your commits on top of the latest main)
git checkout feature/notifications
git rebase main

Merging creates a merge commit (preserves the full history of both branches). Rebasing rewrites history to create a linear sequence (cleaner log, but don't rebase branches that other people have pulled). For most teams, merge is the safer default.

Commit message conventions that teams actually follow:

• Use imperative mood: "Add search filter" not "Added search filter"
• Be specific: "Fix null pointer when user has no profile image" not "Fix bug"
• Reference issue numbers: "Implement course bookmarks (#142)"
• Keep the first line under 72 characters

Some files should never be committed. Environment variables with API keys. Build output directories. Editor-specific config files. The .gitignore file tells Git which files and folders to skip.

# Dependencies (reinstalled via package manager)
node_modules/
venv/
__pycache__/

# Environment variables (NEVER commit secrets)
.env
.env.local
.env.production

# Build output
dist/
build/
.next/
out/

# IDE and editor files
.vscode/settings.json
.idea/
*.swp

# OS-generated files
.DS_Store
Thumbs.db

The rules I wish someone had told me on day one:

1. Never commit secrets. No API keys, no database passwords, no tokens. Use environment variables. If you accidentally commit a secret, rotating it is the only safe option — removing it from Git history is possible but complex, and the secret may already be cached in multiple places.
2. Commit early, commit often. Small commits are easier to review, easier to revert, and easier to understand six months from now.
3. Pull before you push. Always get the latest remote changes before pushing yours. Saves you from merge conflicts that could have been avoided.
4. Never push directly to main. Always use feature branches and pull requests. Even for "quick fixes." Especially for "quick fixes."
5. Write meaningful commit messages. "fix stuff" helps nobody. "Fix checkout total calculation when applying percentage discount" helps everyone, including future you.

Git has a learning curve. You'll mess up a merge. You'll accidentally commit something you shouldn't. You'll get into a "detached HEAD" state and panic. All of that is normal. The key is that Git makes almost everything reversible — the data safety net is real.