Kostenloser .gitignore-Generator

Der .gitignore Generator ist ein kostenloses Online-Tool, das .gitignore-Dateien mit den passenden Regeln für jede Programmiersprache, jedes Framework oder jede IDE erstellt.

Ja, er ist völlig kostenlos und erfordert keine Registrierung. Die gesamte Dateierstellung erfolgt clientseitig in Ihrem Browser.

Der .gitignore Generator bietet Vorlagen für Node.js, Python, Java, Go, Rust, React, Angular, Vue und Dutzende weiterer Sprachen und Frameworks.

Absolut. Der .gitignore Generator verarbeitet alles clientseitig in Ihrem Browser. Es werden keine Daten an einen Server hochgeladen oder dort gespeichert. Ihre Inhalte bleiben jederzeit privat auf Ihrem Gerät.

Ja, der .gitignore Generator ist vollständig responsiv und funktioniert auf Smartphones und Tablets. Sie können ihn auf jedem Gerät mit einem modernen Webbrowser nutzen, ganz ohne App-Download.

Es ist kein Konto und keine Registrierung erforderlich. Öffnen Sie einfach den .gitignore Generator in Ihrem Browser und legen Sie sofort los. Es gibt keine Anmeldebarrieren und keine Nutzungsbeschränkungen.

Geben Sie einfach Ihre Eingabe in das vorgesehene Feld ein, passen Sie die Einstellungen nach Wunsch an, und das Tool verarbeitet sie sofort. Anschließend können Sie das Ergebnis in die Zwischenablage kopieren oder herunterladen.

Der .gitignore Generator funktioniert in allen modernen Browsern, darunter Chrome, Firefox, Safari, Edge und Opera. Für das beste Erlebnis verwenden Sie die neueste Version Ihres bevorzugten Browsers.

Eine .gitignore wirkt sich nur auf nicht verfolgte (untracked) Dateien aus. Sobald Git eine Datei bereits verfolgt, bewirkt ein passendes Muster nichts mehr — Git behält sie im Blick, weil sie Teil des Index ist. Die Lösung: Beende die Verfolgung der Datei, während sie auf der Festplatte erhalten bleibt, mit git rm --cached pfad/zur/datei, oder git rm -r --cached ordner/ für ein ganzes Verzeichnis, und committe die Änderung anschließend. Die Datei gilt danach als nicht verfolgt, und die Ignorier-Regel greift. Das passiert häufig bei einer .env-Datei, einem Build-Ordner oder node_modules/, die sich eingeschlichen haben, bevor du Regeln hinzugefügt hattest. Beachte, dass die Datei auch nach dem Entfernen in der Projekthistorie erhalten bleibt — ein committetes Secret sollte also zusätzlich rotiert und nicht nur ignoriert werden. Erstelle hier zunächst dein Regelwerk, füge es in dein Repository ein und nutze den integrierten Pfad-Tester, um vor dem Aufräumen zu bestätigen, dass das Muster passt.

Diese Zeichen bestimmen, wie breit ein Muster greift. Ein einzelnes Sternchen (*) steht für beliebige Zeichen außer einem Verzeichnistrenner, sodass *.log zwar build.log erfasst, nicht aber logs/app.log. Ein doppeltes Sternchen (**) greift über mehrere Verzeichnisebenen hinweg, sodass logs/**/debug.log jede Tiefe erreicht. Ein abschließender Schrägstrich wie build/ zielt ausschließlich auf Verzeichnisse, ignoriert also einen Ordner samt Inhalt, lässt aber eine Datei namens build unangetastet. Ein führender Schrägstrich verankert ein Muster am Repository-Root, sodass /config nur die oberste config erfasst, nicht verschachtelte Varianten. Ein ? steht für genau ein Zeichen, und [abc] für eines der aufgelisteten Zeichen. Ein führendes ! hebt eine vorherige Regel auf, damit du eine einzelne Datei wieder sichtbar machen kannst, und Zeilen, die mit # beginnen, sind Kommentare. Die Vorlagen dieses Generators nutzen diese Regeln bereits korrekt, und der Tab „Muster-Referenz“ fasst jede davon zusammen. Baue deine Datei oben zusammen und teste einen Beispielpfad, um genau zu sehen, welche Regeln greifen.

Stack-Presets sind Ein-Klick-Abkürzungen, die eine kuratierte Auswahl an Vorlagen für eine gängige Technologie-Kombination laden, damit du dir das Durchsuchen der Liste sparst. Die Auswahl von MERN wählt gleichzeitig Node.js, React, MongoDB, macOS und VS Code aus, während LAMP PHP, Laravel, macOS und Linux lädt. Insgesamt gibt es acht Presets, die außerdem Python ML, Flutter, Full Stack JS, Java Spring, Go API und Rust abdecken. Jedes Preset ersetzt deine aktuelle Auswahl, statt sie zu ergänzen, und liefert dir so einen sauberen Ausgangspunkt. Nach der Anwendung kannst du weiterhin einzelne Vorlagen ein- oder ausschalten, unten eigene Regeln ergänzen und jedes nicht benötigte Vorlagen-Badge entfernen. Presets sind der schnellste Weg, wenn dein Projekt einem Standard-Stack entspricht — wähle oben eines aus und feile dann am Ausgabefeld, bis die Datei genau zu deinem Repository passt.

Dateien, die von deinem Betriebssystem oder Editor erzeugt werden — .DS_Store unter macOS, Thumbs.db unter Windows oder die Ordner .idea/ und .vscode/ — sind persönlich für deinen Rechner, nicht für das Projekt. Sie in eine gemeinsam genutzte Projekt-.gitignore aufzunehmen funktioniert zwar, überfrachtet die Datei aber und setzt voraus, dass jeder im Team dasselbe Betriebssystem und denselben Editor nutzt. Sauberer ist eine globale gitignore, die für jedes Repository auf deinem Computer gilt. Du richtest sie einmalig ein mit git config --global core.excludesfile ~/.gitignore_global und fügst danach deine Betriebssystem- und Editor-Muster in diese Datei ein. Dieser Generator zeigt genau diesen Befehl unter der Option „Globale Konfiguration“ an, und die einzelnen Betriebssystem- und IDE-Vorlagen hier lassen dich die passenden Muster in deine globale Datei übernehmen. Erzeuge oben die Muster und entscheide dann, welche in die Projektdatei gehören und welche in deine globale.

Der integrierte Pfad-Tester liefert eine schnelle, nützliche Annäherung, ist aber keine vollständige Nachbildung von Gits Abgleich-Engine. Du gibst einen Dateipfad wie src/node_modules/test.js ein, und er zeigt sofort an, ob deine aktuellen Regeln ihn als „Ignoriert“ oder „Nicht ignoriert“ einstufen — praktisch, um ein Muster vor dem Commit auf Plausibilität zu prüfen. Im Hintergrund kommt ein vereinfachter Abgleich statt der vollständigen gitignore-Spezifikation zum Einsatz, weshalb ungewöhnliche Randfälle — komplexe Negationen, bestimmte Klammerausdrücke oder die Rangfolge zwischen sich überschneidenden Regeln — nicht immer exakt so aufgelöst werden wie bei Git. Für alltägliche Muster wie Ordner, Dateiendungen und Wildcards ist er zuverlässig. Überrascht dich ein Ergebnis, prüfe es zusätzlich mit git status oder git check-ignore in deinem echten Repository. Erstelle oben dein Regelwerk, teste ein paar repräsentative Pfade und verifiziere alles Kritische anschließend direkt in Git.