.gitignore, Leaked Secrets, and Putting It Together

.gitignore: what should never be tracked

Not everything in a project folder belongs in version control: build output, OS-generated junk files, and, critically, anything secret. A .gitignore file tells Git which files or patterns to simply never track. Create one:

echo ".env" > .gitignore
git add .gitignore
git commit -m "Add .gitignore for local secrets"

Now create a file that .gitignore is protecting:

echo "API_KEY=fake-example-not-a-real-secret" > .env
git status

.env doesn’t appear, not even as untracked. .gitignore is working exactly as intended: the single most effective defense against committing a secret is never letting Git see the file that holds it in the first place.

The uncomfortable truth about secrets already committed

Here’s the part that catches people out constantly in real projects: if a secret was ever committed and pushed, deleting it in a later commit does not remove it. It’s still sitting, completely intact, in every earlier commit that has it, recoverable by anyone with a clone of the repository, forever, unless the history itself is rewritten, and even then, anyone who already cloned or forked it still has their own copy.

See this for yourself, safely and locally. Commit a fake secret on purpose:

echo "PASSWORD=not-a-real-secret-either" > leaked.txt
git add leaked.txt
git commit -m "Oops, commit a secret"

Now “discover” it the way anyone with access to this history could:

git log --oneline
git show <commit-hash-from-above>

The secret is right there, fully readable, in that commit’s diff, exactly as if you were investigating this repository after the fact. Deleting leaked.txt in a new commit would stop it from showing up in the current working directory, but git show against that earlier commit would still reveal it, which is exactly the point: the real fix for a leaked credential is to rotate or revoke it immediately, treating it as compromised the moment it was pushed anywhere, not to quietly remove the file and consider the problem solved.

Clean this up now that the point is made:

rm leaked.txt
git add leaked.txt
git commit -m "Remove leaked.txt from the working tree (history still has it)"

What you now know

Four lessons ago you had never run git init. Here’s the short version of the ground you’ve covered since:

1. What Is Git, and Why Security Teams Live in It. Git is a distributed version control system, and its hard-to-fake history is exactly why infrastructure-as-code and detection-as-code rely on it as an audit trail.
2. Making and Tracking Changes. The working directory, staging area, and commit are three separate steps on purpose, git log tells you who and when, and git diff tells you exactly what.
3. Branching and Merging. A branch is a cheap, isolated pointer, which is exactly why “always branch, never edit main directly” works in practice, and a merge conflict deserves real editorial judgment, not a quick guess.
4. Undoing Mistakes Safely. git restore undoes what was never committed, git revert undoes what was shared without erasing the record, and git reset rewrites history, which is dangerous the moment anyone else has a copy.

Those four ideas, think in snapshots, isolate risky changes on branches, read history like evidence, and undo mistakes without hiding them, are the daily reflexes of anyone who works seriously with Git.

Combined hands-on exercise: reviewing a small project’s history

This last exercise chains together commands from across the whole track into one small scenario: you’re handed a small project and asked to check its history for anything that shouldn’t be there, then clean it up properly.

Start a fresh look at your practice repo:

git log --oneline

Walk through it the way an investigator would: note which commits look ordinary, and which one, “Oops, commit a secret,” stands out. Confirm it’s still fully visible:

git show --stat HEAD~1

(Adjust HEAD~1 if your own commit count differs, the goal is just to land on that commit.) This confirms, one more time, that removing a file afterward never erases it from here. In a real project, this is the exact moment you’d go rotate whatever credential was exposed, not just note that the file is gone now.

Finish on a clean branch habit: make one more small, deliberate change the right way, branch, commit, and merge back, so your very last history entries read as a clean example of the workflow this whole track taught:

git switch -c wrap-up-note
echo "Track complete." >> notes.txt
git add notes.txt
git commit -m "Mark Git Fundamentals complete"
git switch main
git merge wrap-up-note
git log --oneline

You just walked the whole path: spotting a leaked secret in history, understanding why deleting the file isn’t the fix, and closing out with the branch-and-merge habit from Lesson 3. Nothing here ever left your own machine.

Where to go from here

This track deliberately stopped at the commands you’ll use daily. Rebasing, cherry-picking, and Git’s internal object model are each worth learning eventually, but they’re not foundation material.

If something in this track made you want to go deeper right now, bring it to the community Discord using the Join Discord button at the top of the page. The open question you wrote down in the reflection below is a perfectly good place to start that conversation.

When you’re ready, GitHub/GitLab Fundamentals is the direct next step: everything here was local, that track picks up the moment your code needs to live somewhere shared, with other people reviewing it, and with real permissions and secrets attached to who can touch it.