What .gitignore actually does
A .gitignore file tells Git which untracked paths it should usually leave out of its status display and future commits. It is useful for generated output, temporary files, local settings, and other files that should not normally be shared with a project. For example, a web project might ignore a build directory because teammates can recreate its contents from the source files.
Git makes an important distinction between untracked files and tracked files. An untracked file has not been added to Git’s index. A tracked file is already part of the repository’s recorded work, even if you later add its name to .gitignore. Ignore rules apply to untracked files; they do not tell Git to forget something it already tracks. That is why editing .gitignore alone will not make a previously committed file disappear from git status or stop its changes from appearing in commits.
Create rules for files you do not want to add
You need Git installed, a terminal, and a Git repository to try these examples. They use basic Git command-line features available in modern Git versions; no particular version is required. In the repository’s top-level directory, create or edit a plain-text file named .gitignore. Put one pattern on each line. For example, a file containing the lines "node_modules/", "dist/", and ".env" ignores directories with those first two names and files named .env within the scope of that .gitignore file.
Patterns deserve a quick review before you commit them. A trailing slash limits a pattern to directories. A leading slash anchors it to the directory containing that .gitignore file: "/dist/" matches the top-level dist directory when the file is at the repository root, rather than every dist directory below it. A line beginning with # is a comment. To keep a harmless example of a configuration file in the repository, you could ignore ".env" while tracking a separately named file such as ".env.example" containing placeholder values.
Commit .gitignore so other contributors receive the same rules. Ignore only files that should be excluded for the project; a broad rule can hide work you meant to add. If you are unsure whether a new file is being ignored, run "git status --ignored" to include ignored paths in the status display. For a particular path, "git check-ignore -v --no-index path/to/file" can show the matching rule even when that path is already tracked.
Stop tracking a file without deleting your local copy
Suppose config/local.json was committed earlier, but it should now be a local-only file. First, add an appropriate rule, such as "/config/local.json", to the repository’s top-level .gitignore. Then run "git rm --cached config/local.json" from the repository root. The --cached option removes the path from Git’s index while leaving the file in your working directory. Without --cached, git rm would also remove the working copy, so check the command before running it.
Run "git status" afterward. You should see the tracked file staged for deletion from the repository, along with the .gitignore change if you have staged it. Your local copy should still be present. Once you have reviewed the result, stage .gitignore with "git add .gitignore" and commit both changes. The commit removes the file from the repository’s current tracked contents; the ignore rule helps prevent your local copy from being added again by an ordinary "git add .".
For a tracked directory of generated files, the corresponding command is "git rm -r --cached path/to/directory". Review the staged changes carefully before committing: this stages removal of every tracked file under that directory. If you work with others, tell them about the change. When they receive the commit, Git will remove those files from their checked-out repository contents unless their own local changes require attention.
Know what an ignore rule cannot fix
Ignoring a path does not erase it from earlier commits. Neither does "git rm --cached"; it changes what the repository tracks going forward. If a committed file contained a password, token, or other secret, treat that secret as exposed and replace or revoke it through the relevant service. Changing repository history is a separate, more disruptive task that may require coordination with collaborators; adding a .gitignore rule is not a substitute.
A useful routine is to add ignore rules before generating local files, then check "git status" before each commit. If a file you expected Git to ignore still appears as modified, ask whether it is already tracked. If it is, decide whether the project should keep tracking it or whether to remove it from the index with --cached. That distinction—untracked versus tracked—is the key to understanding nearly every .gitignore surprise.
