Understanding the Git Workflow and Commands

If you’ve spent any time working on computers, you have probably used manual version control. It usually looks like this:

website_v1 website_v2_final website_v2_final_FOR_REAL website_v2_final_USE_THIS_ONE

It’s a universal rite of passage. You do this because you are afraid to delete working code, but you need to try something new. The problem is that a week later, you have absolutely no idea what the difference is between final and final_FOR_REAL.

Git exists to solve this problem.

At its core, Git is a Distributed Version Control System (VCS). "Version control" means it tracks changes to your files over time, allowing you to rewind to previous states, see exactly what changed, and understand why. "Distributed" means there is no single central server holding your project's history—when you download a Git repository, you download the entire history of the project directly to your local machine.

Read my blog about Version Control to learn more here.

Learning Git can feel like learning a cryptic new language. But if you learn the fundamental workflow rather than just memorizing commands, it stops being scary and starts becoming the most reliable tool in your developer workflow.

Here is the beginner’s guide to thinking in Git.

The Three States of Git

The biggest mistake beginners make is thinking that saving a file automatically saves it to Git. It doesn't.

To use Git effectively, you have to understand its core mental model. Git manages your files in three distinct stages:

Working Directory  -->  Staging Area  -->  Repository
   (Your Desk)         (The Box)         (The Vault)

1. Working Directory: This is what you see on your computer. It’s the actual files you are currently editing in your code editor.

2. Staging Area: A holding area. When you finish a chunk of work, you "stage" the files. Think of this as putting items into a shipping box. You haven't mailed the box yet; you are just packing it.

3. Repository: Your project's history. When you are ready, you "commit" your staged files. This seals the box, slaps a label on it, and puts it in the vault.

Why have a staging area? Why not just save straight to the repository? Because development is messy. You might spend an hour tweaking CSS, fixing a JavaScript bug, and rewriting an HTML header. The staging area lets you group those changes logically. You can stage and commit the CSS, then stage and commit the HTML, keeping your project history organized.

Building the Workflow: Essential Commands

Let’s step through a real workflow from scratch to see how the terminology and commands connect.

1. git init: Creating the Repository

First, create a new folder for your project and open your terminal. To tell Git to start tracking this folder, you run one command:

git init

This creates a hidden .git folder inside your project. Your project is now a repository (or "repo"). It is an empty vault waiting for files.

Learn more about the git folder here.

2. git status: The Developer's Map

Let’s create a simple file, index.html. After making it, run:

git status

If you only memorize one Git command, make it git status. It tells you exactly what state your files are in. Right now, it will tell you that index.html is untracked. This means the file is in your Working Directory, but Git isn't watching it yet.

3. git add: Packing the Box

To tell Git to track the file and prepare it for saving, we need to move it to the Staging Area.

git add index.html

If you run git status again, the text will turn green. It will say "Changes to be committed". You have successfully placed index.html into the staging area.

(Note: If you want to stage every changed file in your folder at once, you can use git add .)

4. git commit: Sealing the Deal

Now that our file is staged, we want to save a permanent snapshot of it into our repository. We do this by creating a commit.

git commit -m "Add initial homepage structure"

A commit requires a message, passed via the -m flag. This message is the label on your shipping box. It should describe what you changed and why.

A commit is the fundamental unit of Git. It is a permanent snapshot of your project at a specific moment in time.

5. git log: Reading the History

If you want to see the snapshots you've saved, you view the commit history.

git log

This outputs a list of your commits, showing who made them, when they were made, the commit message, and a long alphanumeric string (the commit hash) that acts as the unique ID for that snapshot.

commit 7f8a9b2c1e4d5f6g7h8i9j0k1l2m3n4o5p6q7r8s
Author: Dev Cohort <dev@example.com>
Date:   Sat May 9 18:11:00 2026 +0530

    Add initial homepage structure

Parallel Timelines: Branches and HEAD

Eventually, you will want to build a new feature without breaking your working code. This is where branches come in.

A branch is exactly what it sounds like: an independent line of development. When you initialize a repository, Git gives you a default branch, usually called main.

Imagine you want to test out a dark mode for your website. Instead of editing your stable main code, you create a branch:

git branch dark-mode

Then, you switch to that branch:

git switch dark-mode

Now, any commits you make are isolated to the dark-mode timeline. Your main timeline remains untouched.

How does Git know which branch you are currently looking at? It uses a special pointer called HEAD. HEAD is essentially Git's "You Are Here" marker on the map. When you run git switch, Git moves HEAD to the new branch, and updates the files in your working directory to match.

          [main]
            |
(Commit A)---(Commit B)
                  \
                   (Commit C) <--- [dark-mode]  <--- HEAD

Conclusion

Git is not a magic save button. It is a detailed workflow.

Every time you write code, you are moving through the same cycle:

1. Edit files in your Working Directory.

2. Run git status to see what changed.

3. Use git add to move related changes to the Staging Area.

4. Use git commit to save those staged changes permanently to the Repository.

Don't panic when you make a mistake, and don't try to memorize fifty commands. Understand the difference between your working directory, your staging area, and your repository. Once that mental model clicks in place, the commands are just formalities