The first time you see a Git workflow, it can look like a list of commands you are supposed to memorize:

git add.
git commit -m "Initial commit"
git push

Three commands, and somehow the project ends up on GitHub.

But what actually happens between creating a folder on your computer and seeing that project in a GitHub repository?

The commands become much easier to understand when you stop treating them as a sequence to memorize and start seeing them as different stages in a workflow.

In this article, we discussed a small Git Workflow, from creating a directory to your code being available on GitHub.

mkdir
  ↓
git init
  ↓
git add
  ↓
git commit
  ↓
git push

The goal is not simply to learn what each command means, but to understand where the project is at each stage and what changes after every command.

Why does this workflow matter?

When creating a project on your computer.

You create a folder, add some files, and start making changes.

At some point, you want Git to keep track of those changes. Eventually, you may also want the project's history to be available on GitHub. Simply put, local files store your work, Git tracks how it changes over time, and GitHub backs up and shares those tracked changes with the world.

It is tempting to think that Git takes the files on your computer and uploads them to GitHub.

That is not what happens.

There are several stages between the files you are editing locally and the repository hosted remotely.

A simplified version looks like this:

Working Directory
       ↓
Staging Area
       ↓
Local Repository
       ↓
Remote Repository

Understanding these four places is the key to understanding the Git workflow.

1. Working Directory: where the project starts

Everything starts with a directory on your computer.

For this walkthrough, create a small Git sandbox:

mkdir git-workflow-demo
cd git-workflow-demo

The project can contain two simple files:

git-workflow-demo/
├── README.md
└── hello.py

At this point, these are simply files inside a directory.

Git has not started tracking the project yet.

This is the working directory: the location where the project files exist and where changes are made.

For example, hello.py might contain:

print("Hello, Git!")

If the file is edited, the change happens directly in the working directory.

But there is an important question:

*How does Git know which changes should become part of the project's history? *

That is where Git's repository and staging area come in.

2. git init: turning the folder into a Git repository

Before Git can track the project, initialize a repository:

git init

This creates the Git metadata needed for the directory to become a Git repository.

The project is still in the same location, but Git can now start managing its history.

The transition looks like this:

Regular project folder
        ↓
     git init
        ↓
Git repository

A useful command to run immediately after this is:

git status

git status provides information about the current state of the repository.

It helps answer questions such as:

• What files have changed?
• What files are untracked?
• What changes are staged?
• What changes are ready to be committed?

Rather than guessing what Git knows about, git status lets you inspect the repository's current state.

3. The Staging Area: choosing what to record

Suppose README.md has been created or modified.

You can stage it with:

git add README.md

This is one of the most important distinctions for anyone learning Git:

git add does not upload the file to GitHub.

Instead, it tells Git:

Include this change in the next commit.

The staging area therefore sits between the working directory and the local repository.

Working Directory
       │
       │ git add
       ▼
Staging Area

You can verify the state with:

git status

This shows that the change has moved from an unstaged state to a staged state.

Why have a staging area?

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

Imagine three files have changed:

app.py
README.md
config.py

You might decide that only the changes to app.py and README.md belong in the next commit:

git add app.py README.md

Now those selected changes are staged, while config.py can remain unstaged.

This is one reason Git is more than a simple file-uploading tool.

It gives you a way to select the changes you want to record together.

4. git commit: creating a point in project history

Once the desired changes have been staged, create a commit:

git commit -m "Add README"

A commit is a recorded point in the project's history.

The workflow is now:

Working Directory
       ↓
    git add
       ↓
Staging Area
       ↓
   git commit
       ↓
Local Repository

The local repository now contains a record of the staged changes.

But there is an important distinction:

The commit has not been sent to GitHub yet.

This is where most confuse commit with push.

Think of the two commands this way:

git commit
→ Records the staged changes locally

git push
→ Sends local commits to a remote repository

A commit and a push are therefore two separate operations.

5. A small experiment: watch the state change

One of the easiest ways to understand Git is to observe what happens after each command.

Start with:

git init

Then:

git status

Stage the README:

git add README.md

Check the status again:

git status

Create the commit:

git commit -m "Add README"

Then check again:

git status

The important part of this exercise is not simply running the commands.

It is observing how the repository's state changes.

You can think of the experiment as:

Before git add
        ↓
Working Directory

After git add
        ↓
Staging Area

After git commit
        ↓
Local Repository

That makes the workflow easier to understand than memorizing a sequence of commands without knowing what each one is doing.

6. What changes after each command?

Here is the entire workflow in one place:

The important idea is that each command has a different responsibility.

