The Git Workflow

Alright, now that Git’s set up in your JavaScript project, it’s time to understand how it actually works behind the scenes. Git isn’t magic—it just feels like it once you get the hang of its workflow.

Think of it like this: Git is like a well-organized filing system for your code. But instead of tossing papers into random drawers (like I used to), you have a clear process: Working Directory → Staging Area → Repository. Get this flow down, and Git will stop feeling like that weird command-line thing you only half understand.

Working Directory, Staging Area, and Repository

Here’s the deal. Git doesn’t save your changes instantly. You work in three “zones,” and knowing how they interact is key:

  • Working Directory: This is where you live. You’re coding, editing, testing—basically doing your developer thing.
  • Staging Area: Before you make anything official, you “stage” your changes with git add. This is like saying, “Hey Git, I want to save this part.”
  • Repository: Once you’re happy, git commit locks it into your project's history—forever. This is your version-controlled archive.

A friend once described it like cooking: your kitchen is the working directory, the plate is your staging area, and the photo you post on Instagram is the repository. I mean, kind of a weird metaphor, but it stuck.

Adding and Committing Changes

Okay, so you made a few changes to your code. Does Git know about them? Nope. Not until you tell it.

Start with:

bash
1
          git status

This shows you what’s changed. It’s like a real-time health check for your repo.

To stage a specific file:

bash
1
          git add app.js

Or just go wild and add everything:

bash
1
          git add .

Once staged, it's time to commit. That’s the moment you say, “Yes, save this forever.”

bash
1
          git commit -m "Fix login bug and update UI"

Tip: Be clear in your commit messages. No more "updated stuff" or "final version". I once wrote "fix", and two months later, had no clue what I fixed. Rookie move.

Viewing Commit History

This is where Git shines. Want to see what you did last Tuesday at 3 AM? No problem.

bash
1
          git log

You’ll see all your commits, including dates, messages, and who did what (helpful when your future self blames past you).

Too much info? Clean it up:

bash
1
          git log --oneline

Now you’ve got a sleek history of your project’s evolution. It’s like a developer time machine, minus the flux capacitor.

Final Thoughts and What’s Next

Understanding this workflow is foundational. Every Git command builds on these ideas. And once you get it, using Git becomes muscle memory.

In the next lesson → Writing Commit Messages, we’ll dive into how to write great commit messages—like, actually helpful ones that your teammates (or future self) will thank you for.

And after that? We’re going even deeper in this chapter on Working Locally with Git, where you’ll level up your version control skills and really start feeling like a Git pro.

Oh, and if you want to nerd out a bit more, Atlassian has a solid Git workflow guide worth checking out.

See you in the next one.