There is a common misconception among developers that once you delete a commit, it’s gone forever. You can force-push to rewrite history, or delete a branch that had sensitive information and assume it’s safely erased. But GitHub and Git itself don't work that way. In fact, GitHub can retain and expose "deleted" commits in ways that aren't obvious. Under certain conditions, commits you believe were removed can still be accessed publicly. This creates an illusion of privacy - developers feel safe, but in reality, traces of sensitive information may remain accessible. In this article, I’ll walk through how this happens, demonstrate cases where deleted or private commits can still be accessed, and explain what this means for security-conscious teams, open-source maintainers, and developers who apply GitHub hygiene incorrectly. How Git handles "deleted" commits Git is a distributed version control system that tracks versions of files. This means developers can have their own version of branches independently. Git At its core, Git is a content-addressable database. Commits, trees, and blobs are stored based on their SHA-1 or SHA-256 hash. Git doesn't really "delete" things - it simply dereferences them. Let's take a look at what this looks like in practice: Let's take a look at what this looks like in practice: First, initialise a new Git repository and add a README.md file $ git init
Initialized empty Git repository in /Users/vshelkovnikov/GitHub/demo/.git/
$ touch Readme.md
$ git add .
$ git commit -m "First commit"
[main (root-commit) fe8b8e6] First commit
 1 file changed, 1 insertion(+)
 create mode 100644 Readme.md $ git init
Initialized empty Git repository in /Users/vshelkovnikov/GitHub/demo/.git/
$ touch Readme.md
$ git add .
$ git commit -m "First commit"
[main (root-commit) fe8b8e6] First commit
 1 file changed, 1 insertion(+)
 create mode 100644 Readme.md Add some changes to README.md and commit again. $ git add .
$ git commit -m "Second commit"
[main 2b9714e] Second commit
 1 file changed, 1 insertion(+), 1 deletion(-) $ git add .
$ git commit -m "Second commit"
[main 2b9714e] Second commit
 1 file changed, 1 insertion(+), 1 deletion(-) At this point, we have two commits. You can check them with git log: git log $ git log
commit 2b9714ec5b229700eed2ce2dc673b8d8b52a1f35 (HEAD -> main)
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:33:26 2025 +0300

    Second commit

commit fe8b8e6d36d640a29dc893ecc81bc1a2eeead1ed
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:32:33 2025 +0300

    First commit $ git log
commit 2b9714ec5b229700eed2ce2dc673b8d8b52a1f35 (HEAD -> main)
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:33:26 2025 +0300

    Second commit

commit fe8b8e6d36d640a29dc893ecc81bc1a2eeead1ed
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:32:33 2025 +0300

    First commit HEAD is a pointer located in the .git/HEAD file within your repository. This file typically contains a reference to the current branch (e.g., ref: refs/heads/main) or a specific commit hash if you’re in a detached HEAD state. HEAD .git/HEAD ref: refs/heads/main Let’s reset to the first commit using git reset HEAD^ --hard. git reset HEAD^ --hard $ git reset HEAD^ --hard
HEAD is now at fe8b8e6 First commit $ git reset HEAD^ --hard
HEAD is now at fe8b8e6 First commit We can see that HEAD has switched to the first commit: HEAD $ git log
commit fe8b8e6d36d640a29dc893ecc81bc1a2eeead1ed (HEAD -> main)
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:32:33 2025 +0300

    First commit $ git log
commit fe8b8e6d36d640a29dc893ecc81bc1a2eeead1ed (HEAD -> main)
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:32:33 2025 +0300

    First commit The second commit has disappeared. This is similar to what happens when you force-push (git push -f). It may appear that the code was erased - but in reality, you can still recover it using git reflog. git push -f git reflog $ git reflog
fe8b8e6 (HEAD -> main) HEAD@{0}: reset: moving to HEAD^
2b9714e HEAD@{1}: commit: Second commit
fe8b8e6 (HEAD -> main) HEAD@{2}: commit (initial): First commit $ git reflog
fe8b8e6 (HEAD -> main) HEAD@{0}: reset: moving to HEAD^
2b9714e HEAD@{1}: commit: Second commit
fe8b8e6 (HEAD -> main) HEAD@{2}: commit (initial): First commit Here, we can see that the second commit has the SHA-1 hash 2b9714e. 2b9714e Let’s restore it by resetting HEAD back to it. HEAD $ git reset 2b9714e
Unstaged changes after reset:
M       Readme.md

$ git log
commit 2b9714ec5b229700eed2ce2dc673b8d8b52a1f35 (HEAD -> main)
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:33:26 2025 +0300

    Second commit

commit fe8b8e6d36d640a29dc893ecc81bc1a2eeead1ed
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:32:33 2025 +0300

    First commit $ git reset 2b9714e
Unstaged changes after reset:
M       Readme.md

$ git log
commit 2b9714ec5b229700eed2ce2dc673b8d8b52a1f35 (HEAD -> main)
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:33:26 2025 +0300

    Second commit

