Basic Workflow

Here’s the thing about Git that trips up newcomers: it doesn’t automatically save everything you do. Unlike Google Docs or a word processor that auto-saves every keystroke, Git waits for you to explicitly say “Yes, save this version.”

This might seem inconvenient at first, but it’s actually powerful. It means you control when to snapshot your work and what to include in that snapshot. You’re the director, deciding which scenes make it into the final cut.

Want to understand the fundamentals? Check out How Git Works for a deep dive into Git’s snapshot model, and Understanding the Staging Area to learn why Git has this three-step workflow.

This section walks through the fundamental workflow you’ll use dozens of times a day.

The Three-Step Dance: Status, Stage, Commit

Think of working with Git as a three-step dance:

Check what’s changed (git status)
Choose what to save (git add)
Create the snapshot (git commit)

This pattern becomes muscle memory quickly. Here’s each step broken down.

Step 1: Check What’s Changed

Before doing anything, ask Git: “What’s different since my last commit?”

git status

What you’ll see: Git tells you which files are:

Modified - You changed them since the last commit
Untracked - New files Git doesn’t know about yet
Staged - Files ready to be committed
Deleted - Files you’ve removed

Example output:

On branch main
Changes not staged for commit:
  modified:   src/app.js

Untracked files:
  src/new-feature.js

Pro Tip: Run git status constantly. Like, all the time. Before staging, before committing, before switching branches - make it your habit. It’s your situational awareness tool, showing you exactly where you stand.

Think of git status as asking “Where am I?” before making any move. It prevents surprises and keeps you oriented.

Step 2: Stage Your Changes

Now comes a key concept: the staging area. This is Git’s unique feature - an intermediate step between “I changed this file” and “save this version.”

Why staging exists

Imagine you spent the morning fixing a bug and adding a new feature. You want two separate commits:

“Fix: Resolved payment processing error”
“Feature: Added user profile page”

The staging area lets you prepare exactly which changes go into each commit, even if they’re mixed across the same files. You’re composing your commits deliberately, not dumping everything in at once.

Adding files to staging

# Stage a specific file
git add <file>

# Stage everything in current directory and subdirectories
git add .

# Stage ALL changes everywhere (additions, modifications, deletions)
git add -A

# Stage only modifications and deletions (not new files)
git add -u

# Stage changes interactively (piece by piece)
git add -p

Understanding the options

git add <file> - The surgical approach. Use this when you want precise control over what’s staged.

# Stage just the files related to your bugfix
git add src/payment.js
git add tests/payment.test.js

git add . - Stages everything from your current directory downward. Useful when working in a specific part of your project.

# Working in the frontend folder
cd frontend/
git add .  # Only stages frontend changes

git add -A - The “stage everything” approach. Use carefully.

git add -A  # Stages all changes in the entire repository

Warning: git add -A is convenient but dangerous if you’re not paying attention. You might accidentally stage:

Temporary files you meant to ignore
Debug logs with sensitive data
Build artifacts that don’t belong in version control
Half-finished work you’re not ready to commit

Always run git status before git add -A to see exactly what you’re about to stage.

git add -u - Stages updates to files Git already knows about, but ignores brand new files.

# You modified existing files and created new ones
# This only stages the modifications, not the new files
git add -u

git add -p - The power user’s tool. Git shows you each change and asks “Stage this?” You can say yes, no, or even split the change into smaller pieces.

The Everyday Git section explores interactive staging in detail. For now, just know it exists.

Step 3: Commit Your Snapshot

You’ve staged your changes. Now it’s time to save them permanently with a commit.

# Commit with a message
git commit -m "Fix payment processing timeout error"

# Stage modified files AND commit in one step
git commit -am "Update user authentication flow"

The anatomy of a good commit message

Your commit message is a note to your future self (and teammates) explaining why this change exists. Write it like you’re explaining to someone who’s about to review your code.

Good commit messages:

git commit -m "Fix: Prevent null pointer error in user logout"
git commit -m "Add error handling for failed API requests"
git commit -m "Refactor database connection pooling for better performance"

