Git for Bot Projects: Tested Ignore Rules, Secret Response and Releases

한국어로 읽기

TECH INSIGHT / EXPLAINED

A useful Git workflow records code changes while keeping real credentials outside the repository. Ignore rules, staged-diff review, secret detection and a traceable deployment record work together; none is a complete guarantee by itself.

AI-generated educational illustration. Three colleagues review staged changes, keep credentials outside Git and label a verified release.

Start with tested ignore rules

Create a placeholder-only config.example.ini and keep real configuration separate. A # starts a comment line in .gitignore; it is not a safe inline comment after an exception pattern. The exception must therefore be exactly !config.example.ini. These rules cover common project paths and should be tested against your actual filenames.

# Keep comments on their own lines.
config*.ini
!config.example.ini
.env*
!.env.example
secrets/
keystore/
*.key
*.pem
logs/
data/
__pycache__/
.venv/

Review the staged snapshot

git diff without --cached shows working-tree changes relative to the index, not everything about to be committed. Inspect staged filenames first, then review the staged content and run the configured secret scanner. Scan results can have false negatives; local hooks can be bypassed. Use available server-side push protection as another layer.

git check-ignore -v --no-index -- config_real.ini .env
git status --short
git add -- .gitignore config.example.ini
git diff --cached --name-status
git diff --cached -- .gitignore config.example.ini

Already tracked is different from ignored

Adding a pattern does not remove an already tracked file. After preserving the local file and reviewing the intended index change, git rm --cached -- config.ini removes it from tracking while leaving it on disk. Stage the ignore rule as well. This changes future snapshots, not the old history.

An environment variable avoids a source literal but can still leak through shell history, CI logs, debugging output or a committed .env file. Use the deployment platform’s secret facility where practical, restrict access and validate that placeholders cannot start a live integration.

Treat exposure before rewriting history

For a disclosed API credential, revoke or rotate it at the provider and investigate access and account activity. Then remove sensitive copies from affected history, artifacts and logs. A private key has a different recovery model: it cannot be made secret again by editing Git, and any asset migration requires a separate, carefully verified recovery process.

Follow the hosting provider’s sensitive-data removal procedure with collaborators. History rewriting changes commit IDs and can affect tags, pull requests, signatures and existing clones; forks and cached copies may remain. A generic force push to every branch is not a complete cleanup procedure. History cleanup is part of containment, while revocation removes the credential’s continuing authority.

Record what is deployed, not just a branch name

A solo project may use main plus short-lived feature branches; a dev branch is optional when it serves a real integration stage. Branch pointers move. Record the deployed commit, tested image digest, configuration revision and database schema in a release manifest.

Checking out an old tag changes local files; it does not replace a running process, restore a database or reconcile orders. Rollback means deploying the reviewed artifact with compatible state, stopping duplicate workers and confirming account/order state. Commit messages should explain the change and its evidence; hypothetical fee calculations must not be presented as measured profit.

Sources and further reading

Git ignore syntax · Git staged diff · GitHub sensitive-data removal · GitHub secret scanning

Content and examples reviewed: 2026-09-29