Lesson 3 of 7 in Basics
Staging and committing
Story: Pim's first rule of the archive: choose what goes on record, then record it.
A commit is a snapshot of your project: every file as it was at one moment, with a message that says what changed. Commits are the circles in the Live Graph.
Making a commit takes two steps, because git keeps your files in three places:
| Place | What it holds |
|---|---|
| The working tree | The files you see and edit. |
| The staging area, also called the index | The snapshot your next commit will hold. |
| The repository | Every commit, kept in the .git folder. |
Staging with git add
git add <path> copies a file, as it is right now, into the staging area. This is called staging the file. You can name several files at once, or a folder to stage everything in it.
git add . stages every change in the folder you're in and in the folders inside it. The . means "this folder".
Staging copies what's in the file. It doesn't keep a link to it. If you edit a file after staging it, the staging area still holds the earlier version, and git status lists the file twice: under Changes to be committed for the staged version, and under Changes not staged for commit for your newer edit. Run git add again to stage the newer version.
Committing with git commit -m
git commit -m "<message>" records what's staged as a new commit, and the branch you're on moves forward to it. Only staged changes go in. Anything you didn't stage stays in your working tree, ready for a later commit.
With nothing staged, git makes no commit. It shows the status instead, ending with a line such as nothing added to commit but untracked files present.
Write a short message that says what the commit does, such as Add opening hours or Fix a typo in the heading. By convention it reads like an instruction: "Add", not "Added".
Why two steps?
Staging lets you choose what goes in each commit. If you changed two unrelated things, stage and commit one of them, then the other. Small commits that are each about one thing make a history that's easy to read.
git status shows you all three places at once:
Changes to be committed: staged, so it goes into the next commit;Changes not staged for commit: changed since the last commit, but not staged;Untracked files: new files git isn't keeping yet.
Once everything is committed, it says nothing to commit, working tree clean.
| Command | What it does |
|---|---|
git add <path> |
Stages a file, or everything in a folder, as it is now. |
git add . |
Stages every change in this folder and the folders inside it. |
git commit -m "<message>" |
Records what's staged as a new commit on the branch you're on. |
New commands
git addgit commit -m
Explainer: Staging, then committing
Graph as text
project: your repo, you are here
- HEAD → main at 80c5a76 "Add an about page"
Branches and tags
- main at 80c5a76 "Add an about page"
Commits, newest first
- 80c5a76 "Add an about page"; parent a1a97c1; refs: HEAD → main
- a1a97c1 "Add opening hours"; parent a4b8d97
- a4b8d97 "Style the heading"; parent ab89288
- ab89288 "Add the home page"; parent 37d7cf7
- 37d7cf7 "Add a README"; no parent
Challenge 1 of 3
Story: Nothing counts until it's on record, Agent. Put both recipes on record.
This repository holds two recipes, pancakes.txt and soup.txt, and has no commits yet. Make its first commit, with both files in it.
Commands 0 of Par 2
Goal
- Met: HEAD is on branch main
- Not met yet: Branch main is at the goal's commit
- Not met yet: The history of main matches the goal
- Not met yet: main has one commit
- Not met yet: The commit has pancakes.txt
- Not met yet: The commit has soup.txt