Lesson Completion
Back to course

The Basic Git Workflow

Beginner
12 minutes4.8Git

The Hook (The "Byte-Sized" Intro)

Every professional developer runs the same three commands hundreds of times a day: status, add, commit. It's the heartbeat of Git — edit, stage, commit, repeat. Master this loop, and you can version-control anything from a weekend side project to a million-line codebase. The rhythm never changes.

📖 What is The Basic Git Workflow?

The basic Git workflow is the three-step loop you'll use on every project, every day. It separates editing from saving by introducing a staging area — a place to prepare your changes before committing them permanently.

Conceptual Clarity

The workflow has 3 zones and 3 transitions:

  1. Working Tree → You edit, create, and delete files freely
  2. Staging Area → You use git add to select which changes go into the next commit
  3. Repository → You use git commit to save a permanent snapshot

The magic is in step 2 — the staging area. It lets you:

  • Commit part of your changes (not everything at once)
  • Group related changes into one commit
  • Leave unfinished work out of the commit

Real-Life Analogy

Think of preparing a meal:

  1. Working tree = Your messy kitchen counter with all the ingredients out
  2. Staging area (git add) = The plated dish — only the items you've chosen to serve
  3. Commit = Putting the plate on the table with a label: "Dinner — Feb 13"

You can have a mess on the counter, but only the plated dish gets served. Git works the same way.

Visual Architecture

flowchart LR WT["📂 Working Tree<br/>(edit freely)"] -->|"git add"| SA["📋 Staging Area<br/>(curate changes)"] SA -->|"git commit"| REPO["💾 Repository<br/>(permanent snapshot)"] REPO -->|"git log"| HISTORY["📚 History Timeline"] STATUS["🔍 git status"] -.->|"shows state of"| WT STATUS -.->|"shows state of"| SA style WT fill:#1a1a2e,stroke:#e94560,color:#e94560 style SA fill:#0f3460,stroke:#ffd700,color:#ffd700 style REPO fill:#0f3460,stroke:#53d8fb,color:#53d8fb style HISTORY fill:#0f3460,stroke:#53d8fb,color:#53d8fb style STATUS fill:#1a1a2e,stroke:#ffd700,color:#ffd700

Why It Matters

  • Clean commits: The staging area prevents giant, messy commits with unrelated changes.
  • Undo granularity: Small, focused commits are easy to revert. Massive commits are not.
  • Code review: Reviewers love small, well-labeled commits — each one tells a clear story.
  • Debugging: git bisect can pinpoint bugs faster when each commit is small and atomic.

Code

bash
# ─── The full workflow, step by step ─── # Step 0: Always start by checking where you are git status # Output: # On branch main # nothing to commit, working tree clean # Step 1: Edit some files echo "Hello World" > app.js echo "body { margin: 0; }" > style.css # Step 2: Check what changed git status # Output: # Untracked files: # app.js # style.css # Step 3: Stage specific files (not everything!) git add app.js # Only app.js is staged; style.css stays in the working tree # Step 4: Verify what's staged vs unstaged git status # Output: # Changes to be committed: # new file: app.js # Untracked files: # style.css # Step 5: Commit with a descriptive message git commit -m "Add main application file" # Step 6: Stage and commit the second file separately git add style.css git commit -m "Add base stylesheet" # Step 7: View your clean history git log --oneline # Output: # b2c3d4e (HEAD -> main) Add base stylesheet # a1b2c3d Add main application file

Common git add Variations

CommandWhat It Does
git add file.txtStage one specific file
git add .Stage all changes in current directory
git add -AStage all changes in entire repo
git add -pStage changes interactively, hunk by hunk
git add *.jsStage all JavaScript files
bash
# Interactive staging — choose which parts of a file to stage git add -p # Git shows each changed "hunk" and asks: # Stage this hunk [y,n,q,a,d,s,e,?]? # y = yes, n = no, s = split into smaller hunks

Writing Good Commit Messages

bash
# ❌ Bad commit messages git commit -m "fix" git commit -m "stuff" git commit -m "update" # ✅ Good commit messages git commit -m "Fix navbar overflow on mobile screens" git commit -m "Add user authentication middleware" git commit -m "Remove deprecated API endpoint v1/users"

Rule of thumb: A commit message should complete the sentence: "If applied, this commit will _____."

Key Takeaways

  • The workflow is edit → stage → commit → repeat — this loops forever.
  • git status is your compass — run it constantly to stay oriented.
  • The staging area lets you craft clean, focused commits from messy work.
  • Use git add -p for surgical precision when staging parts of a file.
  • Write commit messages that explain why, not just what.

Interview Prep

  • Q: What is the purpose of the staging area? A: The staging area is an intermediate layer that lets you selectively choose which changes go into the next commit. This enables clean, atomic commits even when you've changed many files.

  • Q: What is the difference between git add . and git add -A? A: git add . stages new and modified files in the current directory and below. git add -A stages everything (including deletions) across the entire repository, regardless of current directory.

  • Q: What makes a good commit message? A: A good commit message is short (50 chars or less for the subject), imperative ("Add feature" not "Added feature"), and explains the intent of the change. It should complete the sentence "If applied, this commit will _____."

Topics Covered

Git FundamentalsGit Introduction

Tags

#git#workflow#status#commit

Last Updated

2026-02-12