Not every file belongs in history
A project can contain files that are generated, very large, specific to one computer or private.
Common examples:
node_modules/
.next/
dist/
.env
*.log
Dependencies can normally be installed again from package.json. Build folders can be generated again. Environment files may contain passwords, tokens or private configuration.
Tell Git what to ignore
Create a file named .gitignore in the repository root:
node_modules/
.next/
dist/
.env
*.log
Then run:
git status
Ignored files should no longer appear as new files.
Ignoring is not removing history
.gitignore mainly prevents untracked files from being added. If .env was already committed, adding it to .gitignore does not erase it from earlier commits.
If a secret was committed or pushed, treat it as exposed. Revoke or rotate the secret first, then remove it from tracking and investigate the history with appropriate guidance.
Share an example, not a secret
Keep a safe template such as .env.example:
API_URL=
API_KEY=
It documents required names without publishing real values.
How the rule appears in practice
Before the ignore rules exist, git status can show debug.log and .env as untracked files. After the matching rules are saved, Git stops proposing those untracked files. The .gitignore file itself belongs in the repository because every collaborator needs the same exclusions.
What to remember
Check files before staging them. Ignore generated and machine-specific files, and never publish secrets. .gitignore prevents future tracking but does not erase existing history.