Git Init, Add, and Commit: What Actually Happens?

In the previous article, we explored Git's mental model: a working directory, a staging area, and a repository containing your project's history.

Now let's put that model to work.

We'll create a tiny project, initialize Git, make a few changes, and watch those changes move through the three areas.

By the end, you'll understand what these commands actually do:

1git init
2git add
3git commit
Copy

No mysterious rituals. No blindly copying commands from Stack Overflow. Just Git doing what Git does.

1. Create a project

Let's build a very sophisticated application.

It will have exactly one file.

Create a directory and move into it:

Create a file named hello.txt with the following content:

Hello, Git!

Your directory now looks like this:

At this point, Git isn't tracking this project yet. The file exists on your computer, but we haven't asked Git to manage its history.

Let's change that.

2. git init: Create a repository

Run:

1git init
Copy

Git initializes a repository in the current directory. Depending on your Git configuration, you might see a message indicating that an initial branch has been created or that Git has used a default branch name.

What actually happened?

Git created a .git directory to hold the repository's internal data, references, and configuration.

Your project now looks conceptually like this:

The .git directory is where Git maintains the repository. You generally shouldn't edit its internal files manually.

You can check the repository status:

1git status
Copy

Git will report that hello.txt is an untracked file.

Think of git init as setting up your project's history book. The pages are ready; you haven't written the first entry yet.

3. git add: Choose what goes into your next commit

Here's where Git's staging area enters the picture.

Run:

1git add hello.txt
Copy

Now check the status again:

1git status
Copy

You'll see hello.txt listed under changes to be committed.

But wait. Didn't we say git add adds a file?

Yes, but there's an important distinction.

The staging area, also called the index, records what you want the next commit to contain.

Our workflow now looks like this:

Working Directory Staging Area
----------------- ------------
hello.txt hello.txt
"Hello, Git!" "Hello, Git!"
| ^
+------ git add --------+

The file is still present in your working directory. Staging doesn't move it away or delete it. It prepares its content for the next commit.

Why have a staging area at all?

Imagine you're working on two things:

* Fixing a login bug.

* Updating the documentation.

You want to record the bug fix now and commit the documentation separately.

Git lets you stage only the relevant changes, keeping each commit focused on one logical task.

That's much more useful than saving every change you've made in one giant commit called misc fixes.

And yes, we've all seen that commit message.

4. git commit: Record a checkpoint

We've initialized the repository and staged our file. Let's record our first commit.

Run:

1git commit -m "Add greeting file"
Copy

The -m option supplies the commit message.

Git records a commit using the content represented by the staging area. The commit also records metadata, including its author, timestamp, and parent relationship.

Because this is our first commit, it has no parent commit.

Check the status:

1git status
Copy

You should see a message indicating that the working tree is clean.

Congratulations! You've created your first commit.

The history now contains a checkpoint representing the project at that moment.

Working Directory Staging Area Repository
----------------- ------------ ----------
hello.txt No pending Commit A
changes "Add greeting file"

A commit is not simply a button that saves files. It's a recorded snapshot that becomes part of the repository's history.

5. Here's where it gets interesting

Let's modify hello.txt.

Change its content to:

Hello, Git!
Version control makes sense now.

Now run:

1git status
Copy

Git reports that hello.txt has been modified.

But we haven't staged the new version.

This is an important moment: the repository still contains the content from our previous commit, while the working directory contains the updated file.

Let's see the difference:

1git diff
Copy

Git displays the changes in your working directory that haven't been staged.

Now stage the update:

1git add hello.txt
Copy

Run:

1git diff --staged
Copy

This shows the changes currently staged for the next commit.

The two commands answer different questions:

git diff: What changed in my working directory compared with the staging area?

git diff --staged: What staged changes would be included in my next commit compared with the current commit?

Now record the update:

1git commit -m "Expand greeting message"
Copy

Our history now looks like this:

A --- B

Where:

A: Add greeting file

B: Expand greeting message

Commit B records the updated project snapshot. Commit A remains part of the history.

That's the foundation of version control: meaningful checkpoints connected through time.

6. What if you change a file after staging it?

This is one of the most useful details to understand.

Let's stage a change:

echo "A second update" >> hello.txt
git add hello.txt

Now edit the file again before committing:

echo "A third update" >> hello.txt

Check:

1git status
Copy

Git can now report that the file has staged changes and additional unstaged changes.

Why?

Because staging records the content at the time you ran git add. Editing the file afterward doesn't automatically update the staged version.

To stage the latest version too, run:

1git add hello.t
Copy

Then commit when you're ready:

1git commit -m "Update greeting "
Copy

This is why git add isn't just a preliminary step you can forget about. It determines which version of your changes goes into the next commit.

7. Is git add . safe?

You've probably seen this command everywhere:

1git add .
Copy

It stages changes under the current directory, including new files and modifications, subject to Git's ignore rules and path handling.

It's convenient, but it can stage more than you intended.

Before committing, check:

1git status
2git diff --staged
Copy

These commands help you verify what you've prepared.

For a small, controlled change, staging a specific file is often clearer:

1git add hello.txt
Copy

For selected parts of a file, you can even use:

1git add -p
Copy

This lets you interactively choose which changes to stage.

A little review before committing is usually faster than figuring out later why a debug statement or unrelated change ended up in your history.

8. Inspect your commit history

Let's see the commits we've created:

1git log --oneline
Copy

You should see entries similar to:

Your actual commit hashes will differ.

Each line represents a commit. The abbreviated hash identifies it, and the message describes the change.

For more detail about the latest commit, run:

1git show
Copy

This displays the commit metadata and its changes.

You can now inspect the history instead of relying on memory or a folder full of backup files.

9. A few common misconceptions

"Git add saves my changes."

Not in the sense of recording them in repository history. It stages content for the next commit. Your editor already saves files to your working directory.

"Git commit includes everything I've changed."

A commit normally records what is staged, not every modification in your working directory.

"Git add moves my files into Git."

It doesn't move your files. It updates the staging area while your files remain in place.

"I need GitHub to use Git."

No. You can initialize repositories, make commits, and inspect history entirely on your local computer. Remote hosting is a separate concern.

"Once I commit, my work is backed up online."

Not necessarily. A local commit is stored in your local repository. To share it with a remote repository, you'll eventually use commands such as git push.

10. The three commands, one mental model

Let's summarize the complete workflow:

# Initialize the repository

1git init
Copy

# Stage a file

1git add hello.txt
Copy

# Record a checkpoint

1git commit -m "Add greeting file"
Copy

The conceptual flow is:

Edit files
|
v
Working Directory
|
| git add
v
Staging Area
|
| git commit
v
Repository History

Remember:

git init initializes a repository.

git add stages content for a future commit.

git commit records a snapshot of the staged content.

These commands form the foundation of almost everything you'll do with Git.

Once you understand them, branches, merges, and remote repositories become easier to reason about because they build on the same underlying ideas.

What's next?

So far, we've worked in a single repository and created a linear history.

But what happens when you want to experiment with a new feature without disturbing your main line of development?

That's where branches come in.

In the next article, we'll explore what a Git branch actually is, why it's lightweight, and what HEAD points to.

Next: Git Branches Are Simpler Than You Think.