Why must API keys and access tokens remain outside the Git repository?

Why must API keys and access tokens remain outside the Git repository?

API keys and access tokens can authorize actions against external services. In a wedding application, a leaked email token might allow message sending, while a storage credential might expose private photos. Committing these values copies that authority into every repository clone and any other system that receives the history.

Separate application code from credentials

Application code should refer to a configuration name, such as an email-service token variable, without containing its secret value. Developers can use appropriately protected local configuration, while hosted environments should receive secrets through their designated configuration or secret-management facility.

A committed example file can show variable names and clearly fake placeholders. It should explain which service supplies each value and whether the variable is required. This lets an AI agent understand setup without needing production credentials.

Review more than obvious environment files

Secrets can appear in screenshots, copied error messages, test fixtures, scripts, or generated documentation. Inspect the intended commit, including newly added files, and use available secret-scanning protections.

An ignored file is not automatically confidential: local access, logs, or an accidental paste can still expose its contents. Likewise, browser-visible configuration must never contain a private service token, regardless of whether its original file was excluded from Git.

Respond to exposure at the service

If a real token enters shared history, revoke or rotate it promptly. Deleting the current line does not remove earlier copies. GitHub's guidance places credential revocation or rotation before coordinated history cleanup. GitHub secret-removal guidance.

Then replace affected deployment configuration, inspect relevant service activity, and address how the credential was committed. Coordinate any necessary history rewrite with collaborators. The practical goal is to remove the exposed credential's authority and prevent the same release path from leaking its replacement.