Practical Exercise: Version-Track a Personal Project Folder From Scratch

This capstone exercise ties together every concept from Module 1 into a single, realistic workflow. You'll take an ordinary, untracked folder — a small personal project — and turn it into a properly version-controlled repository from the very first command to a clean, readable commit history. There's no new theory here; this is entirely about building muscle memory for the sequence of commands you'll use in literally every Git project you ever work on.

Learning Objectives

Combine git init, config, status, add, commit, log, diff, and .gitignore in one realistic end-to-end workflow.
Practice writing a sequence of atomic, well-messaged commits for a real set of changes.
Correctly exclude unwanted files using .gitignore before they're ever committed.
Review the resulting history using git log to confirm a clean, understandable project record.

Key Terms to Know Before Learning Practical Exercise

End-to-end workflow: The complete practical sequence of Git commands used from starting a new project to having a clean, committed history.
Working tree: Another term for the working directory — the actual files as they currently exist on disk.
Commit history: The ordered sequence of all commits made in a repository, viewable with git log.
Repository hygiene: The practice of keeping a repository's tracked files clean and relevant by properly using .gitignore and atomic commits.

How Practical Exercise Actually Works

**Step 1: Set up the project folder.** Create a new folder for a small personal project — for this exercise, imagine a simple personal portfolio website with an `index.html`, a `style.css`, and a `notes.txt` for your own private planning notes, plus an imaginary `node_modules/` folder representing installed dependencies you would never want tracked.

**Step 2: Configure Git (if not already done).** Confirm your identity is set globally with `git config --global user.name` and `git config --global user.email` (from Lesson 5) — this only needs to be done once per machine, not per project.

**Step 3: Initialize the repository.** Run `git init` inside the project folder. Confirm the hidden `.git` folder now exists.

**Step 4: Set up .gitignore before adding anything.** This order matters — create your `.gitignore` file first, adding patterns like `node_modules/` and `notes.txt` (your private planning file), before running any `git add` command. This way, these files are never accidentally staged in the first place.

**Step 5: Check status, then stage deliberately.** Run `git status` to see what Git currently sees. Notice that `node_modules/` and `notes.txt` do not appear at all, because `.gitignore` is already excluding them. Stage your real project files individually or by directory: `git add index.html style.css .gitignore`.

**Step 6: Make your first atomic commit.** Run `git commit -m "feat: initial portfolio structure with homepage and styles"`. This becomes commit #1 in your history.

**Step 7: Make a real, incremental change.** Edit `style.css` to change a color or add a new rule. Run `git diff` to review your unstaged edit line by line before staging it.

**Step 8: Stage and review again before committing.** Run `git add style.css`, then `git diff --staged` to confirm exactly what's about to be committed.

**Step 9: Commit the second atomic change separately.** Run `git commit -m "style: update button color to match new branding"` — kept as its own focused commit, separate from the initial structure commit.

**Step 10: Review the full history.** Run `git log --oneline --graph --decorate --all` to see your two clean, clearly labeled commits in sequence, confirming the project now has a real, readable version history from the very beginning.

By the end of this exercise, you will have personally executed the entire lifecycle covered across all thirteen previous lessons in this module — installation and configuration assumed complete, followed by init, gitignore, status, add, diff, commit, and log — on a real project of your own.

Practical Exercise: Visual Walkthrough

Draw a ten-step numbered vertical flow: 1) Create project folder → 2) Confirm git config (name/email) → 3) git init → 4) Create .gitignore (node_modules/, notes.txt) → 5) git status (confirm ignored files hidden) → 6) git add index.html style.css .gitignore → 7) git commit -m 'feat: initial portfolio structure' → 8) Edit style.css, git diff to review → 9) git add style.css, git diff --staged to confirm → 10) git commit -m 'style: update button color', then git log --oneline --graph --decorate --all to review full history.

Practical Exercise: Quick Reference Table

