BiTree
  • Search For Lessons
  • Curriculum
  • Pricing
  • For Educators
  • Become a Tutor
  • About
  • Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
BiTree

Live coding lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Search For Lessons
  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Become a Tutor
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 BiTree. All rights reserved.
Curriculum/Web Development/Git, GitHub, and Your First Repo
50 minBeginner

Git, GitHub, and Your First Repo

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.

Prerequisites:How the Web Works

What version control actually solves

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.

The 7 commands you'll use every day

Run these in your project folder. Memorize the flow: edit → add → commit → push.

tsx
# One-time setup
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
# Start a new repo from a folder you already have
cd my-project
git init # turn this folder into a git repo
git status # see what changed since last commit
# Save your work as a commit
git add . # stage every changed file
git 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.git
git 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 on
git pull # get teammates' changes
git add . # stage your edits
git commit -m "Fix the header alignment"
git push # send your commits to GitHub

Branches, merges, and why you never push to main directly

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.

Branching workflow

The five-command flow every developer does dozens of times a week.

tsx
# Start a new branch from main
git checkout -b feature/contact-form
# ... edit files, make commits ...
git add .
git commit -m "Add contact form with validation"
# Push the branch to GitHub
git 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 main
git pull # get the merged code
git branch -d feature/contact-form # delete the local branch

Pull requests on GitHub

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.

💡 Resolving a merge conflict

A merge conflict happens when Git can't auto-combine two changes to the same lines. It looks scary the first time; it's mechanical. Git marks the conflicting region in your file like this: ``` <<<<<<< HEAD your change ======= their change >>>>>>> branch-name ``` Open the file, decide which version to keep (or combine both), DELETE the `<<<<<<<` / `=======` / `>>>>>>>` lines, save, then `git add <file>` and `git commit`. That's it. VS Code highlights the markers and gives you Accept Current / Accept Incoming / Accept Both buttons.

GitHub Actions — automate linting and tests on every push

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.

tsx
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm run lint
- run: npm test --if-present

Writing a README that makes you look professional

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.

💡 Make your GitHub profile look professional

Hiring managers click your username from a resume or LinkedIn. The first impression is the profile page. Five 10-minute wins: (1) **Profile photo** — same one you use on LinkedIn. (2) **Bio line** — your role + stack in 8 words ('Frontend dev. Next.js, TypeScript, Supabase. Open to work.'). (3) **Pin your 3 best repos** to the top of your profile — the ones with screenshots, READMEs, and live links. (4) **Create a profile README** by making a repo named exactly your username; the README.md shows on your profile page. (5) **Make sure your green contribution squares aren't empty** — even small daily commits show momentum. Quality beats quantity, but zero shows nothing.

Write a simple README

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.

Loading exercise…

💡 Common mistakes only experienced devs catch

Six Git/GitHub traps that bite even competent juniors. (1) **Committing secrets** — `.env`, API keys, passwords. Once pushed, they're in the repo's history forever (deleting in a later commit doesn't remove them). Add `.env*` to `.gitignore` from the very first commit, and if you slip up, ROTATE the key immediately. (2) **Committing `node_modules/` or `.next/`** — bloats the repo, slows clones, and serves no purpose. They're in the default Next.js `.gitignore` — don't remove them. (3) **Squashing or force-pushing to main** — destroys history other people have already pulled. Force-push only on your own feature branches before review. (4) **Vague commit messages** — `"fix"`, `"updates"`, `"asdf"`. Future-you (and your reviewer) needs to know WHAT changed and ideally WHY. Aim for a sentence. (5) **Branching from an outdated main** — pull main, THEN branch. If you forget, you'll merge stale code and create avoidable conflicts. (6) **Ignoring CI failures** — that red X on your PR means tests are failing. Don't merge through it. Fix the failure first, then merge — that's the entire point of CI.

💡 Going deeper: the professional Git subtrack

This lesson covers the Git you use every day on a web project. When you are ready for the version of Git that working engineers are expected to know (what commits, trees, and blobs actually are; branching strategies like trunk-based development; interactive rebase to clean up history; protected branches and CODEOWNERS; multi-job GitHub Actions; and monorepos with Turborepo), work through the Software Engineering > Git and GitHub (Professional Level) subtrack. The same Git skills apply on every track where you write code.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Network Fundamentals for Developers
Back to Web Development
HTML Fundamentals→