4. Basic Git Workflow

Now that you understand Git's three-stage architecture, it's time to put it to practice! In this chapter, we will walk through the core workflow commands you will use dozens of times a day: creating a repo, staging files, checking statuses, reviewing diffs, and committing changes.

1. Initializing a Repository: git init

To turn any local directory into a Git repository, navigate to the folder in your terminal and run:

git init

This creates a hidden folder named .git in your current directory. This directory contains all the tracking files, objects, and configuration database for your repository. Do NOT delete or manually modify this folder unless you want to stop tracking the project!

2. Checking Repository Status: git status

The git status command is your compass in Git. It shows the current state of your working directory and staging area:

git status

It reports:

  • Which branch you are currently on.
  • Which files are **untracked** (Git knows they exist but is not watching them yet).
  • Which files are **modified** but not staged.
  • Which files are **staged** and ready for the next commit.

3. Staging Files: git add

Staging prepares files for a commit. You are telling Git: "Hey, I want these specific changes to be part of my next snapshot."

# Stage a single file
git add index.html

# Stage multiple specific files
git add styles.css main.js

# Stage ALL files, modifications, and deletions in the entire directory
git add .

4. Viewing Differences: git diff

Before you commit, you often want to see exactly *what* you changed. The git diff command shows the exact lines of code added or removed:

# View unstaged changes (Working Directory vs Staging Area)
git diff

# View staged changes (Staging Area vs Last Commit)
git diff --staged
Pro Tip: Staged additions will appear in green (prefixed with +), and deletions will appear in red (prefixed with -).

5. Committing Changes: git commit

Committing takes a permanent snapshot of your staged changes and saves it in the Git directory. Every commit should include a clear, descriptive message explaining *why* the changes were made.

# Commit with a short message
git commit -m "Initialize project and add home page layout"

If you run git commit without the -m flag, Git will open your default text editor (such as Vim or VS Code) for you to write a longer, multi-line commit message.

Step-by-Step Example Workflow

Let's put all of these together in a clean sequence:

# 1. Initialize a new repo
git init

# 2. Create a new file
echo "Hello Git" > index.html

# 3. Check status (will show index.html as Untracked)
git status

# 4. Stage index.html
git add index.html

# 5. Check status again (will show index.html as Staged / "Changes to be committed")
git status

# 6. Commit the file
git commit -m "Initial commit with index.html"
Note: Commits are completely local! Until you link a remote server (like GitHub) and use `git push`, all of this history remains safely stored on your local hard drive.