Handling an Accidentally Committed and Pushed Password

1. What is it?

If a password, API key, token, connection string, or other secret is accidentally committed and pushed, it must be treated as compromised.

Simply deleting the password from the file and making another commit is not enough, because the secret can still exist in earlier Git commits and may already have been copied, cached, logged, or pulled by someone else.

The priorities are:

Secret exposed
     ↓
Revoke / rotate secret immediately
     ↓
Remove secret from current code
     ↓
Remove from Git history if required
     ↓
Prevent recurrence

The most important action is rotation/revocation, not merely deleting the Git commit.

2. Simple Syntax / Sample

Suppose this was accidentally committed:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=prod;User Id=admin;Password=MyPassword123;"
  }
}

Step 1 — Rotate the password

Change/revoke the exposed credential in the actual system first—for example, the database, Azure resource, GitHub token, or other credential provider.

The exposed value should never be trusted again.

Step 2 — Remove it from the source code

For example:

{
  "ConnectionStrings": {
    "DefaultConnection": ""
  }
}

Use an appropriate secrets mechanism instead, such as environment variables, Azure Key Vault, CI/CD secret variables, or .NET User Secrets for local development.

Step 3 — Prevent the secret file from being tracked

For a local secrets file:

appsettings.Local.json
.env

If Git already tracks the file:

git rm --cached appsettings.Local.json
git commit -m "Stop tracking local configuration"
git push

.gitignore prevents future untracked files from being added. It does not remove secrets from existing Git history.

3. Detailed Explanation

Assume I accidentally do:

git add .
git commit -m "Update database configuration"
git push origin main

The commit contains:

Password=MyPassword123

Now the password has reached the remote repository.

Step 1: Revoke or rotate the secret immediately

This is the first priority.

Old password: MyPassword123
                 ↓
              EXPOSED
                 ↓
         Disable/change it
                 ↓
New password: <new-secret>

Why first?

Even if I remove the password from Git five minutes later, someone or an automated system could already have obtained it.

So:

Removing the secret from Git does not make the exposed secret safe again.

For a password, change it. For an API key/token, revoke it and generate a replacement. Then update the applications or services that legitimately need the new credential.

4. Remove the Secret from the Current Version

Remove the hard-coded value from the application.

Instead of:

var password = "MyPassword123";

use configuration:

var password =
    builder.Configuration["Database:Password"];

The actual value can come from a secure configuration source.

For Azure-hosted applications, for example:

Application
     ↓
Configuration / managed identity
     ↓
Azure Key Vault
     ↓
Secret

This avoids storing the production secret in source control.

5. What About Git History?

Suppose:

A --- B --- C --- D
          ↑
     secret added

You later delete it in D:

A --- B --- C --- D
          ↑       ↑
       Secret   Deleted

The secret still exists in commit C.

Therefore, when repository history must be cleaned, you need a history-rewriting tool, such as git filter-repo. GitHub also documents procedures for removing sensitive data from repository history.

For example, depending on the cleanup scenario, git filter-repo can rewrite history to remove a sensitive file or replace sensitive text.

Because history rewriting changes commit IDs, it requires coordination when other developers use the repository.

Old history:

A --- B --- C --- D
          ↑
        Secret

Rewrite history
      ↓

A' --- B' --- C' --- D'
        Secret removed

Developers with old clones may still possess the old history, so history cleanup does not replace credential rotation.

6. Why Not Just Use git revert?

This is an important interview point.

Suppose the password was introduced in commit C.

You could run:

git revert C

That creates:

A --- B --- C --- R
          ↑       ↑
       Secret   Removed

But commit C still exists.

Anyone can potentially inspect that commit and see the old secret.

Therefore:

git revert
    ↓
Removes secret from current code
    ↓
BUT
    ↓
Does not erase it from previous history

git revert is excellent for safely undoing normal code changes on shared branches, but it is not sufficient for purging an exposed secret.

7. What About .gitignore?

Adding the file to .gitignore is useful for preventing future accidental additions:

.env
appsettings.Local.json
secrets.json

But it does not modify existing commits.

.gitignore
    ↓
Future tracking prevention

NOT

Existing history cleanup

Also, if a file is already tracked, simply adding it to .gitignore doesn't automatically stop Git tracking it.

For example:

git rm --cached appsettings.Local.json

followed by a commit can stop tracking it while retaining your local copy.

8. GitHub Secret Scanning

GitHub provides secret scanning capabilities that can identify many types of exposed credentials, and push protection can block supported secrets before they are pushed. Availability and behavior depend on repository/account configuration and the secret type.

A team can combine this with:

• protected branches
• Pull Request reviews
• CI/CD secret management
• environment variables
• Azure Key Vault
• .gitignore
• least-privilege credentials
• periodic secret rotation

9. Key Points

If I accidentally push a password:

1. Treat it as compromised.

2. Immediately revoke or rotate it.

Old secret → revoke
New secret → configure securely

3. Remove the hard-coded secret from the application.

4. Store the replacement securely, for example in:

Azure Key Vault
Environment variables
CI/CD secret variables
.NET User Secrets (development)

5. Clean Git history when necessary, using an appropriate history-rewriting process such as git filter-repo.

6. Coordinate history rewriting with the team, because rewritten commits get new hashes.

7. Do not assume these alone solve the exposure:

git revert

or:

appsettings.json

They do not erase the secret from historical commits.

Easy interview rule

Secret pushed
     ↓
ROTATE FIRST
     ↓
Remove from code
     ↓
Clean history
     ↓
Prevent recurrence

10. Interview Answer

If I accidentally committed and pushed a password, I would treat that password as compromised and immediately revoke or rotate it. Then I would remove the hard-coded secret from the application and move the replacement to a secure mechanism such as Azure Key Vault or environment/CI-CD secret variables. If the secret exists in Git history, I would follow the repository's incident procedure to purge it using an appropriate history-rewriting tool such as git filter-repo, coordinating with the team because rewriting history changes commit hashes. Simply deleting the password, using git revert, or adding the file to .gitignore is not sufficient because the exposed value can remain in Git history.