commit fe8b8e6d36d640a29dc893ecc81bc1a2eeead1ed
Author: C4tWithShell <vladimir.shelkovnikov@aiso.team>
Date:   Mon Jul 28 17:32:33 2025 +0300

    First commit Let’s look at the commit hashes. Git supports both full and shortened versions of a hash: full shortened Full hashShort versionfe8b8e6d36d640a29dc893ecc81bc1a2eeead1edf38b8e62b9714ec5b229700eed2ce2dc673b8d8b52a1f352b9714e Full hashShort versionfe8b8e6d36d640a29dc893ecc81bc1a2eeead1edf38b8e62b9714ec5b229700eed2ce2dc673b8d8b52a1f352b9714e Full hashShort versionfe8b8e6d36d640a29dc893ecc81bc1a2eeead1edf38b8e62b9714ec5b229700eed2ce2dc673b8d8b52a1f352b9714e Full hashShort version Full hash Short version fe8b8e6d36d640a29dc893ecc81bc1a2eeead1edf38b8e6 fe8b8e6d36d640a29dc893ecc81bc1a2eeead1ed f38b8e6 2b9714ec5b229700eed2ce2dc673b8d8b52a1f352b9714e 2b9714ec5b229700eed2ce2dc673b8d8b52a1f35 2b9714e Every commit in Git has a unique hash that acts as its "ID." The hash is calculated based on the entire commit content, including: The file and directory structure (the “tree” object)The commit messageMetadata like author, committer, and timestampsThe hash of the parent commit(s) The file and directory structure (the “tree” object) The commit message Metadata like author, committer, and timestamps The hash of the parent commit(s) Git uses SHA-1 by default (or optionally SHA-256 as experimental feature). You typically don’t need the full hash - Git allows you to use a short version (usually 4–7 characters are sufficient). In my example, f38b and 2b97 f38b 2b97 So that’s how Git works locally. But what about GitHub? That’s where things get interesting. What about GitHub? GitHub, being a distributed platform built on top of Git, not only inherits Git's decentralized mechanics but also introduces its own layers of complexity and risks. GitHub Let’s revisit the experiment from earlier. I created a public repository and added two commits: I created a public repository and added two commits: Then I ran: Then I ran: git reset 10a47932  # (initial commit)
