DEV Community: Esther Njihia

From MKDIR to GIT PUSH: What Actually Happens to a Project?

Esther Njihia — Sun, 23 Aug 2026 07:02:43 +0000

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:

Command	What changes?	Where are the changes?
`git init`	Creates Git metadata	Local project
`git add`	Selects changes for the next commit	Staging area
`git commit`	Records staged changes	Local repository
`git push`	Sends local commits to the remote	GitHub

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.

Analysis of 120 Years of Olympics Data

Esther Njihia — Sun, 22 Jan 2023 06:12:18 +0000

Overview

The Olympic Games are one of the most prestigious and widely-followed sporting events in the world. With a history dating back over a century, the Olympics have seen countless athletes from all corners of the globe compete for glory and honor. In this project, we will use Python, SQL and Tableau to analyze 120 years of Olympics data sourced from Kaggle.

Data Collection

The data for this analysis was sourced from Kaggle and includes information on athletes, teams, events, and medals. The data was collected for all Summer and Winter Olympics from 1896 to 2016.
Data source: Kaggle

Data Cleaning and Preparation

Before we could begin our analysis, the data needed to be cleaned and prepared for use. This involved removing any duplicate or irrelevant data, correcting any errors or inconsistencies, and formatting the data in a way that would be compatible with our analysis tools.

Data Cleaning with Python

Load data

df = pd.read_csv("data/athlete_events.csv")

Calculate the number of missing values in the data

df.isnull().sum()

We got some missing values with the age, height and weight variables. How about we fix that.
Fill in the age missing values with its mean.

df['Age'].fillna(df['Age'].mean(), inplace= True)

Repeat the same for the height and weight variables.

SQL Analysis

Once the data was cleaned and prepared, we used SQL to extract and analyze the data. We were able to answer questions such as:
1.What is the Gender distribution of athletes across different sports and event?

SELECT Sport, Event, Sex, COUNT(Name) as athlete_count
FROM Athlete
GROUP BY Sport, Event, Sex
ORDER BY athlete_count DESC;

2.Which city and season have the most successful athletes?

SELECT City, Season, COUNT(Medal) as Medal_count
FROM Athlete
WHERE Medal IS NOT NULL
GROUP BY City, Season
ORDER BY Medal_count DESC

3.Which athletes are the most successful in terms of number of medals?

SELECT Name, COUNT(Medal) as medal_count
FROM Athlete
GROUP BY Name
ORDER BY medal_count DESC;

4.Trend analysis to identify any patterns in the number of medals over time
By year

SELECT Year, COUNT(Medal) as medal_count
FROM Athlete
GROUP BY Year
ORDER BY Year ;

5.Use statistical analysis to find factors associated with winning more medals.

first create a sub query to find the total count of medals per city and season

WITH city_season_medals AS (
    SELECT City, Season, COUNT(Medal) AS medal_count
    FROM Athlete
    GROUP BY City, Season
)

use statistical methods to find the relationship between city & season and the total number of medals. Fo this instance I used z-score. The higher the z-score the higher the correlation.

SELECT City, Season, medal_count, (medal_count - AVG(medal_count) OVER()) / STDEV(medal_count) OVER() AS z_score
FROM city_season_medals
ORDER BY z_score DESC

These are some of the questions that were answered during the SQL analysis.

Visualization with Tableau

To make the data more accessible and understandable, Tableau was used to create visualizations of our findings. Some of the visualizations we created include:

A pie chart showing the gender distribution across all sports
A bar chart showing the most successful athletes over time.
line charts to show trends and patterns in the number of medals won over time

View the whole Olympics dashboard:Olympics Dashboard

Conclusion

Through this analysis, I was able to gain a deeper understanding of the history of the Olympics and the performances of countries and athletes over the past 120 years. By using SQL and Tableau, I was able to extract valuable insights from the data and present them in a clear and accessible way.

Code and Data

The code and data used for this project is available at Github

