.gitignore & Best Practices

Not everything in a project folder belongs in version control — build output, dependency folders, and secrets should usually stay out of Git entirely. A .gitignore file tells Git what to leave alone.

Creating a .gitignore

Create a plain text file named .gitignore in the root of your project, with one pattern per line:

node_modules/
.env
*.log
dist/
.DS_Store

Once a pattern is listed, matching files stop showing up in git status and won't get added even by git add . — Git treats them as if they don't exist.

Common patterns worth knowing

• node_modules/ — a trailing slash means "this folder and everything inside it," useful for dependency folders that can always be reinstalled from a package file.
• *.log — the * wildcard matches any filename, so this ignores every file ending in .log anywhere Git looks.
• .env — files holding API keys, passwords, or other secrets should never be committed; anyone who can read the Git history can read a secret that was ever committed, even if it's since been deleted.
• !important.log — a leading ! un-ignores a specific file that would otherwise match a broader pattern above it.

General habits worth building

• Commit often, in small pieces. A commit per logical change is far easier to review, revert, or understand later than one giant commit at the end of the day.
• Write the commit message before you second-guess it. If you can't summarize what changed in one short line, the commit is probably doing too much at once.
• Pull before you push. Staying in sync with the remote avoids most avoidable merge conflicts.
• Branch for anything non-trivial. It costs nothing and keeps main stable while you work.
• Never commit secrets. Use environment variables and a .gitignore'd config file instead — and if one ever slips through, treat the secret as compromised and rotate it, since removing it from a later commit doesn't erase it from history.