ComputeSphereLearn
Console
Learning paths / Application foundations / Git essentials

Commits and history

Reading · 6 min · Module 5, lesson 2 of 642 min left in this module

Module 5 · Git essentialsLesson 2 of 6

Goal: Make small commits with clear messages, and read a project's history with git log.

Key idea

A commit is a saved snapshot of your project with a message saying what changed and why. Make each one small and about one thing, and the history becomes a record you can read, search and undo one step at a time.

If git commit asks who you are, go back to lesson 2.5.1 and set your name and email.

Three places a change lives

Git keeps your work in three places:

  1. Working folder: the files you edit. Git notices changes but records nothing yet.
  2. Staging area: the changes you've picked for the next commit.
  3. History: the commits, each pointing back to the one before.

Staging is what lets you commit one thing at a time. You fixed a bug and tidied a comment? Stage the fix, commit it, then commit the tidy-up separately.

git status                 # what changed, and what's staged
git add src/cart.js        # stage one file
git commit -m "Fix total when the cart is empty"

git add -A stages everything. It's quick, and it's how stray files and secrets end up in commits, so run git status first.

What makes a good commit

One change. If the message needs "and", it's probably two commits. A small commit is easy to review, and easy to undo without losing anything else.

Working code. Each commit should leave the project in a state that runs. Then any point in the history is a safe place to go back to.

A message that finishes the sentence "This commit will…":

  • fix becomes Fix total when the cart is empty
  • updates becomes Add due dates to tasks
  • wip stuff becomes Move price formatting into one function

Keep the first line under about 50 characters, in the imperative ("Add", not "Added"). If the why isn't obvious, add a blank line and a short paragraph under it.

Prefixes like feat: and fix:

Many teams start messages with a type: feat: add due dates to tasks, fix: total when the cart is empty. The convention is called Conventional Commits, and tools can build changelogs and version numbers from it. It's optional; follow whatever the project already does. Path 4 uses it with coding agents.

Read the history

git log --oneline

0d0c70a Make the greeting formal
cdb9ad0 Add greeting

Newest first: a short ID, then the first line of the message. The ID is how you name a commit in other commands, for example git show 0d0c70a to see exactly what it changed.

A history of clear, small commits answers "when did this break, and why?" in a minute. A history of fix and wip answers nothing.

Commit often, locally

Commits live on your machine until you share them (Module 7). Committing every time something works costs nothing, and gives you a point to come back to. Lesson 4.3.2 uses the same habit when an agent writes the code.

Check yourself

You fixed a login bug and renamed some variables in another file. What do you commit?
Which commit message is most useful six months later?