.gitignore, tags & releases

A clean repository contains source code and configuration templates, not virtual environments, compiled files or API keys. Once the code is clean, tags and releases tell users exactly which version they are running.

.gitignore

A .gitignore file lists patterns Git should not track. A good starting point for a Django project:

# Python
__pycache__/
*.py[cod]
.venv/
venv/

# Django
db.sqlite3
media/
staticfiles/

# Secrets and local config
.env
*.pem

# Editors / OS
.vscode/
.idea/
.DS_Store

Pattern	Meaning
*.log	Any file ending in .log, anywhere
/build	Only build at the repo root
media/	A directory named media, anywhere
!keep.log	Exception: do track this file

Commit a .env.example with dummy values so teammates know which variables to set.

Already committed it?

.gitignore only affects untracked files. To stop tracking a file that is already committed:

git rm --cached db.sqlite3          # removes from the index, keeps your local copy
echo "db.sqlite3" >> .gitignore
git commit -m "Stop tracking local database"

If that file was a secret, it still exists in older commits: rotate the credential. Rewriting history with a tool such as git filter-repo is possible but does not help if someone already cloned it.

Use git check-ignore -v path/to/file to find which rule is ignoring a file.

Tags

A tag is a permanent name for a specific commit, usually a version number. Prefer annotated tags: they store the author, date and a message.

git tag -a v1.4.0 -m "Invoice PDF export and GST summary"
git tag                              # list tags
git show v1.4.0
git push origin v1.4.0               # tags are not pushed by default
git tag -a v1.3.1 9f2c4ab -m "Hotfix"   # tag an older commit

Semantic versioning

MAJOR.MINOR.PATCH: bump PATCH for bug fixes, MINOR for backwards-compatible features and MAJOR for breaking changes. Going from v1.4.0 to v2.0.0 warns users that something may break.

GitHub releases

A release is a GitHub page built on a tag: release notes, a changelog and optional downloadable files. Create one on the repo's Releases page, or with the GitHub CLI:

gh release create v1.4.0 --title "v1.4.0" --generate-notes

--generate-notes builds notes from the merged pull requests since the previous release, another reason to write good PR titles.

Key takeaways

• Add .gitignore in the very first commit.
• Never commit .env, keys or databases; provide an example file instead.
• Use annotated, semver tags and push them explicitly.
• Releases turn tags into readable, shareable version history.