git push -f git reset 10a47932  # (initial commit)
git push -f What do we see on GitHub? The second commit is gone - erased from history. Sure, I can restore it using local Git tooling (as shown previously), but can we still access it on GitHub itself? Yes! You can access the commit directly in your browser using: https://github.com/<user>/<repo>/commit/<hash> https://github.com/<user>/<repo>/commit/<hash> For my example, https://github.com/C4tWithShell/demo/commit/cbc61bd83a87561c101a325b03ec9873a7c0cc62 https://github.com/C4tWithShell/demo/commit/cbc61bd83a87561c101a325b03ec9873a7c0cc62 GitHub warns: "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." But the entire commit content is still available. entire commit content is still available. Public repositories Since GitHub is a distributed platform, we can extend this idea to connected repositories - upstreams and their forks. Can I access commits from a deleted fork? I forked my demo repository, worked on it, and added a new .md file by mistake. .md Then realized my error and removed it via git push -f. git push -f I no longer see that commit, but is it really gone? is it really gone? Thanks to SHA-1 hashes, we can locate commits using just 4–7 hex characters. With only 65,536 (16⁴) possible combinations, brute-forcing short SHA prefixes is trivial for modern machines and fully automatable. I can still find that commit in my fork. I can also access it from the original repository, even if the fork was later deleted. original repository What If the Upstream Repo Is Deleted? Okay, let’s flip it. Suppose I commit a secret to the original repo, then delete it immediately before anyone forks it. Am I safe? original repo This time, let's even delete my upstream repository to be sure. After deleting my demo repository, I can see that there is no more "forked" link, and I can not see the SECRET.md file. SECRET.md This time, I create a fork of that fork, and dig through the commit history using the short SHA. This means I can still recover the SECRET.md commit! fork of that fork SECRET.md Because as long as one fork remains, the commit exists. one fork remains How is it possible? It is possible because of the repository network in GitHub - the web of relationships between a repository and its forks. You can explore it at: web of relationships between a repository and its forks https://github.com/<user>/<repo>/network https://github.com/<user>/<repo>/network It shows: Who forked the repo;How commits diverged across forks;Commits that exist in forks but not in the main repository. Who forked the repo; How commits diverged across forks; Commits that exist in forks but not in the main repository. not So when someone forks a repo, GitHub tracks the parent-child relationship. Even deleted or made-private forks may still be tracked in the network graph if: The fork was once public;Commits were pushed before the fork was deleted/private. The fork was once public; Commits were pushed before the fork was deleted/private. GitHub stores commit hashes that can remain accessible if you know the SHA, which is a known metadata leak vector. Does it affect private repos? Let’s try with a private repository. private repository I create a private repo and fork it. The fork remains private with no option to make it public. I added an extra file in the fork no option to make it public Even so, I can access this commit from the original repo using its short SHA. original repo At least in this case, visibility is controlled — the fork cannot be made public, and access is limited to collaborators. visibility is controlled But here's the real problem… I've seen companies open-source their internal repos. Before doing so, they often clean the main repo thoroughly. But what about the forks? But what about the forks? When a private repo is made public: The original repo’s fork network gets frozen at the moment of publication.All commits made before publishing in private forks may become publicly visible.GitHub does not warn you about this. The original repo’s fork network gets frozen at the moment of publication. original repo’s fork network All commits made before publishing in private forks may become publicly visible. commits made before publishing publicly visible GitHub does not warn you about this. does not warn So even if your main repo is clean, you might be exposing secrets from previous private forks. previous private forks Let’s test. I changed the visibility of my original repo. It has just one clean commit and only one file. Can I access the commit in my private fork? Can I access the commit in my private fork? Success! We can see all commits made in the private fork before the moment the original repository was published. To check, let's add a new commit to our private fork: Now let's try to access it from the public repository: Why is it so? Because once the repo goes public, GitHub separates the repository networks. Commits added later to a private fork become isolated. separates the repository networks This behavior applies both ways: This behavior applies both ways: Commits in private forks after publication are invisible from the public repo.Commits in the public repo after that point are invisible from the private fork. Commits in private forks after publication are invisible from the public repo. Commits in the public repo after that point are invisible from the private fork. Is it a bug? No, it is a designed behaviour of GitHub, and they even mention it in their documentation. Unfortunately, not that many people dig into it. Read below—GitHub on the visibility forks: Read below—GitHub on the visibility forks: GITHUB DOCSAbout permissions and visibility of forks - GitHub DocsThe permissions and visibility of forks depend on whether the upstream repository is public or private, and whether it is owned by an organization. GITHUB DOCSAbout permissions and visibility of forks - GitHub DocsThe permissions and visibility of forks depend on whether the upstream repository is public or private, and whether it is owned by an organization. GITHUB DOCSAbout permissions and visibility of forks - GitHub DocsThe permissions and visibility of forks depend on whether the upstream repository is public or private, and whether it is owned by an organization. GITHUB DOCSAbout permissions and visibility of forks - GitHub DocsThe permissions and visibility of forks depend on whether the upstream repository is public or private, and whether it is owned by an organization. GITHUB DOCS About permissions and visibility of forks - GitHub Docs The permissions and visibility of forks depend on whether the upstream repository is public or private, and whether it is owned by an organization. What can be done to fix it? 1. Treat GitHub as Public - Always 1. Treat GitHub as Public - Always Assume anything you push may be exposed eventually. Secrets don’t belong in Git. Use a secrets manager - Vault, AWS Secrets Manager, Doppler, GitHub Secrets, etc. don’t belong in Git 2. Clean properly before publishing 2. Clean properly before publishing Use tools like: TruffleHogdeepsecretsemgrep SecretsBFG Repo-Cleanergit filter-repo TruffleHog deepsecret semgrep Secrets BFG Repo-Cleaner git filter-repo I recommend: deepsecrets or semgrep-secrets combined with truffleHog or gitleaks. They detect secrets based on context, not just entropy or regex. e.g., passwd: hello may be missed by standard tools, but not by deepsecrets. But you should expect false positives  as well since it can be mentioned as examples;Automate the scanning in CI pipelines. deepsecrets or semgrep-secrets combined with truffleHog or gitleaks. They detect secrets based on context, not just entropy or regex. e.g., passwd: hello may be missed by standard tools, but not by deepsecrets. But you should expect false positives  as well since it can be mentioned as examples; deepsecrets semgrep-secrets truffleHog gitleaks based on context passwd: hello Automate the scanning in CI pipelines. 3. Contact GitHub Support for Removals 3. Contact GitHub Support for Removals If you've accidentally pushed sensitive data, GitHub can purge objects from its backend if you contact support but this is not instant or guaranteed. 4. Rotate secrets if they get exposed 4. Rotate secrets if they get exposed As the most important step, rotate secrets instead of trying to remove them. Once a secret is exposed, assume it’s compromised and change it. Don't risk it

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains new, firsthand information uncovered by the writer.

GitHub

Public

The Great Extinction: How AI Is Quietly Killing the Internet

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Why GitHub Commits Aren’t as Private as You Think

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Great Extinction: How AI Is Quietly Killing the Internet

102 Stories To Learn About Open Source Software

10 Repositories that Will Transform the Way You Approach Technical Interviews

10 Python Projects with 10 Lines of Code

10 GitHub Repositories to Follow

The Great Extinction: How AI Is Quietly Killing the Internet

102 Stories To Learn About Open Source Software

10 Repositories that Will Transform the Way You Approach Technical Interviews

10 Python Projects with 10 Lines of Code

10 GitHub Repositories to Follow

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps