What Is a Git Commit and Why Do You Need It? 📸

A commit is a saved snapshot of your project at a specific point in time — like a save point in a video game!

What Is a Commit

In Simple Terms

Imagine you’re writing a book:

• Without Git: You write all day, your computer crashes, and all the text is lost 😱
• With Git commits: Every 30 minutes you make a “save” → you can roll back to any point ✅

Commit = checkpoint in your code!

What’s Stored in a Commit?

Every commit contains:

1. Snapshot of files — a full snapshot of the project
2. Author — who made the changes
3. Date and time — when it was done
4. Message — what changed (commit message)
5. Unique ID — hash (e.g.: a1b2c3d...)
6. Reference to parent — the previous commit

It’s like a photograph:
- A snapshot of the moment ✅
- With date and signature ✅
- Can be viewed later ✅

Why Do You Need Commits?

1. Change History 📜

# You can see EVERYTHING that happened:
commit a1b2c3d
Author: Ivan
Date: April 10, 4:30 PM
fix: fix auth bug

commit x7y8z9w
Author: Maria
Date: April 10, 2:15 PM
feat: add registration form

You can answer questions like:
- Who wrote this code?
- When was this feature added?
- Why was this file changed?

2. Reverting Changes ⏮️

Imagine:
- Added a new feature → everything broke
- With commits: roll back 1 hour → everything works!

# One command — and you're back in time
git checkout previous-commit

Without commits: Ctrl+Z won’t help once you’ve closed the editor!

3. Team Collaboration 👥

The problem:
- You’re working on app.py
- A colleague is also changing app.py
- How do you combine?

The solution — commits!
- Each person makes their own commits
- Git knows how to merge
- Conflicts are resolved transparently

4. Code Backup 💾

Commits on GitHub = cloud backup:
- Your computer burns down — code is safe ✅
- Accidentally deleted a file — restored ✅
- Virus encrypted the drive — clone from GitHub ✅

Commit in Detail

Commit vs Saving a File

Takeaway: Ctrl+S saves the file, Git commit saves a MOMENT in the project’s history!

Example Commit

# 1. Changed the file
echo "print('Hello')" > app.py

# 2. Added to staging
git add app.py

# 3. Made a commit
git commit -m "feat: add greeting function"

# Result:
[main a1b2c3d] feat: add greeting function
1 file changed, 1 insertion(+)

What happened:
1. Git took a snapshot of the current state
2. Recorded it in history with your message
3. Assigned unique ID a1b2c3d

Anatomy of a Commit

git log

Shows:

commit a1b2c3d4e5f6g7h8i9j0  ← Unique hash
Author: Ivan Ivanov <ivan@example.com>  ← Who
Date:   Thu Apr 10 16:30:00 2026 +0300  ← When

    feat: add registration form  ← What (commit message)

    - Created /register page
    - Email and password validation
    - Database integration

How to Commit Correctly

How Often to Commit?

✅ Good practice:

1 commit = 1 logical change

Examples:
- Fixed a bug → commit
- Added a feature → commit
- Updated README → commit
- Refactored a function → commit

Rule of thumb: every 30-60 minutes of work or after completing a task

❌ Bad practice:

Too rarely:

# Worked for a week → 1 giant commit
git commit -m "done"  # 150 files changed!

Problems:
- Impossible to understand what changed
- Can’t partially revert
- Code review is a nightmare

Too often:

git commit -m "added 1 line"  # × 50 times per hour

Problems:
- History is polluted
- Hard to find the change you need

The sweet spot:

# Monday
git commit -m "feat: add user model"
git commit -m "feat: create login form"
git commit -m "fix: fix email validation"

# = 3 clear commits for the day

What NOT to Commit?

❌ Never:
- Passwords, API keys, tokens
- .env file with secrets
- node_modules/, __pycache__/
- Large binary files (videos, archives)
- Temp files, logs

Use .gitignore!

Commits and GitHub

Local commits:
- Made on your computer
- Nobody sees them yet
- Can be changed/deleted

After push:
- Commits are on GitHub
- Visible to the entire team
- Harder to change (requires force push)

Visualization and Tools

Visual Representation

Time →

[Commit 1]     [Commit 2]     [Commit 3]     [Commit 4]
  Init           Add login      Fix bug       Add docs
    ↓                ↓              ↓              ↓
main──●──────────●──────────●──────────●─────────→

Each ● = a commit = a point in the project’s history!

You can jump to any of them:

git checkout Commit-2  # returned to the "Add login" moment

Commits in GitHub Desktop

Visual process:

1. Changes — see modified files
2. Diff — see what exactly changed (green/red)
3. Summary — write commit message
4. Commit to main — snapshot the moment!
5. Push — send to GitHub

Clear and visual! 🎨

Best Practices and Career

Best Practices

✅ DO:
- Commit frequently (every 30-60 minutes)
- Write clear messages
- One commit = one task
- Review diff before committing
- Commit working code

❌ DON’T:
- Giant commits (100+ files)
- Commit broken code
- Meaningless messages (“update”, “fix”)
- Commit secrets and passwords
- Commit temp files

Why This Matters for Your Career

Employers look at:

1. GitHub profile — how many commits, how often
2. Commit quality — clear messages
3. Project history — code evolution
4. Contributions — contributions to open source

Good commits = a mark of a professional! 💼

Conclusion

Commit = save point in a game:
- Checkpoint in code ✅
- Can roll back ✅
- Full history of all changes ✅
- Backup on the server (GitHub) ✅

Start small:
1. Worked 30-60 minutes → commit
2. Fixed a bug → commit
3. Added a feature → commit
4. Updated documentation → commit

Remember: Git commits are a time machine for your code! ⏰

Next step: learn how to write proper commit messages! ✍️