Your First Git Repository

Now that you have Git installed and configured, it's time to create your first repository and make your first commit! In this lesson, you'll learn the fundamental Git workflow that you'll use every day as a developer: initializing a repository, staging changes, and creating commits. By the end, you'll have a real Git repository with tracked changes and understand how to save snapshots of your work.

What is a Repository?

A repository (often shortened to "repo") is a folder that Git is tracking. Inside this folder, Git monitors all changes to your files and maintains a complete history of everything that's happened.

Think of a repository as:

A regular folder containing your project files (code, images, documents, etc.)
Plus a hidden .git folder that stores all the version control magic
The complete timeline of every change you've saved (committed)

The .git Folder: When you initialize a Git repository, Git creates a hidden .git folder in your project directory. This folder contains all the repository data—commits, branches, history, configuration, etc. You should never manually edit files in this folder! Git manages it for you.

👁️ Viewing Hidden Files

The .git folder is hidden by default. To see it:

Windows: In File Explorer, go to View → Options → View tab → Show hidden files
Mac: In Finder, press Cmd + Shift + . to toggle hidden files
Linux: In your file manager, press Ctrl + H or use ls -a in terminal

Step 1: Create a Project Folder

First, let's create a new folder for our first project. We'll keep it simple with a basic website.

Using the Terminal

Open your terminal and run these commands:

BASH

# Navigate to where you want to create your project
# For example, your Documents folder or a dedicated projects folder
cd ~/Documents

# Create a new folder for your project
mkdir my-first-repo

# Navigate into the new folder
cd my-first-repo

# Verify you're in the right place
pwd

The pwd (print working directory) command shows your current location. You should see something like /Users/yourname/Documents/my-first-repo

Using File Explorer/Finder (Alternative Method)

If you prefer, you can create the folder using your operating system's file manager:

Open File Explorer (Windows) or Finder (Mac)
Navigate to where you want your project
Create a new folder called my-first-repo
Open your terminal and navigate to this folder:

BASH

cd path/to/my-first-repo

📁 Project Organization Tip

It's a good idea to keep all your projects in one dedicated folder. Many developers create a projects or code folder in their home directory to keep everything organized!

Step 2: Initialize a Git Repository

Now we'll tell Git to start tracking this folder. This is done with the git init command.

BASH

git init

You should see output similar to:

BASH

Initialized empty Git repository in /Users/yourname/Documents/my-first-repo/.git/

Congratulations! You've just created your first Git repository! Git is now watching this folder and is ready to track changes.

What Just Happened?

When you ran git init, Git:

Created a hidden .git folder in your directory
Set up all the necessary structure for version control
Created an initial branch (usually called "main")
Prepared the repository to track files

Your folder is now a Git repository, but it doesn't have any commits yet. Let's fix that!

Step 3: Check Repository Status

One of the most useful Git commands is git status. It tells you what's happening in your repository at any moment.

BASH

git status

You'll see something like:

BASH

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

This output tells us:

We're on the main branch (more on branches later)
We haven't made any commits yet
There are no files to track

💡 Use Git Status Frequently!

Get in the habit of running git status often. It helps you understand what state your repository is in and what Git thinks about your files. Most developers run this command dozens of times per day!

Step 4: Create Some Files

Let's create a couple of files so we have something to track. We'll make a simple README file and an HTML file.

Method 1: Using Terminal

BASH

# Create a README file
echo "# My First Repository" > README.md
echo "This is my first project using Git!" >> README.md

# Create an HTML file
echo "<!DOCTYPE html>" > index.html
echo "<html>" >> index.html
echo "<head><title>My First Repo</title></head>" >> index.html
echo "<body><h1>Hello, Git!</h1></body>" >> index.html
echo "</html>" >> index.html

Method 2: Using a Text Editor

Alternatively, create these files using your favorite text editor:

README.md:

README.md

# My First Repository

This is my first project using Git!

## What I'm Learning
- How to initialize a Git repository
- How to stage and commit changes
- How to track my project history

index.html:

index.html

<!DOCTYPE html>
<html>
<head>
    <title>My First Repo</title>
</head>
<body>
    <h1>Hello, Git!</h1>
    <p>This is my first project tracked with Git.</p>
</body>
</html>

Now run git status again:

BASH

git status

You'll see:

BASH

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md
        index.html

nothing added to commit but untracked files present (use "git add" to track)

Git sees your new files! They're listed as "untracked" because we haven't told Git to start tracking them yet.

Understanding the Staging Area

Before we commit files, we need to understand Git's three-stage workflow:

The Three States of Git

Working Directory: Where you actually work on files. This is your normal project folder.
Staging Area (Index): A preparation area where you add changes you want to include in the next commit.
Repository (.git directory): Where Git permanently stores committed snapshots.

The workflow looks like this:

TEXT

Working Directory  →  Staging Area  →  Repository
   (modified)         (staged)         (committed)
      
   git add →           git commit →

Why Have a Staging Area?

The staging area gives you fine control over what goes into each commit. You might have:

Made changes to 5 files
But only want to commit 3 of them
Because they're related to one specific feature

You can stage just those 3 files, commit them with a clear message, then stage and commit the other 2 separately with a different message. This keeps your history clean and organized!

🎯 Think of Staging as Shopping Cart

Think of the staging area like a shopping cart. You browse the store (working directory), add items to your cart (staging area), then check out (commit). You can add or remove items from your cart before checking out, giving you complete control over what's in your purchase (commit).

Step 5: Stage Your Changes

Now let's add our files to the staging area using git add.

Adding Individual Files

You can add files one at a time:

BASH

git add README.md

Check the status:

BASH

git status

You'll see:

BASH

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        index.html

README.md is now in the staging area (ready to be committed), while index.html is still untracked.

Adding All Files at Once

Instead of adding files individually, you can stage everything:

BASH

git add .

The dot (.) means "add everything in the current directory and subdirectories."

Now check status again:

BASH

git status

Both files are now staged:

BASH

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md
        new file:   index.html

Be Careful with 'git add .'

While git add . is convenient, make sure you actually want to stage everything. Always run git status first to see what will be added!

Step 6: Make Your First Commit

Now that your changes are staged, you can create a commit—a permanent snapshot of your project at this moment.

BASH

git commit -m "Initial commit - Add README and index page"

You'll see output like:

BASH

[main (root-commit) a1b2c3d] Initial commit - Add README and index page
 2 files changed, 15 insertions(+)
 create mode 100644 README.md
 create mode 100644 index.html

Congratulations! You've made your first commit! Git has now saved a permanent snapshot of your project.

Understanding the Commit Command

git commit - The command to create a commit
-m - Flag for "message" (lets you include your message directly)
"Initial commit..." - Your commit message describing what changed

About the Output

Let's understand what Git told us:

[main (root-commit) a1b2c3d] - You're on the main branch, this is your first commit, and a1b2c3d is the commit hash (unique ID)
2 files changed, 15 insertions(+) - You created 2 files with 15 total lines
Shows which files were created or modified

Writing Good Commit Messages

Commit messages are incredibly important. They're how you (and others) understand what changed and why. Here are best practices:

Good Commit Message Structure

TEXT

Short summary (50 characters or less)

More detailed explanation if needed (wrap at 72 characters).
Explain what changed and why, not how (the code shows how).

- You can use bullet points
- To list multiple changes
- Or explain context

Examples of Good vs Bad Messages

Bad Commit Messages:

"fix"
"update"
"changes"
"asdfasdf"
"Finally works!!!"

These messages don't tell you anything useful!

Good Commit Messages:

"Add user authentication with JWT tokens"
"Fix navigation menu overflow on mobile"
"Update homepage hero section with new brand colors"
"Remove deprecated API endpoints"
"Add error handling for network failures"

These messages clearly describe what changed!

Commit Message Guidelines

Use the imperative mood: "Add feature" not "Added feature" (think of it as giving a command)
Be specific but concise: Explain what and why, not how
Start with a capital letter: "Fix bug" not "fix bug"
No period at the end: Unless it's a full sentence in the body
Limit the summary to 50 characters: Keep it short and scannable

📝 Future You Will Thank You

Good commit messages are like notes to your future self. When you come back to a project six months later trying to figure out why something changed, clear commit messages will save you hours of confusion!

Step 7: View Your Commit History

Now that you have a commit, let's look at your project history using git log.

BASH

git log

You'll see:

BASH

commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> main)
Author: Your Name <your.email@example.com>
Date:   Sat Jan 3 2026 14:30:00

    Initial commit - Add README and index page

This shows you:

Commit hash: The unique identifier for this commit (usually abbreviated)
Author: Who made the commit (that's you!)
Date: When the commit was made
Message: The commit message you wrote
(HEAD -> main): This is where you currently are in your project's timeline

Useful Log Variations

Compact one-line format:

BASH

git log --oneline

Show last 3 commits:

BASH

git log -3

Show file changes in each commit:

BASH

git log --stat

Show visual branch graph (more useful later):

BASH

git log --oneline --graph --all

🔍 Exiting Git Log

If git log opens a pager (you can't type new commands), press Q to quit and return to your normal terminal prompt.

The Complete Git Workflow

Let's practice the complete workflow by making more changes.

Make Some Changes

Edit your index.html file to add more content:

index.html

<!DOCTYPE html>
<html>
<head>
    <title>My First Repo</title>
</head>
<body>
    <h1>Hello, Git!</h1>
    <p>This is my first project tracked with Git.</p>
    
    <!-- New content added -->
    <h2>What I've Learned</h2>
    <ul>
        <li>How to initialize a repository</li>
        <li>How to stage changes with git add</li>
        <li>How to commit changes with meaningful messages</li>
    </ul>
</body>
</html>

Also create a new file called styles.css:

styles.css

body {
    font-family: Arial, sans-serif;
    max-width: 800px;
    margin: 0 auto;
    padding: 20px;
    background-color: #f5f5f5;
}

h1 {
    color: #333;
}

Check What Changed

BASH

git status

You'll see:

BASH

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:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        styles.css

no changes added to commit (use "git add" and/or "git commit -a")

Git detected that index.html was modified and there's a new file styles.css.

See Exactly What Changed

Use git diff to see the exact changes:

BASH

git diff

This shows you line-by-line what was added (green, with +) or removed (red, with -).

Stage the Changes

BASH

git add index.html styles.css

# Or stage everything at once
git add .

Commit with a Good Message

BASH

git commit -m "Add CSS styling and expand homepage content"

View Your History

BASH

git log --oneline

You'll now see two commits:

BASH

b2c3d4e Add CSS styling and expand homepage content
a1b2c3d Initial commit - Add README and index page

Perfect! You've now completed the full Git workflow multiple times. This is the cycle you'll repeat hundreds of times as a developer:

Make changes to files
Check status with git status
Stage changes with git add
Commit with git commit -m "message"
View history with git log

Practice Git Commands

Here's an interactive playground to practice the commands you've learned:

Practice Your Git Workflow

Try these common Git commands

Try these examples:

Common Mistakes and How to Fix Them

Mistake 1: Forgot to Stage Files Before Committing

Problem: You run git commit but nothing happens or Git says "nothing to commit"

Solution: You forgot to stage your changes first!

BASH

git add .
git commit -m "Your message"

Mistake 2: Bad Commit Message

Problem: You made a typo in your commit message or it's not descriptive enough

Solution: You can edit the last commit message:

BASH

git commit --amend -m "Better commit message"

This replaces the message of your most recent commit.

Mistake 3: Staged the Wrong Files

Problem: You accidentally staged files you didn't want to commit

Solution: Unstage them:

BASH

# Unstage a specific file
git restore --staged filename.txt

# Unstage everything
git restore --staged .

Mistake 4: Want to Discard Changes

Problem: You made changes but want to throw them away and go back to the last commit

Solution: Be careful—this permanently deletes your changes!

BASH

# Discard changes to a specific file
git restore filename.txt

# Discard all changes (dangerous!)
git restore .

Git Workflow Best Practices

1. Commit Often

Make small, frequent commits rather than large, infrequent ones. Think of commits as save points in a video game—you want them often so you can always go back!

2. Commit Logical Changes

Each commit should represent one logical change. Don't combine "Fix login bug" and "Add contact page" in the same commit—make two separate commits.

3. Check Status Before and After

Always run git status before staging and committing. This helps you avoid accidentally committing the wrong files.

4. Review Changes Before Committing

Use git diff to review exactly what changed before you commit. This catches mistakes and reminds you what to write in your commit message.

5. Write Meaningful Messages

Your future self (and your teammates) will thank you for clear, descriptive commit messages.

6. Don't Commit Sensitive Data

Never commit passwords, API keys, or other sensitive information. Once it's in Git history, it's very hard to remove!

Useful Commands Reference

Here's a quick reference of commands you've learned:

BASH

# Initialize a new repository
git init

# Check repository status
git status

# Stage a specific file
git add filename.txt

# Stage all changes
git add .

# Commit with a message
git commit -m "Your commit message"

# View commit history
git log

# View compact history
git log --oneline

# View last 5 commits
git log -5

# See what changed (unstaged)
git diff

# See what changed (staged)
git diff --staged

# Unstage a file
git restore --staged filename.txt

# Discard changes to a file (dangerous!)
git restore filename.txt

# Edit last commit message
git commit --amend -m "New message"

Key Takeaways

A repository is a folder tracked by Git with a hidden .git directory
git init initializes a new Git repository
The staging area lets you choose which changes to include in a commit
git add stages changes for commit
git commit creates a permanent snapshot of staged changes
Good commit messages are crucial for understanding project history
git status shows the current state of your repository
git log displays your commit history
Commit often with logical, focused changes
The basic workflow is: modify → stage → commit → repeat

What's Next?

Excellent work! You've successfully created your first Git repository and made several commits. You now understand the fundamental workflow that every developer uses daily.

In the next lesson, we'll dive deeper into commits and history. You'll learn how to view detailed information about commits, compare different versions, and navigate through your project's timeline. We'll also explore more advanced ways to use git log and understand what makes each commit unique.

🎯 Practice Before Moving On

Before the next lesson, create a few more commits in your repository:

Link your CSS file in index.html
Add more styles to your CSS
Update your README with more information
Create at least 3-5 commits total

The more you practice this workflow, the more natural it will become!

Test Your Understanding of Git Basics

Question 1 of 4

What does 'git init' do?

Current Score0 / 0

What is a Repository?

Think of a repository as:

A regular folder containing your project files (code, images, documents, etc.)
Plus a hidden .git folder that stores all the version control magic
The complete timeline of every change you've saved (committed)

👁️ Viewing Hidden Files

The .git folder is hidden by default. To see it:

Windows: In File Explorer, go to View → Options → View tab → Show hidden files
Mac: In Finder, press Cmd + Shift + . to toggle hidden files
Linux: In your file manager, press Ctrl + H or use ls -a in terminal

Step 1: Create a Project Folder

First, let's create a new folder for our first project. We'll keep it simple with a basic website.

Using the Terminal

Open your terminal and run these commands:

BASH

# Navigate to where you want to create your project
# For example, your Documents folder or a dedicated projects folder
cd ~/Documents

# Create a new folder for your project
mkdir my-first-repo

# Navigate into the new folder
cd my-first-repo

# Verify you're in the right place
pwd

The pwd (print working directory) command shows your current location. You should see something like /Users/yourname/Documents/my-first-repo

Using File Explorer/Finder (Alternative Method)

If you prefer, you can create the folder using your operating system's file manager:

Open File Explorer (Windows) or Finder (Mac)
Navigate to where you want your project
Create a new folder called my-first-repo
Open your terminal and navigate to this folder:

BASH

cd path/to/my-first-repo

📁 Project Organization Tip

It's a good idea to keep all your projects in one dedicated folder. Many developers create a projects or code folder in their home directory to keep everything organized!

Step 2: Initialize a Git Repository

Now we'll tell Git to start tracking this folder. This is done with the git init command.

BASH

git init

You should see output similar to:

BASH

Initialized empty Git repository in /Users/yourname/Documents/my-first-repo/.git/

Congratulations! You've just created your first Git repository! Git is now watching this folder and is ready to track changes.

What Just Happened?

When you ran git init, Git:

Created a hidden .git folder in your directory
Set up all the necessary structure for version control
Created an initial branch (usually called "main")
Prepared the repository to track files

Your folder is now a Git repository, but it doesn't have any commits yet. Let's fix that!

Step 3: Check Repository Status

One of the most useful Git commands is git status. It tells you what's happening in your repository at any moment.

BASH

git status

You'll see something like:

BASH

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

This output tells us:

We're on the main branch (more on branches later)
We haven't made any commits yet
There are no files to track

💡 Use Git Status Frequently!

Step 4: Create Some Files

Let's create a couple of files so we have something to track. We'll make a simple README file and an HTML file.

Method 1: Using Terminal

BASH

# Create a README file
echo "# My First Repository" > README.md
echo "This is my first project using Git!" >> README.md

# Create an HTML file
echo "<!DOCTYPE html>" > index.html
echo "<html>" >> index.html
echo "<head><title>My First Repo</title></head>" >> index.html
echo "<body><h1>Hello, Git!</h1></body>" >> index.html
echo "</html>" >> index.html

Method 2: Using a Text Editor

Alternatively, create these files using your favorite text editor:

README.md:

README.md

# My First Repository

This is my first project using Git!

## What I'm Learning
- How to initialize a Git repository
- How to stage and commit changes
- How to track my project history

index.html:

index.html

<!DOCTYPE html>
<html>
<head>
    <title>My First Repo</title>
</head>
<body>
    <h1>Hello, Git!</h1>
    <p>This is my first project tracked with Git.</p>
</body>
</html>

Now run git status again:

BASH

git status

You'll see:

BASH

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md
        index.html

nothing added to commit but untracked files present (use "git add" to track)

Git sees your new files! They're listed as "untracked" because we haven't told Git to start tracking them yet.

Understanding the Staging Area

Before we commit files, we need to understand Git's three-stage workflow:

The Three States of Git

Working Directory: Where you actually work on files. This is your normal project folder.
Staging Area (Index): A preparation area where you add changes you want to include in the next commit.
Repository (.git directory): Where Git permanently stores committed snapshots.

The workflow looks like this:

TEXT

Working Directory  →  Staging Area  →  Repository
   (modified)         (staged)         (committed)
      
   git add →           git commit →

Why Have a Staging Area?

The staging area gives you fine control over what goes into each commit. You might have:

Made changes to 5 files
But only want to commit 3 of them
Because they're related to one specific feature

You can stage just those 3 files, commit them with a clear message, then stage and commit the other 2 separately with a different message. This keeps your history clean and organized!

🎯 Think of Staging as Shopping Cart

Step 5: Stage Your Changes

Now let's add our files to the staging area using git add.

Adding Individual Files

You can add files one at a time:

BASH

git add README.md

Check the status:

BASH

git status

You'll see:

BASH

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        index.html

README.md is now in the staging area (ready to be committed), while index.html is still untracked.

Adding All Files at Once

Instead of adding files individually, you can stage everything:

BASH

git add .

The dot (.) means "add everything in the current directory and subdirectories."

Now check status again:

BASH

git status

Both files are now staged:

BASH

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md
        new file:   index.html

Be Careful with 'git add .'

While git add . is convenient, make sure you actually want to stage everything. Always run git status first to see what will be added!

Step 6: Make Your First Commit

Now that your changes are staged, you can create a commit—a permanent snapshot of your project at this moment.

BASH

git commit -m "Initial commit - Add README and index page"

You'll see output like:

BASH

[main (root-commit) a1b2c3d] Initial commit - Add README and index page
 2 files changed, 15 insertions(+)
 create mode 100644 README.md
 create mode 100644 index.html

Congratulations! You've made your first commit! Git has now saved a permanent snapshot of your project.

Understanding the Commit Command

git commit - The command to create a commit
-m - Flag for "message" (lets you include your message directly)
"Initial commit..." - Your commit message describing what changed

About the Output

Let's understand what Git told us:

[main (root-commit) a1b2c3d] - You're on the main branch, this is your first commit, and a1b2c3d is the commit hash (unique ID)
2 files changed, 15 insertions(+) - You created 2 files with 15 total lines
Shows which files were created or modified

Writing Good Commit Messages

Commit messages are incredibly important. They're how you (and others) understand what changed and why. Here are best practices:

Good Commit Message Structure

TEXT

Short summary (50 characters or less)

More detailed explanation if needed (wrap at 72 characters).
Explain what changed and why, not how (the code shows how).

- You can use bullet points
- To list multiple changes
- Or explain context

Examples of Good vs Bad Messages

Bad Commit Messages:

"fix"
"update"
"changes"
"asdfasdf"
"Finally works!!!"

These messages don't tell you anything useful!

Good Commit Messages:

"Add user authentication with JWT tokens"
"Fix navigation menu overflow on mobile"
"Update homepage hero section with new brand colors"
"Remove deprecated API endpoints"
"Add error handling for network failures"

These messages clearly describe what changed!

Commit Message Guidelines

Use the imperative mood: "Add feature" not "Added feature" (think of it as giving a command)
Be specific but concise: Explain what and why, not how
Start with a capital letter: "Fix bug" not "fix bug"
No period at the end: Unless it's a full sentence in the body
Limit the summary to 50 characters: Keep it short and scannable

📝 Future You Will Thank You

Step 7: View Your Commit History

Now that you have a commit, let's look at your project history using git log.

BASH

git log

You'll see:

BASH

commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> main)
Author: Your Name <your.email@example.com>
Date:   Sat Jan 3 2026 14:30:00

    Initial commit - Add README and index page

This shows you:

Commit hash: The unique identifier for this commit (usually abbreviated)
Author: Who made the commit (that's you!)
Date: When the commit was made
Message: The commit message you wrote
(HEAD -> main): This is where you currently are in your project's timeline

Useful Log Variations

Compact one-line format:

BASH

git log --oneline

Show last 3 commits:

BASH

git log -3

Show file changes in each commit:

BASH

git log --stat

Show visual branch graph (more useful later):

BASH

git log --oneline --graph --all

🔍 Exiting Git Log

If git log opens a pager (you can't type new commands), press Q to quit and return to your normal terminal prompt.

The Complete Git Workflow

Let's practice the complete workflow by making more changes.

Make Some Changes

Edit your index.html file to add more content:

index.html

<!DOCTYPE html>
<html>
<head>
    <title>My First Repo</title>
</head>
<body>
    <h1>Hello, Git!</h1>
    <p>This is my first project tracked with Git.</p>
    
    <!-- New content added -->
    <h2>What I've Learned</h2>
    <ul>
        <li>How to initialize a repository</li>
        <li>How to stage changes with git add</li>
        <li>How to commit changes with meaningful messages</li>
    </ul>
</body>
</html>

Also create a new file called styles.css:

styles.css

body {
    font-family: Arial, sans-serif;
    max-width: 800px;
    margin: 0 auto;
    padding: 20px;
    background-color: #f5f5f5;
}

h1 {
    color: #333;
}

Check What Changed

BASH

git status

You'll see:

BASH

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:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        styles.css

no changes added to commit (use "git add" and/or "git commit -a")

Git detected that index.html was modified and there's a new file styles.css.

See Exactly What Changed

Use git diff to see the exact changes:

BASH

git diff

This shows you line-by-line what was added (green, with +) or removed (red, with -).

Stage the Changes

BASH

git add index.html styles.css

# Or stage everything at once
git add .

Commit with a Good Message

BASH

git commit -m "Add CSS styling and expand homepage content"

View Your History

BASH

git log --oneline

You'll now see two commits:

BASH

b2c3d4e Add CSS styling and expand homepage content
a1b2c3d Initial commit - Add README and index page

Perfect! You've now completed the full Git workflow multiple times. This is the cycle you'll repeat hundreds of times as a developer:

Make changes to files
Check status with git status
Stage changes with git add
Commit with git commit -m "message"
View history with git log

Practice Git Commands

Here's an interactive playground to practice the commands you've learned:

Practice Your Git Workflow

Try these common Git commands

Try these examples:

Common Mistakes and How to Fix Them

Mistake 1: Forgot to Stage Files Before Committing

Problem: You run git commit but nothing happens or Git says "nothing to commit"

Solution: You forgot to stage your changes first!

BASH

git add .
git commit -m "Your message"

Mistake 2: Bad Commit Message

Problem: You made a typo in your commit message or it's not descriptive enough

Solution: You can edit the last commit message:

BASH

git commit --amend -m "Better commit message"

This replaces the message of your most recent commit.

Mistake 3: Staged the Wrong Files

Problem: You accidentally staged files you didn't want to commit

Solution: Unstage them:

BASH

# Unstage a specific file
git restore --staged filename.txt

# Unstage everything
git restore --staged .

Mistake 4: Want to Discard Changes

Problem: You made changes but want to throw them away and go back to the last commit

Solution: Be careful—this permanently deletes your changes!

BASH

# Discard changes to a specific file
git restore filename.txt

# Discard all changes (dangerous!)
git restore .

Git Workflow Best Practices

1. Commit Often

Make small, frequent commits rather than large, infrequent ones. Think of commits as save points in a video game—you want them often so you can always go back!

2. Commit Logical Changes

Each commit should represent one logical change. Don't combine "Fix login bug" and "Add contact page" in the same commit—make two separate commits.

3. Check Status Before and After

Always run git status before staging and committing. This helps you avoid accidentally committing the wrong files.

4. Review Changes Before Committing

Use git diff to review exactly what changed before you commit. This catches mistakes and reminds you what to write in your commit message.

5. Write Meaningful Messages

Your future self (and your teammates) will thank you for clear, descriptive commit messages.

6. Don't Commit Sensitive Data

Never commit passwords, API keys, or other sensitive information. Once it's in Git history, it's very hard to remove!

Useful Commands Reference

Here's a quick reference of commands you've learned:

BASH

# Initialize a new repository
git init

# Check repository status
git status

# Stage a specific file
git add filename.txt

# Stage all changes
git add .

# Commit with a message
git commit -m "Your commit message"

# View commit history
git log

# View compact history
git log --oneline

# View last 5 commits
git log -5

# See what changed (unstaged)
git diff

# See what changed (staged)
git diff --staged

# Unstage a file
git restore --staged filename.txt

# Discard changes to a file (dangerous!)
git restore filename.txt

# Edit last commit message
git commit --amend -m "New message"

Key Takeaways

A repository is a folder tracked by Git with a hidden .git directory
git init initializes a new Git repository
The staging area lets you choose which changes to include in a commit
git add stages changes for commit
git commit creates a permanent snapshot of staged changes
Good commit messages are crucial for understanding project history
git status shows the current state of your repository
git log displays your commit history
Commit often with logical, focused changes
The basic workflow is: modify → stage → commit → repeat

What's Next?

Excellent work! You've successfully created your first Git repository and made several commits. You now understand the fundamental workflow that every developer uses daily.

🎯 Practice Before Moving On

Before the next lesson, create a few more commits in your repository:

Link your CSS file in index.html
Add more styles to your CSS
Update your README with more information
Create at least 3-5 commits total

The more you practice this workflow, the more natural it will become!

Test Your Understanding of Git Basics

Question 1 of 4

What does 'git init' do?

Current Score0 / 0

What is a Repository?

Step 1: Create a Project Folder

Using the Terminal

Using File Explorer/Finder (Alternative Method)

Step 2: Initialize a Git Repository

What Just Happened?

Step 3: Check Repository Status

Step 4: Create Some Files

Method 1: Using Terminal

Method 2: Using a Text Editor

Understanding the Staging Area

The Three States of Git

Why Have a Staging Area?

Step 5: Stage Your Changes

Adding Individual Files

Adding All Files at Once

Step 6: Make Your First Commit

Understanding the Commit Command

About the Output

Writing Good Commit Messages

Good Commit Message Structure

Examples of Good vs Bad Messages

Commit Message Guidelines

Step 7: View Your Commit History

Useful Log Variations

The Complete Git Workflow

Make Some Changes

Check What Changed

See Exactly What Changed

Stage the Changes

Commit with a Good Message

View Your History

Practice Git Commands

Practice Your Git Workflow

Common Mistakes and How to Fix Them

Mistake 1: Forgot to Stage Files Before Committing

Mistake 2: Bad Commit Message

Mistake 3: Staged the Wrong Files

Mistake 4: Want to Discard Changes

Git Workflow Best Practices

1. Commit Often

2. Commit Logical Changes

3. Check Status Before and After

4. Review Changes Before Committing

5. Write Meaningful Messages

6. Don't Commit Sensitive Data

Useful Commands Reference

Key Takeaways

What's Next?

Test Your Understanding of Git Basics

What does 'git init' do?

Know someone who'd find this guide helpful? Please share!

Never Miss a New Git & GitHub Tutorial

You might also like

UI Components

Developer Tools

HTML Game

Join Our Web Development Training Program

Join Our Social Communities

Git & Github Tutorials

Your First Git Repository

What is a Repository?

Step 1: Create a Project Folder

Using the Terminal

Using File Explorer/Finder (Alternative Method)

Step 2: Initialize a Git Repository

What Just Happened?

Step 3: Check Repository Status

Step 4: Create Some Files

Method 1: Using Terminal

Method 2: Using a Text Editor

Understanding the Staging Area

The Three States of Git

Why Have a Staging Area?

Step 5: Stage Your Changes

Adding Individual Files

Adding All Files at Once

Step 6: Make Your First Commit

Understanding the Commit Command