A File That Controls Other Files

There is a hidden file in most projects called .gitignore. It starts with a dot, which means your computer might not even show it to you unless you ask. This file has one job: it tells version control which files to pay attention to and which to pretend do not exist.

Version control is the system that tracks changes to your project and sends those changes to the server where your site lives. If a file is ignored, it stays on your computer and never goes anywhere else.

Why It Exists

Not every file in a project should be shared. Some files contain passwords or secret keys. Some are temporary files that your computer creates automatically. Some are so large that sending them would be wasteful. The .gitignore file keeps those out of the way.

Common things to ignore include environment files (which store passwords), node_modules folders (which can contain thousands of files), and build outputs that get regenerated every time you build the site.

When It Goes Wrong

The problem comes when a rule is too broad. A rule like *.png means "ignore all PNG images." That might be fine if your images live somewhere else. But if your icons are PNGs, they will be invisible to version control. They will exist on your machine and nowhere else.

I have seen this happen with entire folders. A rule like dist/ ignores the built version of the site. If your deployment depends on those built files, they will never reach the server. The site will look fine locally and broken for everyone else.

How to Check

If a file exists on your computer but is missing from the live site, open .gitignore and read through it. Look for rules that might match the missing file. Rules use patterns, so a single asterisk can match many files at once.

You can also ask your version control system to show you which files it is tracking. If your file is not on the list, something is telling the system to ignore it.

A Small File With Big Consequences

The .gitignore file is usually short. Maybe twenty or thirty lines. But each line can affect hundreds of files. One wrong rule, added quickly and without much thought, can break a deployment that otherwise looks perfect.

I have learned to treat this file with respect. When something is missing from production, it is the first place I look.