Python generiert viele Dateien, die nicht committed werden sollten: kompilierter Bytecode (__pycache__, .pyc), Virtual-Environment-Verzeichnisse, Distributionspakete, Coverage-Reports und IDE-spezifische Einstellungen.
Diese Vorlage verwendet die offizielle GitHub Python gitignore kombiniert mit VirtualEnv-Regeln und gängigen IDE/OS-Mustern. Sie funktioniert mit pip, poetry, pipenv, conda, pytest, mypy und allen wichtigen Python-Workflows.
Anleitung
1. Überprüfe die unten vorausgewählten Vorlagen
2. Füge Vorlagen hinzu oder entferne sie, um sie an dein Projekt anzupassen (z.B. Django, Flask hinzufügen)
3. Klicke auf "Kopieren" oder "Herunterladen", um die Datei zu erhalten
4. Platziere sie im Stammverzeichnis deines Projekts
Haufig gestellte Fragen
Sollte ich meine virtuelle Umgebung committen?
Niemals. Virtuelle Umgebungen (venv, .venv, env) können riesig sein und sind maschinenspezifisch. Füge sie zu .gitignore hinzu und verwende requirements.txt oder pyproject.toml, um sie neu zu erstellen.
Sollte ich __pycache__ und .pyc-Dateien ignorieren?
Ja. Dies sind kompilierte Bytecode-Dateien, die automatisch von Python generiert werden. Sie sind maschinenspezifisch und werden neu generiert, wenn Python deinen Code ausführt.
Sollte ich Jupyter-Notebook-Checkpoints committen?
Nein. Das .ipynb_checkpoints-Verzeichnis wird automatisch von Jupyter generiert und sollte ignoriert werden. Die Notebooks selbst (.ipynb-Dateien) sollten committed werden.
Was ist mit requirements.txt und pyproject.toml?
Diese sollten immer committed werden. Sie definieren deine Projektabhängigkeiten und ermöglichen es anderen, die Umgebung zu reproduzieren. requirements.txt wird traditionell mit pip verwendet, während pyproject.toml der moderne Standard für Poetry und pip ist.
Sollte ich .pytest_cache und .mypy_cache ignorieren?
Ja. Diese Cache-Verzeichnisse beschleunigen wiederholte Läufe von pytest und mypy, sollten aber nicht committed werden. Sie werden bei Bedarf automatisch neu erstellt und können zwischen verschiedenen Python-Versionen inkompatibel sein.
Wie gehe ich mit Secrets in Python-Projekten um?
Verwende .env-Dateien für Geheimnisse und füge .env* zu .gitignore hinzu. Lade Umgebungsvariablen mit python-dotenv. Committe eine .env.example-Datei, die die benötigten Variablen ohne echte Werte dokumentiert.
Sollte ich das .eggs- oder dist-Verzeichnis ignorieren?
Ja. Diese Verzeichnisse enthalten Build-Artefakte (Python-Pakete für Distribution). Sie werden beim Erstellen von Paketen mit setup.py oder poetry generiert und sollten nicht im Repository sein, da sie aus dem Quellcode neu erstellt werden können.