Git Internals: Part 1
What Exactly Is Git?
A common misconception among beginners is that Git and GitHub are the same thing. They’re not.
Git is a distributed version control system that tracks changes to your project over time. Every time you commit, Git records a snapshot of your project’s current state, allowing you to revisit previous versions, compare changes, or restore your work whenever needed.
GitHub, on the other hand, is a cloud platform that hosts Git repositories and makes collaboration easier. Think of Git as the tool that manages your project’s history, while GitHub is a service that lets you store and share that history with others.
Have you ever wondered why almost every Git tutorial starts with git init, but very few explain what actually changes after running it?
Or why we need to git add a file before committing it?
Or what people actually mean by a repository?
When I first started learning Git, I did what most of us do — I memorized a few commands and moved on.
git add .
git commit -m "Completed feature"
git pushThen I started contributing to an existing codebase. That’s when I realized Git was much more than just a few commands.
I was asked to pull the latest changes before starting work, create a new branch for every task, resolve conflicts when they appeared, and sometimes even stash my work because something more urgent came up.
I could follow the workflow, but every now and then I’d stop and wonder:
- What is Git actually tracking?
- Why does Git need a staging area?
- What exactly changed after I ran
git init? - Why are files called untracked, modified, or staged?
While trying to answer these questions for myself, I realized that many tutorials focus on which commands to type, not what those commands are actually doing.
So this series is my attempt to understand Git from the ground up.
We’ll start with the fundamentals and build our way towards branches, merge conflicts, rebasing, stash, and everything else that becomes part of day-to-day development.
Git Thinks in Snapshots
Every time you create a commit, Git doesn’t simply save the files you changed. It records a snapshot of your project at that moment, allowing you to revisit, compare, or restore previous versions whenever needed.
This ability to move through your project’s history is what makes Git much more than a backup tool.
To understand how Git records these snapshots, let’s go back to the very first command almost every Git tutorial starts with.
git initWhat does this command actually do?
At first glance, it seems like nothing happened. Your source files remain exactly where they were, and no new folders appear — at least none that are immediately visible.
Get Aarthi_Honguthi’s stories in your inbox
Join Medium for free to get updates from this writer.
So what changed?
The answer lies in a hidden directory that Git creates inside your project.
It creates the Git repository by initializing the hidden .git directory, where Git stores everything it needs to track the history of our project.
Now that Git has been initialized, how does it know which files have changed? The answer lies in something called the Git lifecycle.
Every file in a Git repository moves through a series of states — from the moment it’s created until it becomes part of your project’s history.
Understanding the Git File Lifecycle
Every file in a Git repository moves through a series of states during its lifetime.
Whether you create a new file, modify an existing one, or commit your changes, Git keeps track of the current state of each file.
The diagram below summarizes this entire journey.
Let’s briefly understand what each state represents.
Untracked: A newly created file that Git has never seen before. Git knows the file exists but isn’t tracking it yet.
Staged: The file has been marked for inclusion in the next commit using git add.
Unmodified (Committed): The latest version of the file has been committed, and no changes have been made since then.
Modified: The file was previously committed, but you’ve made changes that haven’t been staged yet.
Staged + Modified: You’ve already staged a version of the file, but then made additional edits afterward. The staged version and your current working version are now different.
git status
At any point, Git can tell us the current state of every file in the repository. Whether a file is Untracked, Modified, or Staged, git status reports its current state.
git add
Creating or modifying a file doesn’t automatically include it in the next commit.
The file now moves to the Staged state.
git commit
Once your changes are staged, create a commit. A commit records a snapshot of the staged changes.
You might have noticed Git printed something like
[main e62081a]after the commit. What domainand that seemingly random string of characters represent? We'll uncover that in Part 2.
