Classroom Public page

Week 10: Git Fundamentals

974 words

Version control. Git tracks changes to files over time, records who made each change and why, and lets you undo mistakes or collaborate without stepping on each other. Every professional software project uses it.

Theme

Git is a program that watches a directory and records snapshots of its contents every time you ask. Each snapshot is a "commit." You can go back to any prior commit; you can work on two different versions simultaneously ("branches"); you can push your commits to a shared server so others can see and build on them.

This week you create a Git repository, make several commits, push to a remote, and deliberately create and resolve a merge conflict. By the end you have the muscle memory for the operations you will use hundreds of times in your career.

Reading list (~1 hour)

  1. Pro Git, Chapter 1 at https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control: what version control is and why it exists
  2. Pro Git, Chapter 2 ("Git Basics"): the fundamental workflow
  3. Optional: https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ (Julia Evans): plain-English explanation of Git's confusing terms

Lecture outline (~2 hours)

Section 1: What Git tracks

  • Git tracks a directory (a "repository") and the files inside it
  • It does NOT automatically track changes; you tell it when to take a snapshot with git add + git commit
  • A commit records: the exact state of every tracked file; a timestamp; your name and email; a message you write describing the change; a reference to the previous commit
  • The chain of commits is the "history"; every change is auditable

Section 2: The three areas

Understanding these three areas explains most Git confusion:

  1. Working directory: your files as you see them on disk. Changes here are not tracked until you stage them.
  2. Staging area (index): files you have prepared for the next commit with git add. You can stage some changes and leave others out.
  3. Repository (.git directory): the committed snapshots. Once committed, a change is in the permanent history.

Workflow: edit files (working directory) -> git add file (stage) -> git commit -m "message" (commit to history).

Section 3: Core commands

Command What it does
git init Initialize a new repository in the current directory
git clone url Clone a remote repository to a local directory
git status Show which files are changed, staged, or untracked
git add file Stage a file for the next commit
git add . Stage all changes in the current directory (use with caution)
git commit -m "msg" Commit staged changes with a message
git log Show commit history
git log --oneline Compact commit history (one line per commit)
git diff Show unstaged changes
git diff --staged Show staged changes not yet committed
git push origin main Push local commits to the remote branch main
git pull Fetch + merge remote commits into the current branch
git show <hash> Show the details of a specific commit

Section 4: Remotes

  • A remote is a URL pointing to a copy of the repository, usually on a server (GitHub, GitLab, Bitbucket, or self-hosted)
  • git remote -v: list remotes
  • git remote add origin url: add a remote named "origin"
  • The name "origin" is a convention, not a requirement; it is the standard name for the main remote

Section 5: Branches

  • A branch is a named pointer to a specific commit
  • git branch name: create a branch
  • git switch name (or git checkout name): switch to a branch
  • git switch -c name: create and switch in one step
  • git merge other-branch: merge the commits from other-branch into the current branch
  • The main (or master) branch is the conventional default; new work typically happens on feature branches, then merges to main

Section 6: Merge conflicts

  • A conflict occurs when two commits changed the same line of the same file in different ways
  • Git marks the conflict with special markers:
    <<<<<<< HEAD
version from current branch
=======
version from incoming branch
>>>>>>> other-branch
  • Resolution: manually edit the file to combine or choose one version; remove the markers; git add the resolved file; git commit
  • This is a normal part of collaboration, not a sign of error

Section 7: .gitignore

  • git add . would stage everything, including files you never want in version control: compiled binaries, .pyc files, secret credentials, large data files
  • .gitignore: a file in the repository root listing patterns of files Git should ignore
  • Common entries: __pycache__/, *.pyc, .env, *.log, node_modules/
  • GitHub and GitLab both maintain standard .gitignore templates for common project types

Labs (~90 minutes)

Lab 10.1: First Git Repo (labs/lab-10-1-git-first-repo.md)

  • Initialize a repo; commit 3 files; push to a remote (a free GitHub or GitLab account)
  • Use git log --oneline to verify the 3 commits exist
  • Artifact: the remote repo URL committed to a README.md in the same repo

Lab 10.2: Merge Conflict (labs/lab-10-2-merge-conflict.md)

  • Create two branches; modify the same line of a file on each branch; merge; resolve the conflict
  • Artifact: the resolved file and a 3-sentence explanation of what you chose and why

Independent practice (~4 hours)

  1. Set up SSH key authentication to your GitHub or GitLab account; push over SSH instead of HTTPS
  2. Use git log --graph --oneline --all to visualize the branch structure after the week 10.2 lab
  3. Explore git stash: make a change, stash it, observe the working directory is clean, then pop the stash
  4. Read the .gitignore entry in the Pro Git book and create a .gitignore for a Python project
  5. Practice: break a commit into two using git reset HEAD~1 --soft (unstage the last commit's changes, re-stage selectively, commit twice). Note what happened in your Toolchain Diary.

Reflection prompts (~30 minutes)

  1. The staging area lets you include some changes in a commit and exclude others. Give a real scenario where this would be useful.
  2. A merge conflict is when two people changed the same line. What is the process for deciding which version wins? Who should make that decision?
  3. .gitignore keeps secrets out of the repo. What happens if a developer commits a .env file containing an API key and then removes it in the next commit? Is the key still accessible?
  4. Every commit message is a message to your future self. What makes a good commit message? What makes a bad one?
  5. Git gives you a complete history of every change. From a security perspective, what are the benefits and risks of keeping that history?

What comes next

Week 11 is networking basics: IP addresses, ports, DNS, ping, traceroute, and curl. You will see the network as a sequence of hops and a set of protocols, not as a magic connection.