Keeping the Repo Safe

1The lock Entra does not cover

Session 02 named two separate gates in this site's pipeline: Entra ID in front of the published pages, and the GitHub repository's own privacy setting in front of the source and its history. Every session since has been about the files Entra shows you once you sign in. This session is about the other gate, the one guarding the repository itself, because the two protect genuinely different things.

2Why a public repository is a real exposure

A public GitHub repository is readable by anyone with the link, no account or sign-in required, and it stays readable forever at every point in its history, not just its current state. Session 01 showed that a commit is a complete snapshot and that history never shrinks on its own. Those two facts together are exactly what makes a public repository risky: it is not only today's files on display, it is every version of every file this project has ever had, including anything that was later edited to remove something sensitive.

This training site's repository holds internal structure, draft material, and the exact mechanics of how Hermetic's internal site gets published, including the pipeline session 02 walked through. None of that is written for a public audience, which is reason enough on its own for the repository to stay private, before a single credential is ever at stake.

3What never belongs in a commit

A private repository is still not a safe place for certain things, because private can become public by a changed setting, a departing employee, or a mistake, and because anyone with legitimate access today is still more people than a secret should ever be shared with. Treat the following as things that never get committed, to any branch, private or not:

4.gitignore: telling git what to never track

A file named .gitignore, sitting in the top of a repository, lists patterns for files git should never track, stage, or warn you about, no matter how many times they change. This repository already has one, and its entire current content is one line:

That single line blocks one specific, auto-generated system file some Windows folders pick up, which has nothing to do with secrets; it is there because the file is noise, not because it is sensitive. The mechanism, though, is exactly what secrets protection relies on. A project that will ever hold a .env file, an API key, or any file built to carry a credential should add a line for it to .gitignore before that file is ever created, so that git status never even offers to stage it by accident.

5What to actually do if a secret leaks anyway

It happens, including to experienced teams, and the response matters more than the mistake. The one rule that overrides every instinct to quietly clean it up: deleting the file in a new commit does not remove it from history. The old commit, with the secret in full, still exists and is still reachable by anyone who can see the repository, exactly as session 01 described a commit as permanent once made.

1. Treat the credential as compromised the instant it is found in a commit, whether or not it was ever pushed, and whether or not the repository is private.
2. Rotate or revoke it immediately, through whatever service issued it. A new key is cheap. A key that may have been seen by the wrong person is not something a later commit can take back.
3. Only after it is rotated, remove the file from the current working tree with a normal commit, so it stops appearing in new work.
4. If the secret must also be scrubbed from the history itself, that is a separate, harder operation that rewrites commits, and it is worth a second person's help the first time; it is out of scope for this session, but rotating the credential is not optional while you decide whether to do it.

6The one habit that catches most of this

Session 03 introduced git status and git diff as the check that would have caught an unrelated file riding along in a commit. The same habit is the main defense here: read what you are about to stage, every time, before you stage it. A credential sitting in a file you are about to commit shows up in that diff exactly like any other line would.

7Try it: see .gitignore do its job

In your practice folder.

1. Create a file named .env containing one fake line, such as API_KEY=not-a-real-key.
2. Run git status. Right now, git lists it as untracked, exactly like any new file, because nothing has told this practice repo to ignore it yet.
3. Create a .gitignore file in the same folder containing one line: .env.
4. Run git status again. The .env file no longer appears at all. Git is not merely declining to stage it; it has stopped mentioning it.
5. Stage and commit the new .gitignore file itself, with a message describing what it protects.

8Check for understanding

1. Entra ID is configured correctly on this training site. Does that make the GitHub repository safe to set to public?

   A.Yes, since Entra already controls who can see the site. B.No. Entra controls who views the published pages; repository privacy controls who can see the source and its history, and the two are independent. C.Yes, because GitHub automatically matches a repository's privacy to any connected identity provider. D.No, but only because a public repository would also disable Entra automatically.
   Answer

   The two settings are independent. Entra ID decides who can view the rendered site. The repository's own privacy setting decides who can see the source and every commit behind it. Getting one right says nothing about the other, which is why both need to be checked.

   Show the answer
2. A credential was committed by mistake and then removed in a later commit. Is it still exposed?

   A.No, because the later commit overwrites the earlier one entirely. B.Yes. The commit where it was first added still exists in the history and is still reachable. C.No, because git automatically clears any commit older than 30 days. D.Only if the repository is public; a private repository erases old commits automatically.
   Answer

   Deleting a file in a new commit only changes what the current working tree shows. The earlier commit where the credential was added is untouched and still exists in full, reachable by anyone with access to the repository, which is why the real response is to rotate the credential rather than assume a later commit fixed anything.

   Show the answer
3. A .gitignore line for .env is added to a project today. What happens to a .env file that was already committed three weeks ago?

   A.It is automatically removed from every past commit. B.Nothing. The already-committed file remains in the history; .gitignore only affects files from this point forward. C.Git deletes the file from the working tree the next time it is run. D.Git prints a warning listing every past commit that included the file.
   Answer

   .gitignore changes nothing about history that already exists. It tells git never to track a matching file from this point forward. A file already committed before the pattern existed stays exactly where it is in the history, which is why the rule has to be in place before a sensitive file is ever created, not after.

   Show the answer
4. A real API key is found sitting in a commit on a private repository, never pushed anywhere public. What is the correct first action?

   A.Leave it, since the repository is private and nobody outside the team could have seen it. B.Rotate or revoke the credential immediately, through the service that issued it. C.Delete the file in a new commit and consider the matter closed. D.Make the repository even more restricted and take no action on the credential itself.
   Answer

   Rotating or revoking the credential is the one action that actually removes the risk, regardless of whether the repository was private or whether anyone is known to have seen it. Everything else, deleting the file, restricting access further, is worth doing too, but none of it substitutes for treating the credential itself as compromised.

   Show the answer
5. What is the actual reason the single line in HN - Training's real .gitignore is not itself an example of secrets protection?

   A.Because a .gitignore file is only allowed to contain one line at a time. B.Because it blocks an auto-generated system file with no sensitive content, not a credential or config file. C.Because the entry is encrypted and git cannot read its actual contents. D.Because the entry is a placeholder that does not correspond to any real file.
   Answer

   The real entry blocks a specific, auto-generated system file, noise rather than anything sensitive. It shows the mechanism correctly, that a listed pattern is never tracked, but a project that might ever hold a credential needs its own lines added for that, such as .env, before such a file is first created.

   Show the answer

9Before session 08

• Locate where your own copy of HN - Training, or any repository you work in, actually lives on disk. Session 08 asks whether that location is safe.

10Glossary

Private repository

A repository readable only by people explicitly granted access, as opposed to a public one readable by anyone with the link.

.gitignore

A file listing patterns git will never track, stage, or report on, from the point the pattern is added onward.

Secret / credential

A password, API key, token, or connection string that grants access to a system and must never be committed.

Credential rotation

Replacing a credential with a new one and invalidating the old, the correct first response to any leaked secret.

History rewrite

An operation that edits past commits directly to remove content from them, a separate and harder step from simply deleting a file in a new commit.

11Sources

• GitHub, Keeping your credentials secure and Removing sensitive data from a repository, GitHub Docs.
• Git, gitignore documentation, git-scm.com.
• HN - Training's own .gitignore, read directly from the repository, 2026-10-03.