🌱 Phase 1 · Foundations 🟢 Beginner MODULE 03

Git Basics: Your First Repository

⏱️ 35 min
💻 Hands-on Coding
🧩 5 Quiz Questions
🏗️ 1 Challenge
Course progress33%
🎯 What you'll learn: The core Git workflow — init, status, add, commit, log, and diff. How to write great commit messages using Conventional Commits. How to use .gitignore to keep your repo clean. You'll do a full hands-on walkthrough creating a real project with 5 commits.

The Core Git Workflow

Every Git project follows the same basic cycle. Once you learn these 5 commands, you can manage any project with Git. Let's build a real project from scratch.

Creating Your First Repository

Terminal — Start a New Project
BASH
# Create a new project directory
mkdir my-first-repo
cd my-first-repo

# Initialize Git — creates a hidden .git folder
git init
# Output: Initialized empty Git repository in .../my-first-repo/.git/

# Check the status of your repo
git status
# Output: On branch main. No commits yet. Nothing to commit.
📁
What is the .git folder?
When you run git init, Git creates a hidden .git/ folder in your project. This folder IS your repository — it stores the entire history of every commit, branch, tag, and configuration. Never manually edit or delete this folder.

git add & git commit

These two commands form the heart of Git. git add moves changes to the Staging Area. git commit saves the staged changes as a permanent snapshot.

Your first commit walkthrough
BASH
# Create a file
echo "# My Project" > README.md

# Check status — README.md is "untracked"
git status

# Stage the file
git add README.md
# Or stage ALL changes at once:
git add .

# Check status again — file is now "staged"
git status

# Commit with a message
git commit -m "feat: add README with project description"

# See your commit in the log
git log
CommandWhat it does
git add filenameStage a specific file
git add .Stage ALL changed files in the current directory
git add -pInteractively stage specific chunks (advanced)
git commit -m "msg"Commit staged changes with a message
git commit --amendEdit the last commit message (use carefully)
git rm --cached fileUnstage a file that was already tracked

git log — Viewing History

After a few commits, you'll want to see your project history. git log shows every commit: who made it, when, and what the message was.

Different log formats
BASH
# Full log — shows hash, author, date, message
git log

# Compact — one line per commit
git log --oneline

# Compact + visual branch graph
git log --oneline --graph --all

# Show last 5 commits only
git log -5

# Search commits by message
git log --grep="feat"

# Show commits by a specific author
git log --author="Your Name"
💡
Commit hashes
Every commit gets a unique 40-character hash like a3f8c2e1d9b.... You can refer to any commit by its first 7 characters: a3f8c2e. You'll use hashes when reverting, cherry-picking, or resetting.

git diff — Seeing Changes

Before committing, you often want to see exactly what changed. git diff shows you line-by-line differences.

Diff commands
BASH
# See unstaged changes (Working Directory vs Staging)
git diff

# See staged changes (Staging vs last commit)
git diff --staged

# See changes between two commits
git diff abc1234 def5678

# See changes in a specific file
git diff README.md

# Diff output legend:
# Lines starting with + are ADDED (green)
# Lines starting with - are REMOVED (red)
# Lines with no prefix are unchanged (context)

Writing Great Commit Messages

A commit message is a permanent record of why a change was made. Bad messages like "fix" or "update" are useless 6 months later. Good messages make you and your team vastly more productive.

Conventional Commits Standard

Conventional Commits is the industry standard format: type(scope): description

Conventional Commit examples
FORMAT
# Format: type(scope): short description

feat: add user authentication system
feat(auth): add Google OAuth login
fix: resolve null pointer in payment flow
fix(cart): prevent negative quantity bug
docs: update API documentation
chore: upgrade dependencies to latest versions
style: format code with prettier
refactor: extract validation logic into helper
test: add unit tests for UserService
perf: optimize database query with index
📏
The 50/72 rule
Subject line: 50 characters max. Keep it short, imperative mood ("add feature" not "added feature").
Body: 72 characters per line max. Explain the WHY, not the what. Wrap at 72 chars for terminal readability.
Imperative mood: Write as if giving a command. "Fix bug" not "Fixed bug" or "Fixes bug".

.gitignore — What to Ignore

Not every file should be tracked by Git. Dependencies, build artifacts, secrets, and OS-generated files should be excluded. The .gitignore file tells Git which files and folders to skip.

.gitignore — Common patterns
.gitignore
# Dependencies
node_modules/
vendor/

# Environment variables (NEVER commit secrets!)
.env
.env.local
.env.production

# Python
__pycache__/
*.pyc
*.pyo
.venv/
venv/

# Build outputs
dist/
build/
*.min.js

# OS files
.DS_Store        # Mac
Thumbs.db        # Windows
desktop.ini

# IDE settings
.vscode/
.idea/
*.swp
🔐
NEVER commit .env files or secrets
API keys, database passwords, and tokens committed to a public GitHub repo are discovered by bots within minutes. Always add .env to .gitignore BEFORE your first commit. If you accidentally commit a secret, revoke it immediately — even deleted commits may exist in GitHub's systems.

Pro tip: Visit gitignore.io to auto-generate .gitignore files for any language or framework.

Full Hands-on Walkthrough: 5 Commits

Let's put it all together in a realistic project walkthrough. Follow along in your terminal.

Complete project walkthrough — 5 commits
BASH
# 1. Create and init project
mkdir todo-app && cd todo-app
git init

# 2. Create .gitignore FIRST
echo "node_modules/\n.env\n.DS_Store" > .gitignore
git add .gitignore
git commit -m "chore: add .gitignore"

# 3. Add README
echo "# Todo App\nA simple task manager." > README.md
git add README.md
git commit -m "docs: add README with project overview"

# 4. Create main file
echo "const todos = [];" > app.js
git add app.js
git commit -m "feat: initialize app with empty todos array"

# 5. Add a feature
echo "function addTodo(text) { todos.push({text, done: false}); }" >> app.js
git add app.js
git commit -m "feat: add addTodo function"

# 6. Fix something
# (edit app.js to add validation)
git add app.js
git commit -m "fix: validate empty string in addTodo"

# See your beautiful history!
git log --oneline
🧩 Knowledge Check — Lesson 3
Test your Git basics. 5 questions with instant feedback.
1. What command initializes a new Git repository?
2. What is the difference between git add . and git commit?
3. According to Conventional Commits, what type prefix should a bug fix use?
4. What should you put in .gitignore?
5. Which command shows the difference between staged changes and the last commit?
💻
Coding Challenge — Lesson 3
Hands-on Git practice · Beginner
Challenge: Create a Local Repo with 5 Meaningful Commits

Create a new project folder for something you're working on or interested in (a portfolio site, a small script, a notes app). Then:

1. Run git init
2. Create a .gitignore file with relevant patterns → commit: chore: add .gitignore
3. Create a README.md describing the project → commit: docs: add README
4. Create your first source file → commit: feat: initialize [project name]
5. Add a feature or section → commit: feat: add [feature name]
6. Make an improvement → commit: refactor: improve [something]

After all 5 commits, run git log --oneline and verify all 5 messages follow Conventional Commits format.
💡 Show hints
  • Use git status after every step to see what Git sees
  • Stage files with git add . then commit with git commit -m "message"
  • Conventional Commits types: feat, fix, docs, chore, style, refactor, test, perf
  • Use git log --oneline to review your commit history at the end
Finished this lesson?
Mark it complete to track your progress.
🎉

Lesson 3 Complete!

You can create repos, make commits, and write great messages. Time to learn the superpower of Git — branches!

Lesson 03 of 09Git & GitHub Mastery