git init, add, commit

To start tracking a project, run git init inside its folder — this creates a hidden .git folder where Git will store the entire history. You only ever do this once per project. From then on, saving progress is a two-step habit: git add tells Git which changed files to include in the next snapshot, and git commit actually takes that snapshot.

$ git init
Initialized empty Git repository in /my-project/.git/

git add takes a file name, or a . to mean "everything that changed". This moves those changes into what's called the staging area — a holding zone for exactly what will go into the next commit. Splitting it into two steps (add, then commit) lets you group related changes together and leave unrelated ones out, instead of every commit having to include absolutely everything you touched.

$ git add index.js
$ git add .

Once changes are staged, git commit -m "message" saves them as a permanent point in the project's history, with the text after -m as the description of what changed. Good commit messages are short and specific — "fix login button not responding" is far more useful later than "stuff" or "updates".

$ git commit -m "Add the login form"

The command ____ moves changed files into the staging area, ready to be committed.

You need to run git init every single time you make a new commit.

What does the -m flag do on the git commit command?