How to give projects a memory that knows every change — and forgets nothing.
Fundamentals 12 min Beginner April 26, 2026
You have been working on a report for hours. One change breaks everything, and Ctrl+Z only goes back so far. What if your computer could remember every version of every file — and let you jump back to any of them in a second? That is exactly what Git does.
Git is the tool behind virtually every software project and every AI model in the world. By the end of this article, you will understand three core concepts — repositories, commits, and GitHub — and know exactly how they fit together.
Your Project Gets a Memory
Repository
AnalogyDefinition
A repository is like a notebook that remembers every state of every page. In a normal notebook, once you erase something, it is gone. In a Git repository, every version of every page is preserved — you can flip back to any past state at any time. And each team member has their own complete copy of this notebook.
Analogy:
A repository is like a notebook that remembers every state of every page. In a normal notebook, once you erase something, it is gone. In a Git repository, every version of every page is preserved — you can flip back to any past state at any time. And each team member has their own complete copy of this notebook.
Definition:
A Git repository is a project directory that contains a hidden .git subdirectory. Inside it, Git stores the complete version history as a database of objects: blobs for file contents, trees for directory structures, and commit objects for snapshots. Because Git is distributed, every local clone contains the full history — there is no technically privileged master server.
Where the notebook analogy breaks: a physical notebook cannot be split into parallel versions (branches), and merging two people's notebooks has no physical equivalent. Also, Git's distributed nature means there is no single "truth" — every clone is equally complete.
git init: Turning a folder into a repository
1
Create a new folder with mkdir project and enter it
2
Run git init — Git creates the hidden .git directory
3
ls -a now shows the .git folder — it was not there before
4
git status confirms: Git is now tracking this folder. Files appear as "untracked"
Centralized (e.g., SVN)
The server owns the complete history. Clients only have the current working copy. No access to past versions without the server. A single point of failure.
Distributed (Git)
Every clone contains the complete history. You can work offline, commit, and compare versions. There is no technically superior server — only conventions.
Common Misconception: Commits automatically go to the server
git commit only saves locally on your machine. Nobody else sees your changes until you explicitly run git push. And: "The central server is the real repo" is wrong — all copies are technically equally complete. The server is just the agreed-upon meeting point.
Saving with Intention
Commit
AnalogyDefinition
A commit is like taking a photo of your desk. Before pressing the shutter, you arrange exactly what should be visible — that is the staging step (git add). You do not photograph everything in the room, only what is on the desk. When you press the shutter (git commit), the photo is taken with a label and a timestamp. Later you can flip through all your photos to see how the desk looked at any point.
Analogy:
A commit is like taking a photo of your desk. Before pressing the shutter, you arrange exactly what should be visible — that is the staging step (git add). You do not photograph everything in the room, only what is on the desk. When you press the shutter (git commit), the photo is taken with a label and a timestamp. Later you can flip through all your photos to see how the desk looked at any point.
Definition:
A commit is a snapshot of the entire project state at one moment in time, plus metadata (author, timestamp, message, parent commit hash). Between the working directory and the repository sits the staging area (index): a preparation zone where you select exactly which changes to include in the next commit. Each commit is identified by a SHA-1 hash computed from its contents, making it unique and tamper-evident.
Where the desk photo analogy breaks: a real photo does not store a reference to the previous photo (parent commit). And you cannot restore your physical desk from a photo — but you can restore your project from a commit, because it contains the complete project state.
The Three-Zone Workflow
1
Working Directory: You edit files normally. Changes exist only locally; Git does not know about them yet.
2
Staging Area (git add): You deliberately select which changes go into the next commit. Like arranging items on the desk before taking the photo.
3
Repository (git commit): The snapshot is permanently saved — with a message, timestamp, and unique hash. Even if you delete the file afterwards, the committed version survives.
A concrete example: You edit buch.txt. git status shows the file as "modified". git add buch.txt moves the change to the staging area. git commit -m "Fix typo in chapter 3" creates the snapshot. git log --oneline now shows one entry: a short hash and your message.
Three Common Commit Misconceptions
First: git add is NOT git commit. git add prepares, git commit saves. Second: Git stores snapshots, not diffs — every commit contains the complete project state. Third: Commits are local until you explicitly upload them with git push. Your teammate does not see them until then.
Inside .git: What Git Actually Stores
The .git directory contains three types of objects. Blobs store the contents of individual files (without filenames — just the content). Trees store the directory structure (which blob belongs to which filename). Commit objects bundle a tree with metadata: author, timestamp, commit message, and a reference to the parent commit.
Each object is identified by its SHA-1 hash — a 40-character hexadecimal number computed from the content. Identical content always produces the same hash. This lets Git instantly detect whether a file has changed, and makes every commit tamper-evident: if even one bit changes, the entire hash changes.
Your Project in the Cloud
Git (Local Tool)
Command-line tool that works completely offline. Open source, created in 2005 by Linus Torvalds for Linux kernel development. Stores the complete history locally. No account needed.
GitHub (Cloud Platform)
Web platform with a graphical interface. Requires internet access. Offers pull requests, issue tracking, and CI/CD. Founded in 2008, part of Microsoft since 2018.
If Git is a camera that takes snapshots (commits), then GitHub is a cloud photo album where you upload your photos. The camera works without the album — you can commit locally as long as you want. But the album lets others see your photos, comment on them, and contribute their own. Where the analogy breaks: GitHub offers active collaboration (pull requests, code reviews, CI/CD) — far more than a passive album.
2008
Founded GitHub was founded in 2008 and quickly became the center of the open-source world
7.5 B $
Microsoft Acquisition In 2018, Microsoft acquired GitHub — a sign of the platform's significance
100 M+
Users Worldwide Over 100 million developers use GitHub for their projects
The three essential collaboration commands: git clone downloads a complete repository — including the full history. git push origin main uploads your local commits to GitHub. git pull fetches your teammates' changes. Important: the repository on GitHub is not "more real" than your local copy — it is simply the agreed-upon meeting point.
Caution: Large Files and Secrets
Git is optimized for text files. Large binary files like videos, AI models, or datasets bloat the repository because every version is stored in full. The solution: Git LFS (Large File Storage) for large files. Even more dangerous: accidentally committed API keys or passwords remain in the Git history even after you delete the file. Prevention is key — use .gitignore and review what you are committing before every commit.
What Happens When Two People Edit the Same File?
Branches are named pointers to commits that enable parallel work. You can create a branch, make independent changes, and merge them back later. As long as different files or different sections of the same file are changed, Git handles the merge automatically.
Conflicts only arise when two branches change the same line differently. Git then marks the conflict zone and you decide which version to keep. This sounds intimidating but is rare in practice and straightforward to resolve. Branches and merge strategies are a topic for later articles.
Interactive: The Git Workflow Step by Step
Click through the four steps of the Git workflow. Notice how each step builds on the previous one: first create a repository, then prepare changes, save a snapshot, and finally share with others.
👆Click on a point in time to learn more.
init
git init
The first step: git init turns a normal folder into a Git repository. Git creates the hidden .git directory where the entire version history will be stored from now on.
Significance: No init, no Git. This command enables version control for the folder. Files appear as "untracked" — Git knows about them but is not tracking them yet.
1 / 4
Key Takeaways
A Git repository is a folder with a hidden .git directory that stores the complete history of every file — not just the latest version.
Git is distributed: every local copy contains the full history, so you can work offline and no single server is the "master."
The staging area lets you choose exactly which changes go into a commit — like arranging items on a tray before photographing them.
A commit is a labeled snapshot of your project at a specific moment, identified by a unique hash.
GitHub is a cloud platform that hosts Git repositories and adds collaboration features — but Git itself works entirely without it.
Quiz: Version Control with Git
Question 1 / 4
Not completed
What does the command git init do in a folder?
1. What does the command git init do in a folder?
☐ A) It downloads a project from GitHub
☐ B) It creates a hidden .git directory and turns the folder into a Git repository
☐ C) It uploads the folder to the internet
☐ D) It deletes all files in the folder
2. You edited three files (app.py, test.py, README.md) but only want to commit app.py. Which commands do you run?
☐ A) git add . && git commit -m "update"
☐ B) git commit app.py -m "update"
☐ C) git add app.py && git commit -m "update app"
☐ D) git push app.py
3. A colleague says: "I pushed my code to Git." What is technically incorrect?
☐ A) Nothing, the statement is correct
☐ B) You push to GitHub or another remote server, not to Git — Git is the local tool
☐ C) You cannot push code at all
☐ D) Git does not have a push command
4. Why does Git store complete snapshots instead of just differences (diffs)?
☐ A) Snapshots use less storage space
☐ B) Each commit is self-contained and can be restored without computing differences
☐ C) Git cannot compute differences
☐ D) Diffs do not work with text files
Answer Key: 1) B · 2) C · 3) B · 4) B
Comprehension Check
Your friend has a folder with code. You recommend running git init. What changes in the folder, and what can they do afterwards that was not possible before?
You edited three files but only want to commit changes to two of them. Describe how you use the staging area.
A colleague says: "I pushed my code to Git." What is technically incorrect about this statement?