Understanding the Git Workflow: Working Directory, Staging, Commit, and Push

Trevor Zabar — Sun, 23 Aug 2026 07:02:32 +0000

When I first started learning Git, commands such as git add, git commit, and git push seemed like separate steps that were easy to confuse. After practicing the Git workflow, I understood that each command moves changes to a different stage.
The complete workflow is:

Working Directory → Staging Area → Local Repository → Remote Repository

In this article, I will explain each stage using a simple website project.

What Is Git?

Git is a version control system that tracks changes in a project. It allows developers to save different versions of their work and review or restore earlier versions when necessary.

GitHub is an online platform where Git repositories can be stored and shared. Git works on your computer, while GitHub stores a copy of your repository online.

The important difference is that saving a commit locally does not automatically upload it to GitHub. You must push the commit separately.

The Working Directory

The working directory is the project folder on your computer. It contains the files you are currently creating or editing.

For example, imagine a website project with the following files:

my-website/
├── index.html
├── style.css
└── script.js

If I open index.html and change the heading, the change first exists in the working directory.

At this point, Git knows that the file has changed, but the change has not been prepared for saving yet. I can check the condition of the project with:

git status

Git may display something similar to:

Changes not staged for commit:
  modified:   index.html

This means that index.html has been changed, but it is not yet in the staging area.

The Staging Area

The staging area is where I select the changes that I want to include in my next commit.
To stage the modified file, I run:

git add index.html

Then I check the status again:

git status

The output may now look like this:

Changes to be committed:
  modified:   index.html

The file is now ready to be committed, but it has not been permanently saved in the project history yet.

I can stage more than one file by listing the filenames:

git add index.html style.css

I can also stage all changed files with:

git add .

Although git add . is convenient, I should check the files before committing. It may stage files that I did not intend to include.

Why the Staging Area Matters

The staging area gives me control over what goes into a commit.

For example, suppose I make changes to two files:

I add a completed navigation bar to index.html.
I experiment with unfinished styles in style.css.

If I want to commit only the navigation bar, I can run:

git add index.html
git commit -m "Add navigation bar"

The changes in style.css will remain in the working directory and will not be included in the commit.

This makes it possible to create focused commits. Each commit can describe one meaningful change instead of containing a mixture of unrelated work.

Creating a Commit

A commit is a saved record of staged changes. It represents a particular version of the project.

After staging index.html, I can create a commit with:

git commit -m "Update homepage heading"

The message after -m explains what the commit contains.

Good commit messages include:

git commit -m "Add contact form"
git commit -m "Fix mobile navigation"
git commit -m "Update project documentation"

Messages such as these are less useful:

git commit -m "Changes"
git commit -m "Update"
git commit -m "Work"

A good commit message should be short, clear, and specific.

When I commit changes, they are saved in my local Git repository. They are not yet available on GitHub.

To view the project history, I can run:

git log

For a shorter version of the history, I can use:

git log --oneline

A short log may look like this:

a31f9c2 Add contact form
e72b410 Update homepage heading

Each commit has a unique identifier that Git uses to distinguish it from other commits.

Pushing to GitHub

A remote repository is the online version of a Git repository. For many projects, the remote repository is hosted on GitHub.

After creating a commit locally, I can upload it with:

git push origin main

In this command:

origin is the name of the remote repository.
main is the branch I am pushing.

The difference between committing and pushing is important:

git commit = Save changes in the local repository
git push   = Upload local commits to the remote repository

Running git commit does not automatically update GitHub. I must run git push to send the commit to the remote repository.

A Complete Example

Suppose I want to add a welcome message to my website.

First, I check the current status:

git status

Next, I edit index.html:

<h1>Welcome to My Website</h1>

I can review the changes before staging them:

git diff

The git diff command shows changes that have not been staged.

Next, I stage the file:

git add index.html

I check the status again:

git status

Now I create a commit:

git commit -m "Add welcome message"

Finally, I push the commit to GitHub:

git push origin main

The complete workflow is:

git status
git diff
git add index.html
git commit -m "Add welcome message"
git push origin main

Each command has a separate purpose:

git status shows the current state of the project.
git diff shows the changes made to files.
git add selects changes for the next commit.
git commit saves the staged changes locally.
git push uploads the commit to GitHub.

Starting Git in a Project

If I am working on a new project, I first move into the project folder:

cd my-website

Then I initialize Git:

git init

This creates a hidden .git folder that stores the project's Git information and history.
I can check the project status with:

git status

If the project contains files that Git has not tracked before, they will appear as untracked files.

I can add all the files:

git add .

Then I create the first commit:

git commit -m "Initial project setup"

If I have already created an empty repository on GitHub, I can connect the local repository to it:

git remote add origin https://github.com/your-username/my-website.git

I can make sure the branch is called main:

git branch -M main

Then I push the project to GitHub:

git push -u origin main

The -u option links the local branch to the remote branch. After this first push, I can usually use:

git push

Reviewing Staged Changes

It is useful to review changes before committing them.

The following command shows changes that have not been staged:

git diff

After using git add, I can review the changes that are ready to be committed:

git diff --staged

The difference is:

git diff          = Shows unstaged changes
git diff --staged = Shows staged changes

This extra check can help me catch mistakes before they become part of the project history.

Removing a File from the Staging Area

Sometimes I may stage a file by mistake. I can remove it from the staging area without deleting it from my computer:

git restore --staged style.css

The changes in style.css will remain in the working directory, but they will not be included in the next commit.

This command only unstages the file. It does not delete the file or remove the changes I made.

Discarding Changes

If I decide that I do not want to keep changes in a file, I can restore it to the version from the latest commit:

git restore index.html

This removes the unstaged changes in index.html.

I should use this command carefully because the discarded changes may not be easy to recover. Before running it, I can check what will be removed with:

git diff

Common Beginner Mistakes

Forgetting to Stage Changes

If I run git commit before staging a file, Git may tell me that there is nothing to commit.

The correct sequence is:

git add index.html
git commit -m "Describe the change"

Thinking a Commit Is the Same as a Push

A commit saves changes locally. A push uploads those local commits to GitHub.

The commands are separate:

git commit -m "Save my changes"
git push

Using Unclear Commit Messages

A message such as "Update" does not provide enough information about the change.

A clearer message would be:

git commit -m "Fix incorrect signup link"

Committing Without Checking

Before committing, I should inspect the staged files:

git status
git diff --staged

This helps prevent accidental commits containing unfinished work, temporary files, or sensitive information.

A Simple Way to Remember the Workflow

I think of the Git workflow as preparing and sending a parcel.

The working directory is my desk, where I work on the contents. The staging area is where I choose what should go into the parcel. The commit is like sealing and labeling the parcel, while pushing is like sending it to the online destination.

The commands follow the same idea:

git add       Choose what to include
git commit    Save the selected changes locally
git push      Share the saved changes online

Final Workflow

For everyday Git work, I can use:

git status
git add .
git commit -m "Describe what changed"
git push

When I am unsure about the state of my project, I start with:

git status

The most important lesson is that changes move through separate stages:

Edit files
   ↓
Working Directory
   ↓ git add
Staging Area
   ↓ git commit
Local Repository
   ↓ git push
Remote Repository

Once I understand this process, Git commands become easier to remember. I am not just running commands randomly; I am deliberately moving my work from one stage to the next.

DEV Community: Trevor Zabar