Step	Command(s)	Purpose
1. Configure identity (once per machine)	git config --global user.name / user.email	Ensure commits are properly attributed
2. Initialize repository	git init	Create the .git tracking folder
3. Set up .gitignore first	Create .gitignore with node_modules/, notes.txt	Prevent unwanted files from ever being staged
4. Check and stage deliberately	git status, then git add <files>	Confirm exactly what will be tracked before staging
5. Commit atomically	git commit -m "..."	Save a focused, well-described snapshot
6. Review before every commit	git diff / git diff --staged	Catch mistakes before they're permanent
7. Review full history	git log --oneline --graph --decorate --all	Confirm a clean, understandable commit record

Practical Exercise: Command Syntax and Examples

mkdir my-portfolio && cd my-portfolio

# (Assuming git config --global user.name/email already set from Lesson 5)

git init

cat > .gitignore << 'EOF'
node_modules/
notes.txt
EOF

touch index.html style.css notes.txt
mkdir node_modules   # simulating a dependency folder

git status
# Only index.html, style.css, and .gitignore show as untracked —
# node_modules/ and notes.txt are correctly hidden by .gitignore

git add index.html style.css .gitignore
git commit -m "feat: initial portfolio structure with homepage and styles"

echo "button { background-color: navy; }" >> style.css
git diff

git add style.css
git diff --staged
git commit -m "style: update button color to match new branding"

git log --oneline --graph --decorate --all

Breaking Down the Practical Exercise Example

This walkthrough mirrors a completely realistic first day on a new personal project. Creating the `.gitignore` file before ever running `git add` ensures `node_modules/` and `notes.txt` never even appear as untracked candidates in `git status`. The two separate commits — one for initial structure, one for a specific styling change — demonstrate the atomic commit principle from Lesson 10 in practice. Running `git diff` before staging and `git diff --staged` before committing builds the habit of reviewing changes at every step, and the final `git log --oneline --graph --decorate --all` confirms a clean, two-commit history that clearly documents the project's evolution from the very beginning.

How Practical Exercise Is Used on Real Engineering Teams

This exact sequence — init, gitignore, status, add, commit, review, repeat — is precisely what a new developer performs on day one of literally any personal or professional software project.
Technical interviews at many companies include a live-coding or take-home portion explicitly evaluating whether a candidate creates focused, atomic commits with clear messages rather than one giant 'final submission' commit.
Bootcamp and university capstone projects are frequently graded in part on commit history quality, specifically checking for exactly this kind of disciplined, step-by-step workflow rather than a single bulk commit at the deadline.
Freelancers and open-source contributors use this same foundational workflow as the starting point for every new client project or repository they create, regardless of the technology stack involved.

Practical Exercise Interview Questions and Answers

Q1. Walk me through the steps you'd take to start version-controlling a brand-new project folder.

First, confirm Git is configured with your name and email (a one-time setup per machine). Then run git init inside the project folder to create the .git tracking directory. Before staging anything, set up a .gitignore file to exclude files like dependencies or local notes. Then use git status to confirm what's untracked, stage the real project files deliberately with git add, and commit with a clear, atomic, well-written message. Repeat this add-review-commit cycle for each subsequent logical change, and use git log periodically to confirm the history stays clean and understandable.

Q2. Why is it best practice to set up .gitignore before your first git add, rather than after?

Setting up .gitignore first ensures unwanted files like dependency folders or local notes are never even staged in the first place. If you add and commit files before creating .gitignore, those files become part of the tracked history and adding a later ignore rule won't remove them — you'd need the extra step of git rm --cached to fix it.

Q3. What habits from this exercise reflect professional Git usage rather than just beginner correctness?

Reviewing changes with git diff before staging and git diff --staged before committing, keeping each commit atomic and focused on one logical change, writing clear imperative-mood commit messages, and periodically reviewing the overall history with git log --oneline --graph --decorate --all are all habits that distinguish disciplined, professional Git usage from simply making commands run without errors.

Practical Exercise Quiz: Test Your Understanding

1. In this exercise, why is the .gitignore file created before running any git add command?

It has no effect on the order in which it's created
So that unwanted files are never staged in the first place, avoiding the need to untrack them later
Because git init requires .gitignore to already exist
Because git add fails without a .gitignore file present

Answer: B. So that unwanted files are never staged in the first place, avoiding the need to untrack them later

Explanation: Creating .gitignore before any staging ensures excluded files never enter the staging area or commit history to begin with, avoiding the extra git rm --cached cleanup step required for already-tracked files.