That is why the commands should not be thought of as interchangeable.

7. Where does GitHub come in?

So far, everything has happened on the local computer.

The working directory is local.

The staging area is local.

The Git repository containing the commit history is local.

GitHub becomes involved when a remote repository is connected.The local repository and the GitHub repository are separate repositories.

The next step is to connect them.

8. Connecting the local repository to GitHub

After creating an empty repository on GitHub, connect it to the local repository with:

git remote add origin git@github.com:username/git-workflow-demo.git

Here, origin is the name given to the remote repository.

You can check the configured remote with:

git remote -v

At this point, Git knows where the remote repository is.

But the local commits are still local.

They have not been sent to GitHub yet. That requires git push.

9. Where SSH fits and what it does

If the remote URL looks like this:

git@github.com:username/git-workflow-demo.git

the repository is being accessed through SSH.

SSH provides an authenticated way for your computer to communicate with GitHub.

The basic idea is:

Your computer
     │
     │ SSH authentication
     ▼
   GitHub

Before Git can communicate with GitHub through SSH, an SSH key needs to be configured and associated with the GitHub account.

The important point for the Git workflow is that SSH is about authentication and communication with the remote repository.

It is not another version of git add or git commit.

Those commands manage the local Git workflow. SSH helps establish the connection to GitHub.

10. Finally: git push

Now the local commit can be sent to the remote repository:

git push -u origin main

This is the step where the local Git history is transferred to the configured remote repository.

The complete workflow now looks like this:

┌──────────────────────────┐
│    Working Directory     │
│                          │
│   Files are created or   │
│        modified          │
└────────────┬─────────────┘
             │
          git add
             │
             ▼
┌──────────────────────────┐
│      Staging Area        │
│                          │
│ Changes selected for the │
│      next commit         │
└────────────┬─────────────┘
             │
         git commit
             │
             ▼
┌──────────────────────────┐
│    Local Repository      │
│                          │
│   Commit history exists  │
│        locally           │
└────────────┬─────────────┘
             │
          git push
             │
             ▼
┌──────────────────────────┐
│    Remote Repository     │
│         GitHub           │
└──────────────────────────┘

So what actually happened to the project?

It did not simply jump from the computer to GitHub.

It moved through a series of stages.

A common beginner misconception

One of the easiest things to misunderstand when learning Git is that git add, git commit, and git push all somehow "move the code."

They do—but not to the same place.

Consider this simplified model:

git add
→ Select changes for the next commit

git commit
→ Record those staged changes locally

git push
→ Send those local commits to the remote repository

The commands are connected, but each one operates at a different stage of the workflow.

This distinction becomes particularly important when something does not behave as expected.

If a file is not included in a commit, the first question should not be:

"Why didn't GitHub update?"

A better question is:

"At which stage did the change stop?"

Was it:

• never changed in the working directory?
• not staged?
• not committed?
• committed locally but not pushed?

Understanding the workflow makes those questions much easier to answer.

The bigger lesson: Git is a workflow, not a command list

It is possible to memorize:

git add .
git commit -m "message"
git push

and still have very little understanding of Git.

A better mental model is:

"I changed something."
        ↓
Working Directory

"I want this change included."
        ↓
Staging Area

"I want to record this version."
        ↓
Local Repository

"I want that recorded history on GitHub."
        ↓
Remote Repository

Once the purpose of each stage is clear, the commands become easier to remember because each command answers a specific need.

That is more useful than memorizing a command sequence without understanding what happens between the commands.

5 takeaways from the Git workflow

1. The working directory is where changes are made.

This is where project files are created, edited, and deleted.

2. The staging area lets you choose what goes into the next commit.

git add prepares selected changes for recording.

3. A commit records staged changes locally.

A commit creates a point in the project's history.

4. A push sends local commits to a remote repository.

git push is what moves committed history from the local repository to the configured remote.

5. Understanding the workflow is more useful than memorizing commands.

When the purpose of each stage is clear, Git commands become easier to reason about.

What happens when more than one person changes the project?

The basic workflow is only the beginning.

Once a repository becomes collaborative, another set of questions appears:

• What happens when two people work on the same project?
• What is a branch?
• Why create a branch instead of working directly on main?
• How are changes reviewed before they become part of the main project?
• What happens when two people modify the same part of a file?

Those questions lead to the next part of the Git workflow:

branches → pull requests → merging → merge conflicts → collaborative Git workflows.

For now, the most useful mental model is simple:

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

Git is not just the tool used to put code on GitHub. It is a system for tracking, organizing, recording, and sharing changes to a project over time.