How to use .gitignore and avoid uploading secrets to GitHub
Published on 2026-10-26 by frfrand
gitignore patterns, already versioned files, and secret rotation
You uploaded a project to GitHub and discovered you also pushed .env, temporary files, and a huge dependencies folder. .gitignore prevents Git from starting to track certain files, but it has an important limitation: it does not delete what you already published.
The idea is to use it to solve a real problem, not to memorize commands because they look good in a screenshot. Let's go with the essentials, a work example, and the mistakes you should avoid.
What .gitignore does and when it is useful
Patterns are normally applied to untracked files. A file versioned before adding it to .gitignore will continue to be tracked. To stop including it in future commits you can remove it from the index, but if it contained a secret, the credential is already compromised and must be rotated.
If you are learning, try it first in a test repository or environment. If you manage production, document the state before executing anything that alters files, history, or data. This allows you to understand what changed and recover if you make a mistake.
Example to copy and understand
# Ejemplo .gitignore
.env
.env.*
!.env.example
node_modules/
__pycache__/
*.pyc
# Si .env ya estaba versionado
git rm --cached .env
git commit -m 'dejar de versionar entorno'Do not copy the final command without checking the previous state. Branch names, host, user, or paths are examples; replace them with those of your project. Some commands modify files or make requests that may write data.
How I would use it step by step
- Step 1. Identify what your project generates and what another developer really needs.
- Step 2. Add patterns for temporary files and secrets; leave a
.env.examplewithout private values. - Step 3. Check why a path is ignored with
git check-ignore -v path. - Step 4. If credentials were already in commits, revoke and replace them immediately.
- Step 5. Use a secret manager for deployments and a leak scanner in CI when possible.
Stop after each step and check the result. If something fails, note the exact message before changing strategy. Jumping between five random solutions usually makes it harder to find the real cause.
A case that could happen to you working with clients
A bot that queries an AI API needs a provider key. The repository must contain how to configure AI_API_KEY, not the real value. The application receives the credential from the environment when it runs.
The goal is not for it to "work once," but for you to be able to explain how you repeat it without compromising another application. If there are client data or credentials, work with separate tests and minimal accesses.
The mistake I see most often
git rm --cached does not remove the secret from remote history or old clones. For a leaked key, rotating and reviewing accesses is urgent; cleaning history can be additional, but it does not substitute that measure.
A simple rule: if you can't explain what the command will do to your code or server, check its official help first. This way you avoid confusing a quick fix with a new problem.
Where does ArduMaker come in?
When deploying from Git in ArduMaker, prepare secure variables in the execution environment and do not embed passwords in the frontend. Separate access by client and by service.
For example, you can deploy from a Git repository to a VPS, associate an HTTPS domain, and manage services and databases from the same environment. The panel reduces repetitive infrastructure tasks, but does not replace Git, testing, or project permission review.
Quick questions before applying it
Does this change production? It depends on where you run the action. Test locally first, identify the affected commit or service, and prepare a recovery plan.
How do I check that it went well? Don't settle for the absence of error messages: check the status, run a functional test, and verify the corresponding logs or history.
Is it worth automating it? If it is repeatable and has verifiable results, yes. But automation should fail clearly and not hide errors or credentials.
To expand
Summary: the useful tool is not the one with the most options, but the one that allows you to understand what changed, verify it, and keep working without surprises.