Git Basics — explained innovatively

If you’re anything like me, you’ve probably learned Git multiple times.

You understand it while you’re learning, but a few weeks later the concepts become fuzzy again. I could remember the commands, but I couldn’t remember why Git worked the way it did.

So I started looking for a real-world analogy that would make Git’s workflow easier to visualize. The analogy that finally made everything click was thinking of Git as a librarian.

Rather than memorizing commands like git add, git commit, and git push, I now think about an author writing books and a librarian managing them.

The Librarian Analogy

Imagine you’re an author.

You sit at your desk writing books. When you’re satisfied with a draft, you hand it to the librarian.

The librarian places the book on a book cart while preparing it for shelving. When you officially approve it, the librarian places it on the library shelf as a new edition.

If you later revise the same book, the librarian doesn’t replace the old edition. Instead, another edition is added to the shelf.

Finally, your local library can send its latest editions to the Central Library, where everyone else can access them.

This simple story maps surprisingly well to Git.

Created with chatGPT

Step 1: Hiring the Librarian (git init)

Before running Git, your project is simply a folder on your computer.

There is no tracking.

No version history.

Nobody is keeping track of what changes you make.

When you execute:

git init

you are essentially hiring a librarian.

The librarian now starts managing your project. Internally, Git creates a hidden .git directory, which stores all of its metadata and history.

At this point, your library looks like this:

YOUR OFFICE

               👨‍💻 Author
                   │
                   ▼
             ┌───────────────┐
             │     Desk      │
             └───────────────┘

                 👩 Librarian

        🛒 Cart            📚 Shelves

            (all empty)

Notice that nothing has been cataloged yet. The librarian is simply ready to start tracking your work.

Step 2: Writing a Book (Working Folder)

Now you create your first file.

employees.sql

Think of this as writing your first book on your desk.

When you execute:

git status

Git responds with:

Untracked files:
    employees.sql

Why?

Because the librarian looks in the catalog and says:

“I’ve never seen this book before.”

The file exists on your desk, but it isn’t part of the library yet.

Step 3: Handing the Book to the Librarian (git add)

Once you’re satisfied with the file, you run:

git add employees.sql

This is where many beginners — including me — get confused.

I used to think git add stored the file permanently.

It doesn’t.

Instead, you’re telling the librarian:

“This version is ready. Please place it on the book cart.”

The file still remains on your desk.

The cart simply contains the books that are ready for the next shelving operation.

Running git status now shows:

Changes to be committed

The librarian has the book on the cart, but it hasn’t reached the shelf yet.

Step 4: Putting the Book on the Shelf (git commit)

Next you execute:

git commit -m "Added employee query"

Now the librarian takes every book currently on the cart and places it on the library shelf as a new edition.

After the commit, running:

git status

returns:

nothing to commit, working tree clean

The desk and the library now contain the same version of the book.

Step 5: Editing the Book Again

Now suppose you edit employees.sql.

When you execute:

git status

Git no longer says:

Untracked files

Instead, it says:

Changes not staged for commit

Why?

Because the librarian already knows this book.

The librarian simply notices that the version on your desk is now different from the version currently on the shelf.

The book isn’t “unknown” anymore — it just has new changes that haven’t been placed on the cart yet.

This distinction finally helped me understand the difference between Untracked and Changes not staged.

Step 6: Sharing with the Central Library (git push)

Everything so far has happened inside your own library.

When you execute:

git push

you’re telling your librarian:

“Send the latest editions from our shelves to the Central Library.”

The Central Library is your remote repository (GitHub, Azure DevOps, GitLab, etc.).

Other developers can now retrieve those editions into their own local libraries using git pull.

The Complete Flow

YOUR OFFICE

           👨‍💻 Author
               │
               ▼
      ┌───────────────────┐
      │       Desk        │
      │ (Working Folder)  │
      └───────────────────┘
               │
        git add │
               ▼
      🛒 Book Cart
      (Staging Area)
               │
      git commit │
               ▼
      📚 Local Library Shelves
      (Local Repository)
               │
       git push │
               ▼
      🏛️ Central Library
      (Remote Repository)

Why This Analogy Worked for Me

Instead of memorizing Git commands, I now think about the responsibilities of the librarian.

Whenever I run git status, I imagine the librarian asking three simple questions:

1. Do I know this book?

• No → Untracked

1. Has the book changed since the last edition on the shelf?

• No → Nothing to report

1. Have you placed the latest version on my cart yet?

• No → Changes not staged
• Yes → Changes to be committed

Once I started thinking this way, Git commands stopped feeling like isolated commands and started feeling like steps in a simple workflow.

Sometimes all we need isn’t another Git tutorial — we just need a mental model that sticks.