Poor commit messages:

git commit -m "fixed stuff"
git commit -m "changes"
git commit -m "asdf"
git commit -m "I hate this bug"

Future you, debugging at 2 AM, will be grateful for descriptive commit messages. Trust me on this.

The shortcut: `git commit -am`

The -a flag automatically stages all modified tracked files before committing. It’s convenient but has a gotcha: it only works on files Git already knows about. New files still need explicit git add.

# This works: Stages and commits modified files
git commit -am "Update navigation menu styling"

# This WON'T stage new files - you still need git add for those

When to use -am: Quick commits when you’re confident all your changes belong together and you don’t have new files.

When NOT to use -am: When you need granular control, have multiple logical changes mixed together, or have new files to add.

Putting It All Together: A Real Workflow

Here’s what your typical workflow looks like:

# Start your day: Check where you are
git status

# Make some changes to your code...
# Edit src/homepage.js
# Create src/newsletter-signup.js

# Check what changed
git status
# Shows: homepage.js modified, newsletter-signup.js untracked

# Stage the changes you want to commit
git add src/homepage.js
git add src/newsletter-signup.js

# Double-check what's staged
git status
# Shows: Both files ready to commit

# Create the commit
git commit -m "Add newsletter signup form to homepage"

# Verify it worked
git status
# Shows: Working directory clean

Building Your Commits Thoughtfully

Here’s a mindset shift that helps: Think of commits as telling a story of how your project evolved. Each commit is a chapter that should make sense on its own.

Good commit practice:

One logical change per commit
Related files grouped together
Clear message explaining the “why”
Code that works (doesn’t break the build)

Example of good commit grouping:

# Commit 1: The bugfix
git add src/authentication.js tests/auth.test.js
git commit -m "Fix: Prevent session timeout during file uploads"

# Commit 2: The feature
git add src/profile-page.js src/avatar-upload.js
git commit -m "Add user profile customization with avatar upload"

# Commit 3: The documentation
git add README.md docs/user-profile.md
git commit -m "Document new profile customization features"

Each commit is focused, testable, and tells a clear story.

Common Mistakes to Avoid

Mistake 1: Committing too much at once

Don’t let changes pile up. If you’ve been coding for hours, you probably have multiple logical changes mixed together. Break them into separate commits.

Mistake 2: Committing too little too often

The opposite problem: committing every tiny typo fix. Find a balance - commit when you’ve completed a logical unit of work.

Mistake 3: Vague commit messages

“Updated files” tells you nothing. “Fixed user login to handle special characters in passwords” tells you everything.

Mistake 4: Not checking status before staging

Always know what you’re about to stage. Surprises in commits are rarely good surprises.

What About the Staging Area?

You might be wondering: “Why can’t I just go straight from editing to committing? Why this staging step?”

Great question! The staging area is what makes Git powerful and flexible. It’s your workbench where you prepare commits before they become permanent. You can:

Mix and match changes from different files
Commit only part of a file’s changes (with git add -p)
Review exactly what’s going into the commit
Catch mistakes before they’re permanent

At first, the staging area might feel like extra ceremony. But once you’re working on complex features with multiple moving parts, you’ll appreciate having this middle ground.

Want to understand the staging area deeply? We explore its architecture and power in the Concepts section. For now, just use it - the “why” will click as you work with it.

Your New Habit Loop

Here’s the rhythm you’re building:

Make changes (edit your code)
git status (see what changed)
git add (choose what to save)
git status (verify what’s staged)
git commit -m (save the snapshot)
Repeat

This becomes second nature quickly. You’ll find yourself running git status reflexively, staging changes thoughtfully, and writing clear commit messages without thinking about it.

Welcome to the Git workflow. You’ve just learned the commands you’ll use more than any others. The rest of Git builds on this foundation - everything else is variations and extensions of status, add, commit.

Practice this until it feels natural, because it’s about to become your most-used skill.

Initialize & Clone Ignoring Files