You just spent 3 hours writing code. You got your scraper working perfectly. It extracts data, cleans it, saves to CSV. Beautiful.
Then you think: "Let me add one more feature."
You start editing. Change this function. Modify that loop. Delete some lines. Add new ones. After 30 minutes, nothing works. Errors everywhere. You can't remember what you changed. You can't undo it all manually.
You try Ctrl+Z. It only goes back 10 changes. You need to go back 50 changes. Your perfect working code is gone. You'll have to rewrite everything from scratch.
This is the moment you discover Git.
Git is a time machine for your code. You create save points (commits). When things break, you jump back to any save point. Your code is exactly how it was before you broke it.
You don't need to understand how Git works internally. You don't need to know about directed acyclic graphs or SHA-1 hashes. You just need to know: save point, go back to save point. That's it.
Let me show you.
What Git Actually Does (The Simple Version)
Forget everything you've heard about version control systems and distributed repositories. Here's what Git does:
Git takes snapshots of your project folder.
That's it. Really.
Every time you tell Git "save this," it takes a snapshot of your entire project. Later, you can say "show me how my project looked on Tuesday" and Git shows you that exact snapshot.
Think of it like this:
You're writing a book. Every day, you make a copy of your entire manuscript and label it with the date.
- Monday copy: 50 pages
- Tuesday copy: 52 pages
- Wednesday copy: 48 pages (deleted 4 bad pages)
- Thursday copy: 55 pages (added 7 new pages)
If Thursday's writing is terrible, you can throw it away and go back to Wednesday's copy. Or Tuesday's. Or Monday's. You have every version.
Git does this for code. Except instead of physical copies, it's digital snapshots. And you choose when to create snapshots (not automatically every day).
What Git is NOT:
- Not a backup service (that's what GitHub does, we'll cover that in blog 2)
- Not automatic (you decide when to save)
- Not complicated (just 5 commands cover 90% of your needs)
- Not scary (you literally cannot lose code with Git)
Installing Git
Let's get Git on your computer.
Windows
Download from git-scm.com
Run the installer. Click Next on everything. Default options are fine.
Open Command Prompt and type:
git --version
You should see something like git version 2.43.0.
Mac
Git is probably already installed. Check:
git --version
If not installed:
# Using Homebrew (recommended)
brew install git
# Or download from git-scm.com
Linux
# Ubuntu/Debian
sudo apt-get install git
# Fedora
sudo dnf install git
# Check it worked
git --version
Setting Up Git (Do This Once)
Tell Git who you are. This gets attached to every save point you create.
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
That's it. You're ready.
Your First Git Project
Let's create a simple Python project and use Git to track it.
Step 1: Create a Project Folder
# Create folder
mkdir my_scraper
cd my_scraper
# Create a simple Python file
echo "print('Hello, Git!')" > scraper.py
You now have a folder with one file.
Step 2: Initialize Git
git init
Output:
Initialized empty Git repository in /Users/you/my_scraper/.git/
This creates a hidden .git folder. Git stores all its snapshots there. Don't touch that folder. Just know it exists.
Step 3: Check Status
git status
Output:
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
scraper.py
nothing added to commit but untracked files present (use "git add" to track)
Git sees your file but isn't tracking it yet.
Step 4: Add File to Staging
git add scraper.py
Now check status again:
git status
Output:
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: scraper.py
The file is now "staged" (ready to be saved in a snapshot).
Step 5: Create Your First Commit (Save Point)
git commit -m "Initial commit: created scraper.py"
Output:
[main (root-commit) a1b2c3d] Initial commit: created scraper.py
1 file changed, 1 insertion(+)
create mode 100644 scraper.py
You just created your first snapshot!
The -m flag means "message". Always write a short description of what you changed.
Making Changes and Committing
Let's modify the file and create another snapshot.
Edit the File
# Add more code
echo "print('Scraping data...')" >> scraper.py
echo "print('Done!')" >> scraper.py
Check What Changed
git status
Output:
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: scraper.py
no changes added to commit (use "git add" and/or "git commit -a")
Git knows you changed the file.
See Exactly What Changed
git diff
Output:
diff --git a/scraper.py b/scraper.py
index abc123..def456 100644
--- a/scraper.py
+++ b/scraper.py
@@ -1 +1,3 @@
print('Hello, Git!')
+print('Scraping data...')
+print('Done!')
Lines with + are additions. Lines with - would be deletions.
Commit the Changes
git add scraper.py
git commit -m "Added scraping and completion messages"
You now have two snapshots:
- Original version (just "Hello, Git!")
- Updated version (with scraping messages)
Viewing Your History
git log
Output:
commit b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1
Author: Your Name <your.email@example.com>
Date: Tue Mar 15 14:32:10 2024 +0000
Added scraping and completion messages
commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
Author: Your Name <your.email@example.com>
Date: Tue Mar 15 14:28:05 2024 +0000
Initial commit: created scraper.py
You can see all your snapshots with dates and messages.
Better log format:
git log --oneline
Output:
b2c3d4e Added scraping and completion messages
a1b2c3d Initial commit: created scraper.py
Much cleaner.
Going Back in Time
This is where Git becomes magic.
Scenario: You Broke Everything
Let's simulate breaking your code:
# Overwrite the file with garbage
echo "This is broken code!!!" > scraper.py
# Check what you did
cat scraper.py
Output:
This is broken code!!!
Oh no. Your working code is gone.
Option 1: Undo Uncommitted Changes
If you haven't committed yet, just throw away your changes:
git restore scraper.py
Check the file:
cat scraper.py
Output:
print('Hello, Git!')
print('Scraping data...')
print('Done!')
Your code is back! Git restored it from the last snapshot.
Option 2: Go Back to an Old Commit
Let's say you committed the broken code. You want to go back to an earlier snapshot.
First, commit the broken code (just for this example):
git add scraper.py
git commit -m "Broke everything (example)"
Now view your log:
git log --oneline
Output:
c3d4e5f Broke everything (example)
b2c3d4e Added scraping and completion messages
a1b2c3d Initial commit: created scraper.py
You want to go back to commit b2c3d4e (the working version).
git checkout b2c3d4e
Check your file:
cat scraper.py
Output:
print('Hello, Git!')
print('Scraping data...')
print('Done!')
You're back in time! The file looks exactly like it did at that commit.
Important: This puts you in "detached HEAD" state. Don't worry about what that means. Just remember: you're looking at an old snapshot, not editing the current one.
Going Back to Present
git checkout main
This takes you back to the latest snapshot (the "main" branch, which we'll explain more in blog 3).
The 5 Commands You'll Use 90% of the Time
Forget everything else. Master these five commands:
1. git status
Shows what changed since last commit.
git status
Use this constantly. Before every commit. After every commit. When confused. Always.
2. git add <filename>
Stages a file for committing.
# Add one file
git add scraper.py
# Add all changed files
git add .
3. git commit -m "message"
Creates a snapshot with a description.
git commit -m "Fixed bug in price extraction"
Good commit messages:
- "Added login function"
- "Fixed crash when URL is invalid"
- "Updated requirements.txt"
Bad commit messages:
- "stuff"
- "changes"
- "fixed it"
4. git log
Shows history of commits.
# Detailed log
git log
# One-line log (better)
git log --oneline
# Last 5 commits
git log --oneline -5
5. git diff
Shows what changed.
# See unstaged changes
git diff
# See staged changes
git diff --cached
# See changes in a specific file
git diff scraper.py
That's it. You can do 90% of your Git work with just these 5 commands.
Real Example: Building a Scraper
Let's use Git while building an actual scraper.
Step 1: Initialize Project
mkdir price_scraper
cd price_scraper
git init
Step 2: Create Basic Structure
# Create files
touch scraper.py
touch requirements.txt
# scraper.py
import requests
from bs4 import BeautifulSoup
url = 'https://example.com/products'
response = requests.get(url)
soup = BeautifulSoup(response.content, 'html.parser')
print('Scraper initialized')
# requirements.txt
requests==2.31.0
beautifulsoup4==4.12.2
Step 3: First Commit
git add .
git commit -m "Initial scraper setup with dependencies"
Step 4: Add Product Extraction
# scraper.py (updated)
import requests
from bs4 import BeautifulSoup
url = 'https://example.com/products'
response = requests.get(url)
soup = BeautifulSoup(response.content, 'html.parser')
# Extract products
products = []
for item in soup.select('.product'):
name = item.select_one('.name').text
price = item.select_one('.price').text
products.append({'name': name, 'price': price})
print(f'Found {len(products)} products')
Step 5: Commit the Feature
git add scraper.py
git commit -m "Added product extraction logic"
Step 6: Add Data Saving
# scraper.py (updated)
import requests
from bs4 import BeautifulSoup
import json
url = 'https://example.com/products'
response = requests.get(url)
soup = BeautifulSoup(response.content, 'html.parser')
products = []
for item in soup.select('.product'):
name = item.select_one('.name').text
price = item.select_one('.price').text
products.append({'name': name, 'price': price})
# Save to file
with open('products.json', 'w') as f:
json.dump(products, f, indent=2)
print(f'Saved {len(products)} products to products.json')
Step 7: Commit the Save Feature
git add scraper.py
git commit -m "Added JSON export functionality"
Step 8: View Your Progress
git log --oneline
Output:
d4e5f6g Added JSON export functionality
c3d4e5f Added product extraction logic
b2c3d4e Initial scraper setup with dependencies
You have a complete history of how you built the scraper.
Step 9: Something Breaks
Let's say the JSON export causes an error. You want to go back to the version that worked (before you added saving).
# Go back to commit c3d4e5f
git checkout c3d4e5f scraper.py
Your scraper is now back to the version without JSON export. It works again.
Step 10: Recommit or Keep Going
# If you want to keep the old version
git commit -m "Reverted to version without JSON export"
# Or if you want to try fixing the JSON issue again
# Just edit the file and commit when working
Common Mistakes (And How to Fix Them)
Mistake 1: Forgot to Commit
You made changes. Closed your laptop. Came back. Can't remember what you changed.
Fix:
# See what changed
git diff
# If changes are good, commit them
git add .
git commit -m "Describe what you changed"
Mistake 2: Committed Too Early
You committed but forgot to add a file.
Fix:
# Add the forgotten file
git add forgotten_file.py
# Amend the last commit (adds this file to it)
git commit --amend --no-edit
Mistake 3: Bad Commit Message
You wrote "stuff" as your commit message. Not helpful.
Fix:
# Change the last commit message
git commit --amend -m "Better commit message here"
Mistake 4: Want to Undo Last Commit
You committed something you shouldn't have.
Fix:
# Undo the commit but keep your changes
git reset HEAD~1
# Now your files still have the changes, but the commit is gone
# You can edit more and commit again
Mistake 5: Accidentally Deleted a File
You deleted a file and want it back.
Fix:
# Restore the file from last commit
git restore deleted_file.py
What to Commit (And What Not To)
DO Commit:
- Source code files (.py, .js, .html, etc.)
- Configuration files (requirements.txt, package.json)
- Documentation (README.md, docs/)
- Scripts (shell scripts, automation)
DO NOT Commit:
- Passwords or API keys
- Large data files (CSVs, databases)
- Dependencies (node_modules/, venv/)
- Compiled files (.pyc, .exe)
- OS files (.DS_Store, Thumbs.db)
Why not commit these?
- Passwords: Security risk
- Large files: Git gets slow, wastes space
- Dependencies: Can be reinstalled from requirements.txt
- Compiled files: Generated automatically
- OS files: Irrelevant to the project
We'll cover .gitignore files in blog 4 to automatically exclude these.
Checking Out Your Work
Let's review what Git does for you every day.
Morning routine:
# Check where you are
git status
# See what you did yesterday
git log --oneline -5
While working:
# Made progress? Save it.
git add .
git commit -m "Implemented login scraper"
# Broke something? Undo it.
git restore broken_file.py
# Want to see changes?
git diff
End of day:
# Commit your work
git add .
git commit -m "End of day: added error handling"
# Review what you accomplished
git log --oneline --since="1 day ago"
Next day:
# Pick up where you left off
git log --oneline -3 # Remind yourself what you did
Git tracks everything. You never lose work. You always know what changed.
Quick Reference
Setup (once)
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
Starting a project
git init
Daily workflow
# Check status
git status
# Add files
git add filename.py
git add . # Add all
# Commit
git commit -m "Description of changes"
# View history
git log --oneline
# See changes
git diff
Undoing things
# Undo uncommitted changes
git restore filename.py
# Undo last commit (keep changes)
git reset HEAD~1
# Go back to old commit
git checkout <commit-hash>
git checkout main # Return to present
What's Next?
You now know local Git. Your code is safe. You can save snapshots and go back in time.
But what if:
- Your hard drive dies?
- You want to work from multiple computers?
- You want to share your code?
- You want to collaborate with others?
That's where GitHub comes in. GitHub is your code's cloud backup. It's also a social network for code.
In blog 2, we'll cover:
- Creating a GitHub account
- Pushing your local Git projects to the cloud
- Cloning projects to other computers
- Making your code public (or keeping it private)
- Using GitHub as a portfolio
You already know Git. GitHub is just Git + cloud storage + social features.
Summary
Git is a time machine for your code. You create save points (commits). When things break, you jump back.
The 5 commands you need:
-
git status- What changed? -
git add- Stage files for commit -
git commit -m "message"- Create save point -
git log- View history -
git diff- See exact changes
The workflow:
- Make changes to your files
git add .git commit -m "What you did"- Repeat
When things break:
- Uncommitted changes:
git restore filename - Need old version:
git checkout <commit-hash> - Wrong commit:
git reset HEAD~1
You don't need to understand Git's internal workings. You just need to use it. Save often. Write clear commit messages. Never lose code again.
Git isn't complicated. It's just snapshots. Create them. Go back to them. That's all Git does.
Next up: Blog 2 - "GitHub: Your Code's Cloud Backup (And Social Network)"
We'll take your local Git knowledge and put it in the cloud. Your code will be safe even if your computer explodes. Plus, you'll have a portfolio to show employers.
Resources:
- Official Git documentation: https://git-scm.com/doc
- Git cheat sheet: https://education.github.com/git-cheat-sheet-education.pdf
- Practice Git: https://learngitbranching.js.org/
Top comments (0)