Gitignore and Cleanup: Untrack Secrets and Artifacts
Fifth day, and her first pull request is close. Teo asks her to clean the repo before she opens it.
What she finds is closer to archaeology than housekeeping. A build binary, committed on purpose, because a colleague once decided rebuilding takes too long so it is faster to just commit the result. A stray file sitting in the root of the repo, name BEACON_API_KEY, plain text, readable by anyone who opens the folder.
"whose is this?" she asks in the team channel.
Silence. Then somebody writes back: "oh that's the staging key, it's also pinned in #general for convenience."
Then Priya, the manager, who Niki has so far only seen in meetings, replies: "Why is our staging key pinned in #general."
Then a longer silence.
"Handle it," Priya says.
The Build Binary Never Belonged in git
build/beacon got committed by accident, back when someone thought committing the build output was faster than rebuilding it. It untracks with git rm --cached, leaving the file on disk, just no longer part of the repository's history going forward.
Teo's tip
git rm --cached build/beacon removes it from the index without touching the working tree copy. Commit that removal like any other change, staging it is not enough, do not forget to commit.
The binary still exists inside every earlier commit that included it. Untracking only changes what gets committed going forward, it does not rewrite history. Purging it from past commits entirely would need a separate, riskier operation, out of scope here.
Teach the Repo What to Ignore
Nothing here should have to be untracked by hand twice. A .gitignore covering build/, *.log, and .env keeps the same three mistakes from happening again: committed build output, committed logs, committed secrets.
Teo's tip
Writing the .gitignore file is not the finish line. git add .gitignore and commit it, same as any other change, do not forget to commit.
The Files gitignore Never Saw
git clean only removes files that are untracked and not ignored. beacon.tmp was never committed and matches none of the new .gitignore rules, so it qualifies. So does BEACON_API_KEY, the plaintext key was never covered by any ignore rule either, on purpose, quietly hiding a real secret would not fix anything. The same command removes both. It also works for any build or test output a program drops into the tree, not just this scenario. Cleaning a whole untracked directory needs -d too, plain -f skips those. git clean -n first, to see exactly what would go, then git clean -f once the list looks right.
Teo's tip
git clean -n is a dry run, it only prints what would be removed. git clean -f actually deletes it. Always run -n first, deleting the wrong file by accident is a bad way to learn this command.
She does not know it yet, but this key is not finished with her. It comes back twice more.