After this lesson, you will be able to: Use Git to version-control your code (init, add, commit, branch, merge, push, pull), create a GitHub repository, open and merge pull requests, resolve simple merge conflicts, set up a basic GitHub Actions CI workflow, write a README that sells your project, and make your GitHub profile look professional.
Every developer on every team uses Git. Every code review, every deploy, every collaboration goes through it. GitHub is where most of that work lives in public — your GitHub profile is the first thing a hiring manager looks at, and a profile with real commits and a polished README beats a long resume. This lesson takes you from never having used Git to comfortable on the commands you'll touch every day, plus the GitHub features (PRs, Actions, READMEs) that make you look professional.
Without version control: you copy your project folder before risky changes (`project-final`, `project-final-v2`, `project-actually-final`), you can't undo last Tuesday's mistake without losing everything since, and two people can't safely edit the same project at the same time. Git solves all three. Every commit is a snapshot you can return to. Every branch is a parallel version of the code. Every push syncs your work with teammates. Git is local (your laptop tracks history). GitHub is a hosting service (a website that stores your repo on the internet so others can collaborate). They're separate tools — Git works without GitHub, but the combo is what every team uses.
Run these in your project folder. Memorize the flow: edit → add → commit → push.
# One-time setupgit config --global user.name "Your Name"# Start a new repo from a folder you already havecd my-projectgit init # turn this folder into a git repogit status # see what changed since last commit# Save your work as a commitgit add . # stage every changed filegit commit -m "Add the bio page" # snapshot, with a message# Sync with GitHub (after you create the repo on github.com)git remote add origin https://github.com/you/my-project.gitgit branch -M main # rename the default branch to 'main'git push -u origin main # first push: -u sets the upstream# Day to day from then ongit pull # get teammates' changesgit add . # stage your editsgit commit -m "Fix the header alignment"git push # send your commits to GitHub
A branch is a named line of development. The default branch is usually `main` (used to be `master`). When you start a new feature, you create a branch off `main`, work there, then merge back into `main` when the feature is done. On any real team, you do NOT push directly to `main`. You push your branch to GitHub, open a pull request (PR), get someone to review it, and merge the PR. The protection isn't bureaucracy — it's what catches the bug you didn't notice and prevents you from breaking production when you push at 11 pm.
The five-command flow every developer does dozens of times a week.
# Start a new branch from maingit checkout -b feature/contact-form# ... edit files, make commits ...git add .git commit -m "Add contact form with validation"# Push the branch to GitHubgit push -u origin feature/contact-form# On GitHub: 'Compare & pull request' button appears.# Open the PR, get a review, merge.# After the PR is merged, clean up locally:git checkout maingit pull # get the merged codegit branch -d feature/contact-form # delete the local branch
A pull request is a proposal to merge changes from one branch into another. On GitHub, opening a PR creates a webpage that shows your diff, lets reviewers comment line by line, runs your CI checks automatically, and gives you a green Merge button when everything passes. Good PR description = title that explains WHAT in 5 words + body that explains WHY in 1-3 sentences + a screenshot or test plan if visual. Reviewers don't want to guess your intent — show them.
Create `.github/workflows/ci.yml` in your repo. Every push triggers it. This is the smallest useful CI workflow — install dependencies, run lint and tests, fail the PR if anything breaks.
# .github/workflows/ci.ymlname: CIon:push:branches: [main]pull_request:branches: [main]jobs:test:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v4- uses: actions/setup-node@v4with:node-version: '20'cache: 'npm'- run: npm ci- run: npm run lint- run: npm test --if-present
Your README.md is the first thing a hiring manager sees when they click your project. A good one has, in this order: **(1) Project name + one-line description** — what is this thing in a single sentence. **(2) A screenshot or demo GIF** — visual proof it actually works. **(3) Live URL** — let them click before they read. **(4) Tech stack list** — Next.js, TypeScript, Tailwind, Supabase, etc. The keywords recruiters scan for. **(5) How to run locally** — `npm install`, `cp .env.example .env.local`, `npm run dev`. Test it on a clean checkout before claiming it works. **(6) (Optional) Architecture decisions or interesting bits.** Anyone who reads this far is genuinely curious. Skip vanity sections (badges no one set up, 'About me' essays, generic 'Contributing' guidelines for solo projects). Brevity wins.
Draft a README for a hypothetical project. Required patterns check for an `<h1>`-style title heading (`# `), a 'Live demo' link section, and a 'Stack' or 'Tech stack' section listing at least three technologies. Plain Markdown, no HTML required.
Sign in and purchase access to unlock this lesson.