Git Basics for Programmers: Repositories, Working Tree, and the Commit Mindset

Git’s Three Core Areas: Working Tree, Staging Area, Repository

Git tracks your project through three related “areas” that map directly to what you do while coding:

• Working tree (working directory): the files you edit in your editor. Changes here are just edits on disk.
• Staging area (index): a “proposal” of what the next commit will contain. You choose which changes to include.
• Repository (.git): the database of commits (history). A commit is a snapshot of tracked files at a point in time, plus metadata and a message.

Everyday loop: you edit files (working tree), select parts to include (staging area), then record a snapshot (commit) into the repository. The key mindset is that a commit should represent one logical change you can describe in a sentence.

Creating or Cloning a Repository

Create a new repository from an existing folder

Use this when you already have a project directory and want to start tracking it with Git.

cd path/to/project-folder git init

This creates a .git directory (the repository database). Your files remain where they are; Git just starts tracking.

Clone an existing repository

Use this when the project already exists elsewhere (for example, on a server) and you want a local copy with full history.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

git clone https://example.com/repo.git cd repo

Cloning gives you: the working tree files, the full repository history, and a configured remote named origin.

Reading State with git status

git status is your primary “what’s going on?” command. It tells you what is modified, what is staged, and what is untracked.

git status

Typical categories you’ll see:

• Untracked files: new files in the working tree that Git isn’t tracking yet.
• Changes not staged for commit: tracked files modified in the working tree but not added to the staging area.
• Changes to be committed: changes currently staged; these will go into the next commit.

Use the short form when you want a compact view:

git status -sb

This often shows branch info plus a concise list of file states.

Verifying Changes with git diff (Working Tree vs Staged)

Before staging or committing, verify what you actually changed. Git provides two key comparisons:

• Working tree vs staging area: what you changed but have not staged yet.
• Staging area vs last commit: what you have staged and are about to commit.

See unstaged changes

git diff

This shows differences between your working tree and the staging area (i.e., what is not staged yet).

See staged changes (what will be committed)

git diff --staged

This shows differences between the staging area and HEAD (the last commit on your current branch). Treat this as a “pre-commit review.”

Reviewing History with git log

git log lets you inspect commits already recorded in the repository. This is how you confirm what happened, when, and why.

Default log

git log

This shows full commit entries (hash, author, date, message). It’s useful but can be verbose.

Compact history with --oneline

git log --oneline

This shows each commit as a short hash plus the subject line. It’s ideal for quick scanning.

Visualize branching with --graph

git log --oneline --graph --decorate

--graph draws an ASCII graph of merges and branches. --decorate shows branch and tag names pointing at commits.

Making Focused Commits with git add and git commit

A focused commit contains one logical unit of work: one fix, one refactor, one feature slice, one documentation update. This makes history readable and makes it easier to revert or cherry-pick later.

Stage changes intentionally with git add

Staging is where you decide what the next commit means.

Stage an entire file

git add path/to/file

Use this when all changes in the file belong to the same logical change.

Stage all current changes (use carefully)

git add -A

This stages modifications, deletions, and new files. It’s fast, but it can accidentally include unrelated edits. Prefer explicit file paths or partial staging when you’re working on multiple things.

Partial staging with git add -p

When a file contains multiple unrelated edits, partial staging lets you split them into separate commits.

git add -p

Git will present “hunks” (chunks of changes) and ask what to do. Common choices:

• y: stage this hunk
• n: do not stage this hunk
• s: split the hunk into smaller hunks (useful when Git grouped too much)
• e: manually edit the hunk to stage only specific lines (advanced but powerful)
• q: quit; keep decisions made so far

Practical pattern: if you fixed a bug and also reformatted code, use git add -p to stage only the bug fix first, commit it, then stage the formatting and commit separately.

Commit the staged snapshot

Once staging reflects exactly what you want recorded, create a commit.

git commit -m "Subject line"

For commits that need explanation, write a proper message with a subject and body:

git commit

This opens your editor so you can write a multi-line message.

Commit Message Guidance: Subject, Body, Intent

A good commit message helps future-you (and teammates) understand why a change exists. Aim for clarity over cleverness.

Subject line

• Keep it short and specific.
• Describe what the commit does, not what you did.
• Examples: Fix null check in user lookup, Add retry to API client, Refactor parser into smaller functions

Body (optional but valuable)

Use the body when the change needs context. Good body content includes:

• Intent: what problem you’re solving and why.
• Approach: key design decisions or constraints.
• Behavioral changes: what changed for users or callers.

Example structure:

Fix null check in user lookup  The lookup could throw when the cache returned a missing entry. Add a guard and fall back to DB fetch. This prevents intermittent 500s on first request after deploy.

Commit small logical units

Use commits as building blocks. If you can’t describe the commit in one sentence, it may be too large or mixing concerns. Common ways to split work:

• Separate refactors from behavior changes.
• Separate formatting from functional changes.
• Commit tests alongside the behavior they validate, or commit tests first if they demonstrate the bug.
• Use partial staging to separate unrelated edits inside the same file.

Step-by-Step: A Repeatable Mini-Workflow

1) Edit

Make changes in your editor (working tree). Keep an eye on scope: try to work on one logical change at a time.

2) Review diff

git diff

Confirm the working tree contains only what you intend. If you see unrelated edits, either revert them or plan to split them into separate commits.

3) Stage intentionally

git add path/to/file

Or, to split changes:

git add -p

Then verify exactly what is staged:

git diff --staged

4) Commit

git commit

Write a clear subject line; add a body when intent or context matters.

5) Inspect history

git log --oneline --graph --decorate

Confirm the commit appears as expected and the message communicates the change.

Workflow checklist

• Edit
• Review diff
• Stage intentionally
• Commit
• Inspect history