By using the above techniques, we can also use the data to predict future results, and also to identify patterns and trends that can be used to improve performance and achieve success in future Olympic games.

Data engineering 102: Introduction to python for data engineering.

Esther Njihia — Sun, 04 Sep 2022 20:39:09 +0000

Overview

The most interesting thing about python language is sort of all rounded. Due to its readability which is easy and the fact that it has very many applications including data engineering. In this post, we will discuss the most important concepts in the python language.

Python Syntax

Python, builds the code structure using whitespace and indentation.

Comments

The comments are just as crucial as the code itself, because they explain why a piece of code was produced
The comments are ignored by the Python interpreter when it runs the code.
A single line comment in Python starts with the hash symbol (#), which is followed by the comment.

Identifiers

Python uses identifiers, or names, to designate variables, functions, modules, classes, and other types of objects.
An identifier's name must begin with a letter or an underscore. After that, only underscores or alphanumeric characters are allowed.

Keywords

Keywords are words that have special meaning in python. Python has a special module keyword that outlines all the keywords that are used in the Python Language.

Control statements

If statements.

If statements are conditional statements. Below is the summary of the different if statements:
When you want to run a code block based on a condition, use the if statement.
If you want to execute a different code block if the condition is not True, use the if...else statement.
When you wish to check multiple conditions and execute the associated code block after the condition that evaluates to True, use the if...elif...else statement.

for loop

A code block can be performed a predetermined number of times by using the for loop statement.
To alter the loop, use the range(start, stop, step).

while loop.

If a condition is True, use the Python while loop statement to run a code block.

Functions

A named, reusable chunk of code called a function in Python executes a command or returns a value.
Create a new function by using the def keyword. The function definition and body make up a function.
A function may have 0 parameters or more. You must pass a function the same amount of arguments if it has one or more parameters.
A function can do a task or give back a value. If you want to return a value from a function, use the return statement.

Lists

An orderly group of elements is referred to as a list.
If you want to retrieve a list element by its index, use the square bracket notation []. The index of the first element is zero.
To reach a list element from the list's end, use a negative index. The final component has an index of -1.
To change an entry from a list, use list[index] = new value.
To add a new element to the end of a list, use the append() method.
To insert a new element at a certain location in a list, use insert().
To remove an entry from a list and return it, use the pop() function.
To eliminate an element from a list, use remove().
Tuples are immutable lists.
Use tuples when you want to define a list that cannot change.

Dictionary

A Python dictionary is a group of key-value pairs, each of which has a corresponding value.
In order to access a value by its key, use square brackets or the get() method.
To remove a key-value pair by the key from a dictionary, use the del statement.
To iterate through the keys, values, and key-value pairs in a dictionary, use a for loop.

This post includes a summarization of some most important concepts as a beginner in Python.

DEV Community: Esther Njihia

From MKDIR to GIT PUSH: What Actually Happens to a Project?

Why does this workflow matter?

1. Working Directory: where the project starts

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

3. The Staging Area: choosing what to record

Why have a staging area?

4. git commit: creating a point in project history

5. A small experiment: watch the state change

6. What changes after each command?

7. Where does GitHub come in?

8. Connecting the local repository to GitHub

9. Where SSH fits and what it does

10. Finally: git push

A common beginner misconception

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

5 takeaways from the Git workflow

1. The working directory is where changes are made.

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

3. A commit records staged changes locally.

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

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

What happens when more than one person changes the project?

Analysis of 120 Years of Olympics Data

Overview

Data Collection

Data Cleaning and Preparation

Data Cleaning with Python

SQL Analysis

Visualization with Tableau

Conclusion

Code and Data

Data engineering 102: Introduction to python for data engineering.

Overview

Python Syntax

Comments

Identifiers

Keywords

Control statements

If statements.

for loop

while loop.

Functions

Lists

Dictionary

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

4. `git commit`: creating a point in project history

10. Finally: `git push`