Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Version Control with Git  ›  Lesson

Git — Saving Snapshots

Git 14 minGit records a project as a chain of commits, and each commit is a snapshot of whatever you staged, with a message saying why.

Git — Saving Snapshots

You change the bookshop's order code on Friday, and on Monday checkout is broken. What exactly changed, and how do you get back to Friday morning? Without version control you are guessing. With Git, every saved step is a snapshot you can inspect, compare and return to.

The rule

Edit, stage, commit: each commit is a snapshot with a reason.

Git sees your project in three places:

  • Working directory: the files as they are on disk right now, including half-finished edits.
  • Staging area: the changes you have chosen for the next snapshot.
  • Repository: the permanent history of commits, stored in the hidden .git folder.

A commit records the staged state of the project, together with an author, a time, a message and a link to the commit before it. Each commit gets a unique id (a hash such as a1b2c3d), and together they form a chain you can walk back through.

git init                      # start tracking this folder
git status                    # what changed? what is staged?
git diff                      # show unstaged line changes
git add app.py                # stage one file
git commit -m "Return 404 for unknown book ids"
git log --oneline             # list the history, newest first

Staging exists so that one commit can hold one idea. If you fixed a bug and also reworded the README, stage and commit them separately; later, each change can be understood or undone on its own.

A good message says what changed and why in a short line: "Return 404 for unknown book ids" beats "fix stuff".

Some files must never be committed: secrets such as .env with the database password, and generated folders such as node_modules or __pycache__. List them in a .gitignore file:

.env
__pycache__/
node_modules/

The shortcut

Before every commit, run the status → diff → add → commit loop and ask: "Is everything I staged part of one idea, and nothing secret?"

Committing one fix cleanlyStep 1 of 4

  1. Status

    git status shows app.py and README.md modified, and a new untracked .env.

The trap: git add . stages everything, including secrets. Once a password is committed and shared, deleting the file later does not remove it from history. The only safe fix is to change the password.

Drills

Answer fast — trust the rule.

quick drill

You edited app.py but have not run git add. Where does the change live?

quick drill

Which command shows which files are modified, staged or untracked?

quick drill

Which is the most useful commit message?

quick drill

You committed .env with a real password and pushed it. You delete the file in a new commit. Is the password safe?

Remember

  • Edit, stage, commit: each commit is a snapshot with a reason.
  • Loop: status, diff, add one idea, commit with a clear message.
  • Secrets go in .gitignore before the first commit; a committed secret is a leaked secret.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainYour first careful commit

You have changed app.py and README.md in the bookshop repository, and a new .env file holds the database password. Describe the commands you would run to commit only the code change with a good message, and how you make sure .env is never committed.