2. Why does the exercise use two separate commits instead of one large commit for both the initial structure and the style change?

Git requires a minimum of two commits per project
To follow the atomic commit principle, keeping each logical change separate and easier to review or revert
Because git commit can only handle one file at a time
There is no meaningful reason; it was arbitrary

Answer: B. To follow the atomic commit principle, keeping each logical change separate and easier to review or revert

Explanation: Separating unrelated changes into their own focused commits follows the atomic commit best practice covered in Lesson 10, making history clearer and each change independently reviewable or revertible.

3. What is the purpose of running git diff --staged before the second commit in this exercise?

To undo the staged changes
To review exactly what will be committed before making it permanent
To compare two different branches
To check the remote repository's status

Answer: B. To review exactly what will be committed before making it permanent

Explanation: git diff --staged compares the staging area against the last commit, letting you confirm precisely what's about to be saved before running git commit, catching any mistakes beforehand.

Practical Exercise: Common Mistakes Beginners Make

Running git add . before setting up .gitignore, accidentally staging a dependency folder or private notes file that then requires git rm --cached to fix.
Bundling the initial project structure and the later style change into one single commit instead of two clean, atomic ones.
Skipping the git diff and git diff --staged review steps, missing a chance to catch mistakes before they became part of permanent history.
Forgetting to run git status at each step to build the habit of always knowing your repository's current state before acting.

Practical Exercise: Exam-Ready Quick Notes

Correct order matters: configure identity → git init → set up .gitignore → check status → stage deliberately → review → commit.
Two atomic commits (structure, then style change) are preferred over one bundled commit.
Reviewing with git diff before staging and git diff --staged before committing is a core professional habit, not an optional extra step.
git log --oneline --graph --decorate --all is the standard way to confirm your history is clean at the end of a work session.

Practical Exercise: Key Takeaways

This exercise demonstrates that real Git usage is a disciplined sequence, not just isolated commands memorized in a vacuum.
Setting up .gitignore before your first git add prevents unwanted files from ever entering your repository's history.
Reviewing changes at each step with git diff, and keeping commits atomic with clear messages, are the habits that define professional, confident Git usage.

Frequently Asked Questions About Practical Exercise

Q1. What is the correct order of steps when starting to version-control a brand-new project?

Configure your Git identity (once per machine) if not already done, run git init in the project folder, set up .gitignore before staging anything, check git status, stage files deliberately with git add, review with git diff, commit with a clear atomic message, and repeat for subsequent changes.

Q2. Why does the exercise emphasize creating .gitignore before the first commit?

Because .gitignore only prevents currently untracked files from being staged — it cannot retroactively remove files that were already committed. Setting it up first avoids ever having to use git rm --cached to fix an accidental inclusion later.

Q3. Is it necessary to run git diff before every single commit?

It's not strictly required by Git, but it's a strongly recommended professional habit — reviewing exactly what you're about to stage or commit catches mistakes, forgotten debug code, or unintended changes before they become permanent history.

Q4. What does completing this exercise actually demonstrate about my Git skills?

It demonstrates that you can independently execute the full, realistic Git workflow covered in this module — not just run individual commands in isolation, but sequence them correctly, apply .gitignore proactively, write atomic commits, and confidently review your project's history.

Q5. What should my commit history look like at the end of this exercise?

Running git log --oneline --graph --decorate --all should show exactly two clean commits: one for the initial project structure (e.g., 'feat: initial portfolio structure with homepage and styles') and one for the separate styling change (e.g., 'style: update button color to match new branding'), with node_modules/ and notes.txt never appearing anywhere in the history.

Summary

This capstone exercise combines every command from Module 1 into one realistic workflow: configuring Git identity, initializing a repository with git init, setting up .gitignore before ever staging files, checking git status to confirm the correct files are visible, staging deliberately with git add, reviewing changes with git diff and git diff --staged, committing atomic changes with clear messages via git commit, and reviewing the resulting clean history with git log --oneline --graph --decorate --all. Completing this exercise on a real personal project is the single best way to convert the individual concepts from this module into genuine, practical Git fluency.