The Basic Git Workflow

We already know that Git keeps track of project history and have seen how to create or clone a repository. Now we can move on to the most important Git workflow you will use in everyday development: change files → stage the changes → create a commit.

One of the first confusing ideas for beginners is that editing a file does not automatically make it part of the next commit. Git has an extra step in between called the staging area.

A simple way to picture the workflow is:

The working directory is where you actually edit your files. If you open a project in VS Code and change index.html, app.js, or README.md, those changes are happening in your working directory.

When you decide that certain changes should be included in your next commit, you use git add to place them in the staging area. You can think of the staging area as a preparation list for your next commit. A staged change is not yet permanently recorded in Git history. It simply means, “I want this change to be included in my next commit.”

Finally, git commit creates the actual commit and saves it in your local repository, which is the Git history stored on your computer.

Suppose you changed three files:

index.html
style.css
README.md

If you only want the website changes in your next commit, you can stage just the first two files:

git add index.html style.css

Then create the commit:

git commit

That commit will include the changes to index.html and style.css, while the change to README.md remains in your working directory.

This is one of the main reasons the staging area exists: it lets you choose exactly which changes belong together in a commit.

You do not need to understand Git's internal implementation at this point. The important workflow is simply:

1. Edit files.
2. Use git add to prepare selected changes.
3. Use git commit to create a commit.

Why Are Add and Commit Separate?

Imagine that you fix a login bug and also update the README on the same day. Those are two different kinds of work, so combining everything into one large commit would make the history harder to understand.

A cleaner history might look like this:

Commit 1: Fix login bug
Commit 2: Update README

The staging area gives you control over what goes into each commit. You can stage the login-related files first, commit them, and then stage the README separately.

This makes your Git history easier to read and easier for other developers to review.

git status Is Your Best Helper

Throughout this workflow, one command is especially useful:

git status

It tells you which files have changed, which changes are staged, and which files are not yet being tracked by Git.

A good beginner habit is simple: whenever you are unsure about the current state of your repository, run git status.