Stage 1 - Introduction to Git and Version Control

Start with one concrete problem: a startup team builds a tiny task-service and one developer accidentally rewrites the README while another edits task-service.js. Within minutes nobody remembers which change caused a bug. This is where Git becomes a practical answer.

Git is not “just save on disk.” It is a system for recording named, inspectable milestones of a project. Each commit captures what changed, why it changed (-m message), and who made it. This is the core difference from copy-pasted folders like task-service-final, task-service-final-2, and task-service-final-final.

The first distinction to internalize is this: Git and file sync are different layers. File sync services keep devices in sync, but they do not answer “which logical fix was added for this bug.” Git answers by grouping related edits into one point in history.

For example, in a coding incident you might want three precise answers:

• Which exact command list changed api/task.go?
• Who introduced the wrong default sort order?
• When did that behavior move from prototype to shared branch?

A version control system stores exactly these answers. You can compare two commits, open one and confirm intent, and move backward if needed.

Git and GitHub are complementary

Git itself lives and works locally by default. It can track changes, branches, and history on your machine without needing a server. GitHub (or GitLab/Bitbucket) is a collaboration platform built around Git repositories.

For task-service, this means you can practice safely offline:

1. edit local files,
2. make history in small commits,
3. inspect and test before you ever push.

Later, GitHub becomes the shared room where teammates discuss and merge branches. So when someone says “Git is on GitHub,” you can correct them: “Git is local by design; GitHub is where we share Git repositories.”

First mental model for this course

We will treat the repository as an evolving story around one file-based sample project:

• README.md tracks requirements and examples.
• task-service.js holds business behavior.
• notes.txt captures learning experiments.

Every next stage will continue this same project history:

• Stage 2: create the repo and first commit;
• Stage 3: inspect changes with diff and separate partial work in staging;
• Stage 4: branch to add a feature;
• Stage 5: resolve conflict when two branches touch the same lines;
• Stage 6–7: sync with remote and review via PR;
• Stage 8–9: recover confidently and finish with workflow discipline.

This continuity is intentional so you can feel how one command choice changes downstream impact.

First setup for real work

Install Git (git --version should print a version). Then configure your identity once:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git config --global --list

Use the same email as your GitHub account if you want author attribution later.

You are ready for Stage 2 when you can explain those three layers in one minute, without examples copied from docs.