Git-Trick: Alles standardmäßig ignorieren – so vermeidest du versehentliche Commits
.gitignore Everything by Default
Ein Blogbeitrag schlägt vor, die Git-Dateiverwaltung umzukehren: Statt alles zu verfolgen und Ausnahmen zu ignorieren, solltest du alles ignorieren und nur bestimmte Dateien explizit erlauben. Mit einer .gitignore-Datei, die `*` enthält und dann Ausnahmen wie `!.gitignore`, `!*.go`, `!go.mod` und `!go.sum` definiert, werden nur die gewünschten Dateien versioniert. Das verhindert versehentliche Commits von .DS_Store, node_modules oder Umgebungsvariablen. Der Autor räumt ein, dass die Technik nicht für jedes Projekt geeignet ist, verweist aber auf ein 207-zeiliges .gitignore von typescript-go als Beispiel und gibt Tipps zur Überprüfung ignorierter Pfade sowie einen Hinweis auf lazygit.
Statt alles standardmäßig zu erlauben und Dateien selektiv zu ignorieren, was wäre, wenn wir alles standardmäßig ignorieren und nur bestimmte Dateien erlauben würden?
- rcfox
Das scheint mir ein schlechter Ratschlag zu sein. Ich habe nur sehr selten versehentlich zusätzliche Dateien committet, aber ich würde zu 100 % vergessen, Dateien, die ich committen wollte, wieder zu ent-ignorieren. Wenn du schon einen ersten Einrichtungsschritt machst, um alles zu ignorieren, warum nicht gleich einen ersten Einrichtungsschritt, um die üblichen Dateien zu ignorieren? Erstelle eine Vorlage, die du in alle deine Repos kopierst.
- Brajeshwar
Es ist seltsam, dass einige Entwickler mit Ratschlägen um die Ecke kommen, die so klingen, als kämen sie aus einer Welt, in der sie allein arbeiten, nicht mit genug Leuten oder an genug Projekten. In diesem Fall kümmert sich eine `.gitignore_global` um die üblichen Verdächtigen, die er erwähnt hat (`.DS_Store`-Dateien, IDE-Konfigurationen, komprimierte Dateien usw.). Selbst wenn etwas schiefgeht, wird es normalerweise beim anfänglichen Scaffolding erwischt, bevor kritische Dateien hineinkommen. Wenn man mit neuen, jungen, unerfahrenen Entwicklern arbeitet, gibt ihnen die typische Lektion über die globale Git-Ignore, lokale Konfiguration, und dass sie Dotfiles haben sollen, usw. Gib deine als Inspiration oder als Ausgangspunkt. Bearbeitung: Ich weiß, dass meine nicht die besten Dotfiles im Internet sind, aber sie haben mir geholfen, problemlos zwischen mehreren Geräten, mehreren Identitäten (Arbeit, Projekte, privat usw.) zu wechseln. Ich habe sie kürzlich aufgeräumt und Automatisierung, Tests usw. mit Claude Code hinzugefügt. https://github.com/brajeshwar/dot
- isityettime
Wie wäre es, einfach zu lernen, `git add` richtig zu verwenden? Bist du so darauf fixiert, ständig `git add -A` einzuhämmern? Es ist nicht schwer, nicht committete Dateien im Arbeitsverzeichnis zu haben, ohne sich mit .gitignore herumzuschlagen.
- caseyw
Ich ignoriere nicht standardmäßig, sondern stage nur die Elemente, die ich explizit möchte. Ich kann dir nicht sagen, wie oft ich mit jemandem gepairt habe und sie einfach sagen: „git add .“, ich bin von dieser Wahl immer verwirrt. Ich verstehe es, aber ich habe mehr Probleme durch das Hinzufügen aller Dateien gesehen als durch konsequentes selektives Vorgehen. Jedem das Seine.
- flexagoon
> anderer Kram (CLAUDE.md zum Beispiel), der nicht in dein Repository gehört. Wie ist CLAUDE.md/AGENTS.md „Kram, der nicht in dein Repository gehört“? Wenn du Agenten für ein Projekt verwendest und projektspezifische Regeln für sie hast, warum solltest du wollen, dass andere Leute, die Agenten in deinem Repository verwenden, keinen Zugriff auf diese Regeln haben und schlechteren Code produzieren?
- yipinwong
Eine sehr sicherheitsingenieur-orientierte Herangehensweise. Ich blockiere jeden Port für VPS und öffne dann einen nach dem anderen. Hier derselbe Ansatz mit Dateien. Der einzige Nachteil, den ich hier sehe, ist zu wissen, welche man zulassen soll. Bei Ports ist das einfach, aber Dateien können viele verschiedene Erweiterungen haben. Apps/CLIs usw. erstellen Dateien mit Erweiterungen, die du noch nie gesehen hast, was Probleme verursachen kann. Abgesehen davon mag ich den Ansatz.
- matthewmc3
Ich bin nicht überzeugt davon, alles zu ignorieren, aber eine der besten Änderungen, die ich je an meinem Git-Workflow vorgenommen habe, war, alle Dotfiles standardmäßig zu ignorieren, indem ich `.*` zu ~/.config/git/ignore hinzugefügt habe. Meine Projekte müssen jetzt eine Standardvorlage haben, um die üblichen wieder zu ent-ignorieren (!.gitignore, !.gitattributes, !.github, !.editorconfig usw.), aber dann kann ich jederzeit .foo.lang-Dateien, .tmp/.cache-Verzeichnisse, Claude-Helfer wie .code_analysis.md oder .todos.txt oder was auch immer in mein Projekt werfen, ohne die Auswirkungen zu verwalten, wenn ich vergesse, die .gitignore zu verwalten. Ich bin überrascht, dass nicht mehr Leute diesen Weg gehen.
- ryanbrunner
Das Problem bei diesem Ansatz (das ihr erstes Beispiel bereits zeigt) ist, dass man fast sofort mit einer Lösung „dieser Dateityp ist in Ordnung“ beginnt, und ob etwas in Git soll, hat nicht wirklich eine starke Korrelation mit dem Dateityp. Es behindert `git status` und zwingt dich im Wesentlichen dazu, selbst im Blick zu behalten, was du geändert hast (da ignorierte Dateien dort nicht auftauchen), und es kann ein falsches Sicherheitsgefühl vermitteln, dass `git add .` sicher ist, obwohl es das vielleicht nicht ist.