.gitignore
A Git configuration file used to specify patterns of files and directories to ignore, preventing sensitive or irrelevant files from being accidentally committed to a repository.
Timeline (last 90 days)
User-level instruction files (such as `~/.claude/CLAUDE.md`) should be excluded via `.gitignore`, committing only the shared files in the project root directory.
Adding the .env file to .gitignore can prevent it from being accidentally committed, but if the .env file is already tracked or has already been committed to history, merely adding .gitignore is not enough to remove it; you need to use git rm --cached to stop tracking it and may need to use git filter-branch or BFG Repo-Cleaner to clean the history.
Creating a .bolt/ignore file in the Bolt.new project root (with syntax similar to .gitignore) prevents the context indexer from reading the specified files, and in testing reduced the context weight of a single prompt by 35% to 50%.
Git provides three ignore files: the project-level .gitignore, the global core.excludesFile, and the local .git/info/exclude
The .gitignore in the project root is committed along with the code, so team members share the same set of ignore rules
Writing personal editor configurations into the project .gitignore is a common but inelegant practice that causes the shared file to gradually bloat
.gitignore rules are processed line by line from top to bottom, and rules appearing later override earlier ones.
The 'ignore everything by default' whitelist pattern ignores all files via *, then explicitly adds back files to be tracked using rules with the ! prefix.
The main drawback of the whitelist pattern is that every time a new file type is added, the .gitignore must be manually updated, increasing maintenance overhead.
Data science and machine learning projects are well suited to whitelist-style .gitignore, with data and models preferably managed through dedicated tools such as DVC.
1 more timeline events
All Facts (12)
Cursor的.cursorignore文件设计灵感来源于Git的.gitignore机制，两者共享相同的glob语法规范
85%UnverifiedUser-level instruction files (such as `~/.claude/CLAUDE.md`) should be excluded via `.gitignore`, committing only the shared files in the project root directory.
50%UnverifiedAdding the .env file to .gitignore can prevent it from being accidentally committed, but if the .env file is already tracked or has already been committed to history, merely adding .gitignore is not enough to remove it; you need to use git rm --cached to stop tracking it and may need to use git filter-branch or BFG Repo-Cleaner to clean the history.
50%UnverifiedCreating a .bolt/ignore file in the Bolt.new project root (with syntax similar to .gitignore) prevents the context indexer from reading the specified files, and in testing reduced the context weight of a single prompt by 35% to 50%.
50%UnverifiedThe .gitignore in the project root is committed along with the code, so team members share the same set of ignore rules
50%UnverifiedWriting personal editor configurations into the project .gitignore is a common but inelegant practice that causes the shared file to gradually bloat
50%UnverifiedGit provides three ignore files: the project-level .gitignore, the global core.excludesFile, and the local .git/info/exclude
50%UnverifiedThe traditional .gitignore uses a blacklist pattern, where all files are tracked by default and only the exceptions to be excluded are listed.
50%Unverified.gitignore rules are processed line by line from top to bottom, and rules appearing later override earlier ones.
50%UnverifiedThe main drawback of the whitelist pattern is that every time a new file type is added, the .gitignore must be manually updated, increasing maintenance overhead.
50%UnverifiedData science and machine learning projects are well suited to whitelist-style .gitignore, with data and models preferably managed through dedicated tools such as DVC.
50%UnverifiedThe 'ignore everything by default' whitelist pattern ignores all files via *, then explicitly adds back files to be tracked using rules with the ! prefix.
50%