.gitignore

Written Explanation

What goes in the file

Create a text file named exactly .gitignore (with the leading dot, no extension) in the top folder of the repository. Each line is a pattern for files Git should not track. Here is a typical start for a Java project:

# build output
target/
out/
*.class

# IDE
.idea/
*.iml

# secrets
.env

What each group is for:

You do not have to use Maven or IntelliJ yet. The list is safe to start with, and you add lines as the project grows. Other IDEs use other folder names, such as .vscode/ or bin/; look at what git status shows as untracked and decide.

Pattern rules you need

• A line starting with # is a comment; blank lines are ignored.
• * matches any text in a name: *.class matches every file ending in .class, in any folder.
• A trailing / means "directories only": target/ matches a folder named target and everything under it, but not a plain file with that name.
• A leading ! negates a pattern and re-includes a file that an earlier line excluded. (If a parent folder is ignored, you cannot re-include a file inside it.)
• A leading / anchors a pattern to the folder that contains the .gitignore: /notes.txt matches only the top-level one.
• ** matches nested folders, for example **/logs matches a logs folder at any depth.
• The last matching pattern wins, so put an ! exception after the broader pattern it relaxes. For instance, *.class followed by !Keep.class ignores all compiled files except Keep.class.

Commit the .gitignore itself. It belongs to the project, and teammates then get the same rules.

Proving it works

Before the file exists, git status -s lists everything:

?? .env
?? .idea/
?? A.class
?? A.java
?? target/

After creating .gitignore with the lines above:

?? .gitignore
?? A.java

Ignored files disappear from the list. To ask why a specific file is ignored, use:

git check-ignore -v .env target/app.jar A.class

.gitignore:11:.env	.env
.gitignore:2:target/	target/app.jar
.gitignore:4:*.class	A.class

Each line says which file, which line number, and which pattern matched. If a file you expect to be ignored is not listed, no pattern matches it. After git add . and a commit, git ls-files lists the tracked files: only .gitignore and A.java. That is the "proof" that target/ stays untracked.

The trap: ignoring does not untrack

.gitignore only affects files Git is not already tracking. If a file was committed earlier, Git keeps tracking it and keeps showing its modifications, even if a pattern now matches. This is the most common .gitignore problem. The fix is to remove the file from Git's tracking while keeping it on disk:

git rm -r --cached Account.class Main.class
git status -s

D  Account.class
D  Main.class

--cached removes the file only from the staging area and the next commit, not from your folder. Then commit:

git commit -m "Stop tracking compiled class files"

From now on the .gitignore pattern takes over. Note that the old commits still contain the files; only future commits stop tracking them.

Secrets: ignoring is not a cure

Putting .env in .gitignore before the first commit keeps it out of history. But if a password was already committed, ignoring it later does not remove it: it is still in the old commits, and anyone with a copy of the repository can read it. Rewriting history can hide it from new clones, but it does not reach copies others already made.

The safe rule is:

A secret that has been committed once must be treated as leaked: change the password or revoke the key first.

GitHub's guidance on removing sensitive data says the same: rotate the credential first, because rewriting history alone does not erase copies in other clones and forks. In practice, keep real secrets out of your project folder (or in an ignored file) and commit only a template such as .env.example containing fake values, so teammates know which settings are needed.