Everyday Work – Add, Commit, Status, Diff…

Once your repository exists, Git becomes part of your daily rhythm. Think of it like brushing your teeth—simple actions, repeated often, that preserve the health of your codebase. In this chapter, we’ll dive into the bread and butter: adding, committing, checking status, and examining diffs. Mastering these is like mastering scales before jazz improvisation; once you’re fluent, everything else flows.

The Daily Loop

Every developer repeats the same cycle dozens of times a day:

Edit files in working directory.
Stage with git add.
Commit with git commit.
Inspect with git status or git diff.

Visualization of the cycle:

flowchart TD
  WD[Working Directory] -->|git add| Index[Staging Area]
  Index -->|git commit| Repo[Repository]
  Repo -->|inspect| Status[git status / git diff]

This loop is the heartbeat of Git. Once you internalize it, you move without thinking.

Editing and Checking Status

Suppose you modify app.py. Git immediately knows the file is changed.

git status

Output:

On branch main
Changes not staged for commit:
  modified: app.py

git status is your dashboard. It shows which files are staged, which are not, and what Git thinks is happening.

Staging with Add

git add moves changes into the staging area. This allows you to curate what goes into a commit. You don’t have to commit all changes at once.

git add app.py

Now git status will show:

Changes to be committed:
  modified: app.py

Visualization:

flowchart LR
  WD[Working Dir: app.py*] -->|git add| Index[Staging: app.py]
  Index -->|ready| Commit[Commit]

Committing Changes

Commit the staged snapshot:

git commit -m "fix: correct greeting message"

This creates a new commit node in the history DAG. Each commit is immutable, identified by SHA-1.

gitGraph
  commit id: "Initial"
  commit id: "Fix greeting"

Diffing Before Committing

To see what you changed, run:

git diff

This shows line-by-line differences in unstaged files. To see staged diffs:

git diff --cached

Example output:

-print("Hello, Git!")
+print("Hello, World!")

Diffs are surgical tools. They help you review before committing, preventing “oops” commits.

Inspecting History

After a few commits, use:

git log --oneline --graph

Example output:

* 1a2b3c4 fix: correct greeting message
* 5d6e7f8 feat: add app.py
* 9a0b1c2 chore: add README.md

This is the narrative of your work. Each line is a breadcrumb.

Everyday Example

Solo Developer

You edit three files but only want to commit two logically grouped changes.

git add index.html style.css
git commit -m "feat: redesign homepage layout"

Later you commit the third file separately.

This creates logical commits instead of chaotic dumps.

Team Developer

On a team, staging helps you write clean commits reviewers can understand. Instead of mixing bug fixes with new features, you separate them. This discipline makes collaboration smoother.

Visualization of Logical Grouping

flowchart TD
  A[Unstaged: index.html, style.css, app.js]
  A -->|add index.html, style.css| Staging[Staging Area]
  Staging --> Commit1[Commit 1: Homepage redesign]
  A -->|add app.js| Staging2[Staging Area]
  Staging2 --> Commit2[Commit 2: App logic fix]

Think Different Mindset

Git isn’t just about saving code—it’s about writing history that makes sense. Staging and committing are acts of storytelling. Each commit is a sentence. Together, they form paragraphs, chapters, entire novels of development. Sloppy commits make messy stories. Curated commits make elegant narratives. Think not “what did I change?” but “what story am I telling?”

The commands in this chapter—add, commit, status, diff—are deceptively simple. Yet they are the foundation of daily Git work. Master these and you can work fearlessly, knowing exactly where you are, what you’ve done, and what comes next. In the next chapter, we’ll handle .gitignore and learn how to keep noise out of history so the story stays clear.