Git for Windows: Create .gitignore in Notepad Without .txt

The file itself is simple; the Windows-specific trap is its name. Notepad and File Explorer can make it easy to save a file that looks like .gitignore but is actually .gitignore.txt, which Git will not treat as an ignore-rules file. A few carefully chosen patterns can keep build output, local configuration, logs, and editor debris out of commits without concealing source files the team needs.

Git’s documentation defines .gitignore as a list of patterns for intentionally untracked files. It is a shared, version-controlled policy for a repository, which makes it the right place for generated files that every contributor should exclude.

Create .gitignore with Notepad without creating .gitignore.txt​

Start in the root of the repository: the folder that contains the hidden .git directory after you run git init, or the folder created by git clone. A .gitignore stored here applies to files below it, although subfolders can also contain more specific .gitignore files.

1. Open the repository folder in File Explorer.
2. Right-click an empty area of the folder, select New, and choose Text Document. Windows will create a file with a temporary name such as New Text Document.txt.
3. Rename that file to .gitignore. If File Explorer warns that changing the extension might make the file unusable, accept the change.
4. If Windows will not let you distinguish .gitignore from .gitignore.txt, turn on filename extensions first. In Windows 11, select View > Show > File name extensions in File Explorer. In Windows 10, use the View tab and enable File name extensions.
5. Open .gitignore in Notepad and add the rules needed for the project. Save the file normally with Ctrl+S.

You can also create the file entirely from Notepad. Choose File > Save as, navigate to the repository root, enter .gitignore in the File name field, and change Save as type to All Files. That last choice prevents Notepad from appending .txt to the filename.

A correctly named ignore file often appears in File Explorer as simply .gitignore: the name begins with a period and has no ordinary extension. That is expected.

Git ignore patterns turn file names into repository policy​

Each non-empty line in .gitignore is a pattern. Lines beginning with # are comments, so use them to separate categories and explain why a rule exists. Git applies the last relevant matching rule, which makes the order of exceptions meaningful.

For a small Windows-based application or scripting project, this is a reasonable starting point:

# Build output and temporary working folders
bin/
obj/
build/
dist/
out/

# Logs and temporary files
*.log
*.tmp
*.bak

# Local environment files and secrets
.env
.env.*
!.env.example

# Visual Studio and Visual Studio Code user-specific files
.vs/
.vscode/
*.user
*.suo

# Windows Explorer metadata
Thumbs.db
Desktop.ini

The slash at the end of bin/, obj/, and similar entries means the rule targets directories. *.log matches log files anywhere below the folder containing this .gitignore. By contrast, /build/ would apply only to a build directory immediately inside the repository root.

The two .env rules show an important exception pattern. .env and files such as .env.production are ignored, while !.env.example tells Git to keep an example template visible for other developers. That template should contain placeholder values, never real passwords, API keys, connection strings, or tokens.

Be selective with editor folders. .vscode/ may contain personal editor state, but it can also hold shared project settings, debugging profiles, and recommended extensions. If the team wants to commit selected files from that directory, ignore its disposable content rather than the entire folder. A broad ignore rule is easy to write and harder to unwind when it hides useful project configuration.

.gitignore does not remove files Git already tracks​

The most common misunderstanding is treating .gitignore as a cleanup command. It is not. Git’s own documentation is explicit: ignore patterns affect intentionally untracked files. If appsettings.json, .env, or a log file was already added and committed, inserting its name into .gitignore will not remove it from the repository.

Check this first:

git status

If the file is listed under changes to be committed, or it is already part of the repository’s history, remove it from Git’s index while leaving the working copy on disk:

git rm --cached .env

Then commit both the updated .gitignore and the removal from the index. On the next status check, .env should remain on the machine but stop appearing as an untracked or staged candidate.

This distinction is especially important for secrets. Adding a leaked credential to .gitignore prevents a future accidental add, but it does not revoke a credential already pushed to a remote repository and does not erase its prior Git history. Rotate the exposed secret through the service that issued it, then follow the organization’s established process for repository cleanup if historical removal is required.

Verify .gitignore with git status and git check-ignore​

Do not assume a pattern works because it looks right. Git for Windows gives you two useful checks.

First, create or identify a file that should be ignored, then run:

git status

By default, git status lists untracked files but omits ignored ones. If build\app.exe is covered by build/, it should not appear in the untracked-files section. The .gitignore file itself should appear as untracked until you add it:

git add .gitignore
git status

A more direct diagnostic is:

git check-ignore -v build\app.exe

The -v option asks Git to show the ignore file and pattern that matched the path. This is the fastest way to find out whether a rule is being applied, and which rule won when several ignore files or exceptions overlap.

To see ignored paths in the status output, use:

git status --ignored

Git marks ignored entries with !! in short status output:

git status --short --ignored

If an expected file still appears with ??, inspect three things before adding more wildcard rules:

• Confirm that the repository root contains .gitignore, not .gitignore.txt.
• Confirm that the pattern matches the file’s actual relative path and spelling.
• Confirm that the file has not already been added to Git’s index.

The last point explains many apparent failures. A tracked file remains visible to Git by design, even if a later ignore rule matches its name.

Repository .gitignore rules should stay separate from personal clutter​

A root .gitignore belongs in the repository because it travels with the code and gives every clone the same rules. Build directories, generated binaries, shared application logs, and project-local secret files generally belong there when the entire team should avoid committing them.

Git supports two other exclusion locations for different purposes. The repository’s .git/info/exclude file applies only to that local clone and is useful for one person’s temporary files. A global excludes file, configured through Git’s core.excludesFile setting, is for files you never want to track across projects, such as operating-system metadata or backup files created by a preferred editor.

That separation keeps shared policy understandable. A developer can ignore a personal scratch folder locally without quietly altering what every teammate sees after cloning the repository.

What this means for you​

Create and commit a small root-level .gitignore before the first serious git add . command, then test its behavior with Git rather than relying on File Explorer’s filename display.

• Save the file as exactly .gitignore in the repository root, using Notepad’s All Files type when necessary to avoid the .txt suffix.
• Put project-wide generated output, known local secret files, logs, and Windows metadata in the repository’s .gitignore.
• Use comments and narrow patterns so future contributors can understand why files are excluded.
• Run git status before committing and use git check-ignore -v <path> when a file is unexpectedly visible or hidden.
• Remove previously tracked files with git rm --cached <path>; adding an ignore rule alone does not stop Git from tracking them.
• Treat .gitignore as preventive hygiene for secrets, not a remediation tool for credentials that have already been committed.

A well-made .gitignore is modest infrastructure: one text file that prevents noisy commits, reduces accidental disclosure, and makes git status show the files a developer can actually act on. On Windows, getting the filename exactly right is the first and most important rule.