Why is a file still tracked after I added it to .gitignore?
.gitignore only affects untracked files. Run git rm --cached on the file, commit, and it will be ignored from then on.
Merged, de-duplicated, correct.
Tick your stack and get one clean .gitignore. Rules keep their order so negations still work, duplicates are dropped, and lockfiles stay in version control where they belong.
Loading the toolbox.
You do not have to take our word that your data stays here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.
F12, or Cmd+Option+I on a Mac, and select the Network tab.Only two things can add a line to that log, and neither carries your data. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.
The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint, so a coding mistake could not quietly send your data elsewhere.
A .gitignore file tells git which files to leave untracked: dependencies you can reinstall, build output you can regenerate, editor settings that belong to one person, operating system clutter, and secrets. Each line is a pattern. A trailing slash matches only folders, a leading slash anchors the pattern to the folder that holds the .gitignore, * matches anything except a slash, and ** matches across folders.
A line that starts with ! re-includes something an earlier pattern excluded. git reads the file from top to bottom and the last matching pattern wins, which is why order matters.
The original 2gitignore sorted every rule alphabetically. That put !.vscode/settings.json above .vscode/, so git re-included the file and then ignored it again, and every shared editor setting silently disappeared from the repository. 2gitignore now keeps each fragment in its original order.
A second subtlety: git cannot re-include a file inside a folder that is itself ignored. The VS Code fragment therefore ignores .vscode/*, the folder's contents, rather than the folder, so the four shared files can be brought back.
No. package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum, Cargo.lock, composer.lock, and Gemfile.lock record the exact versions that were installed and tested. Committing them means every developer, CI run, and deploy installs the same dependency tree. Ignoring them is how a build that passed yesterday fails today.
The previous version ignored several lockfiles by default. This one never does, and a test checks every lockfile against every fragment combined.
Node and Python fragments ignore .env and its variants but keep .env.example, so the template your team relies on is still committed.
Elsewhere in the toolbox: 2hash, 2base, 2otp, 2xml, and more on the 2toolbox home page. Part of the 2suite.io privacy-first ecosystem.
.gitignore only affects untracked files. Run git rm --cached on the file, commit, and it will be ignored from then on.
In the repository root. You can add more in subfolders; their patterns are relative to their own folder.
Personal settings, yes. Shared files such as .vscode/settings.json and extensions.json are worth committing, and the VS Code fragment keeps them.
Add it to .git/info/exclude, which works like .gitignore but is never committed.