"A folder becomes a repository the moment Git starts watching it. The difference is one command and a hidden folder you'll almost never touch directly."
What a Repository Is
A repository — repo for short — is any folder that Git is tracking. That's it. Nothing special about the folder itself; what makes it a repository is a hidden subfolder called .git that Git creates inside it when you run git init.
That .git folder is Git's entire database for your project. Every commit you've ever made, every branch, every configuration setting — all of it lives inside .git. Delete that folder and Git forgets all history. The files survive, but the timeline is gone.
You will almost never touch .git directly. But knowing it exists tells you two important things:
- Moving a repository to a different location on your disk moves
.gitwith it — all history stays intact. - Git tracks one folder per
.git. You can't use one.gitfolder to track a completely separate directory elsewhere.
git config — Attaching Your Identity Before Anything Else
Before your first commit, Git needs to know who you are. Every commit permanently records an author name and email address as part of its data. Once a commit exists, its author cannot be changed retroactively.
You configure this once, globally, for your machine:
git config --global user.name "Your Full Name" git config --global user.email "your@email.com"
The --global flag writes these values to a file called .gitconfig in your home directory. Every Git repository on your machine will use them unless you override them per-project with --local.
To confirm the setup:
git config --list
Your name and email will appear in the output alongside Git's other default settings. The email address matters beyond identification — GitHub uses it to match your commits to your profile and display your contribution history.
git init — Starting the Watch
Navigate to the folder you want Git to track. Then run:
git init
Git responds with:
Initialized empty Git repository in /path/to/your-folder/.git/
That's Git creating the .git subfolder. Your folder is now a repository. Nothing has been committed yet — Git is watching, but no snapshots exist.
A note on branch names. Git 2.28 and later creates a branch called main by default. Earlier versions create master. If your output shows master instead of main, your Git is older than 2.28. Both work identically — only the name differs. All screenshots and outputs in this series use main.
git status — Reading What Git Sees
git status is the command you will run most often in day-to-day Git work. It answers one question: what's changed since my last commit?
In a brand-new repository with no commits yet, it looks like this:
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
notes.txt
nothing added to commit but untracked files present (use "git add" to track)
"Untracked" does not mean Git can't see the file. Git sees it — it listed it. "Untracked" means Git has made a deliberate choice not to include it in snapshots yet. You haven't told it to. This is intentional: Git lets you decide what gets tracked, rather than tracking everything automatically and creating noise.
Run git status before and after every operation when you're learning. The output tells you exactly where everything stands.
The Staging Area — Why It Exists
This is the concept most beginners skim past and later find confusing. It's worth slowing down here.
Git does not commit everything that changed. Git commits exactly what you stage.
The staging area (also called the index) is a preparation step between your working files and your commit. You explicitly select which changes to include in the next snapshot.
Why does this extra step exist?
Imagine you're working on two things simultaneously: you fixed a bug in auth.js and started a new feature in dashboard.js. Both files changed. You want two separate commits — one for the bug fix, one for the feature — because clear, focused commits make the history readable and make it straightforward to revert one change without reverting the other.
The staging area lets you add only auth.js to the first commit, even though dashboard.js is also modified. Then you stage and commit dashboard.js separately. Without the staging area, you'd have to commit all changes together or none — no middle ground.
git add — Preparing the Snapshot
git add moves a file from "untracked" (or "modified") into the staging area:
git add notes.txt # stage one specific file git add . # stage all changes in the current directory
After staging, run git status again. The output changes:
On branch main
No commits yet
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: notes.txt
The file moved from "Untracked files" to "Changes to be committed." It's in the queue. It hasn't been committed — but it's staged and ready for the next snapshot.
git commit — Taking the Snapshot
git commit -m "Describe what changed and why"
The -m flag attaches a message to the commit. Every commit must have one. Good commit messages describe intent, not mechanics. Add initial notes file is acceptable. Fix: remove stale session cache on logout is better because it answers why, not just what.
A commit is permanent and immutable. Once it exists, its content does not change. Future commits build on top of it, but the original commit stays exactly as it was. This is what makes Git a reliable timeline — nothing in the past can be silently edited.
After committing, git log shows the full history:
commit a3f7b21c9e4d5f8b1a2c3d4e5f6789012345678 (HEAD -> main)
Author: Your Full Name <your@email.com>
Date: Thu Aug 7 14:23:45 2026 +0530
Add initial notes file
Every entry in git log is a permanent record: who made the change, when, and why.
.gitignore — Teaching Git What to Skip
Some files should never be committed. Two categories matter most.
Regenerable files — things that any developer can recreate from the repo with a single command. The most common example is node_modules/ — hundreds of megabytes of npm packages. They are defined in package.json and regenerated with npm install. Committing them bloats the repository and makes every diff unreadable.
Secrets — credentials that give access to your services. A .env file is the standard location for these in a Node.js project. In a platform like RR Skillverse, .env contains the Azure PostgreSQL connection string, the Supabase API key, the Azure Blob Storage account key, and the Azure OpenAI key. Committing this file to a public repository exposes every one of those services to anyone who can read the history.
The .gitignore file tells Git to pretend certain files don't exist. Create it in the root of your project. Here is what a real Node.js project like RR Skillverse would use:
# Dependencies -- regenerated from package.json with npm install node_modules/ # Environment variables -- contains database credentials and API keys .env .env.local # Build output -- generated from source at build time dist/ # Operating system artifacts .DS_Store Thumbs.db
Create .gitignore before running git add . — not after. If you stage everything first, Git queues files you meant to exclude. You'll have to unstage them manually. The .gitignore only prevents files from being staged in the first place; it does not automatically remove files that are already committed.
🎯 Quick Check
Q1: You've modified auth.js for a bug fix and dashboard.js for a new feature. How do you commit them as two separate commits?
Show Answer
Stage only auth.js with git add auth.js and commit it. Then run git add dashboard.js and commit it separately. The staging area lets you compose precise commits even when multiple files have changed — this is exactly what it's designed for.
Q2: What happens if you delete the .git folder from a repository?
Show Answer
All Git history is lost. The files themselves survive — Git does not move or duplicate your working files; it only tracks them. But without .git, Git no longer knows about any commits, branches, or configuration for that folder. The folder becomes an ordinary folder again. This is why .git is the single most important thing to never accidentally delete.
Q3: In the RR Skillverse .gitignore, why is node_modules/ excluded but package.json is tracked?
Show Answer
package.json describes which packages to install — it's the source of truth that any developer or CI server uses to regenerate node_modules/ with npm install. Committing node_modules/ would add hundreds of megabytes of generated files that change with every install, making the repo slow to clone and diffs impossible to read. The rule: commit the recipe, not the baked result.
Key Takeaways
- A repository is any folder containing a
.gitsubfolder — delete.gitand you lose all history - Set
git config --global user.nameanduser.emailonce per machine before your first commit - The staging area exists so you can compose precise commits from a messy working state
git addmoves changes into the queue;git committakes the permanent snapshot- Create
.gitignorebefore staging — excludenode_modules/and.envfrom the very first commit