A Java project’s .gitignore is dominated by build outputs (Maven and Gradle each generate substantial directories), compiled bytecode, and IDE files. The list above is a known-good set; this page explains each entry.

Compiled bytecode

*.class

Java compiles each .java source file to a .class bytecode file. Regenerable by running the build; never useful to commit.

A surprising number of stale *.class files end up in repos when a developer compiled outside the build directory (e.g., into the source tree by mistake). The pattern catches them all.

Maven outputs

target/
pom.xml.versionsBackup
release.properties
.flattened-pom.xml
dependency-reduced-pom.xml
buildNumber.properties

target/ is where Maven puts everything: compiled classes, packaged JARs, generated docs, test reports. Always huge. Always regenerable.

The other entries are produced by specific Maven plugins (versioning, release, flatten-maven-plugin, shade-plugin) when they run. Add them so a single use of any of those plugins doesn’t pollute your tree.

Gradle outputs

build/
.gradle/
gradle-app.setting
!gradle-wrapper.jar
.gradletasknamecache

build/ is Gradle’s equivalent of Maven’s target/. .gradle/ holds Gradle’s own cache (configuration, dependency resolution).

!gradle-wrapper.jar is a negation: ignore JARs in the working tree (none, normally) but keep gradle/wrapper/gradle-wrapper.jar — that’s part of the Gradle Wrapper, which projects commit to lock the build tool version.

Specifically, the Gradle Wrapper files should be committed:

gradlew                    ← shell script
gradlew.bat                ← Windows version
gradle/wrapper/            ← contains gradle-wrapper.jar and properties

Without them, anyone cloning the repo has to install Gradle separately at the right version.

JAR / WAR / EAR

*.jar
*.war
*.ear
*.nar

Build outputs. Don’t commit. The exception is gradle-wrapper.jar, handled by negation.

For projects that distribute JARs as releases (committed to the repo for some reason — usually wrong but occasionally legitimate for legacy compatibility), use a more specific path-based pattern instead of the broad *.jar.

IDE files

# IntelliJ IDEA
.idea/
*.iml
*.iws
*.ipr
out/

# Eclipse
.project
.classpath
.settings/
.metadata/
bin/
tmp/
*.tmp
*.bak
*.swp
*~.nib
local.properties
.loadpath
.recommenders

# NetBeans
nbproject/private/
nbbuild/
dist/
nbdist/
.nb-gradle/

Java-IDE history runs deep — Eclipse, IntelliJ, NetBeans each generate substantial per-project metadata. Some of these files (like .classpath) can be committed for shared IDE setup, but the modern convention is to ignore them and rely on Maven/Gradle as the canonical project definition.

The IntelliJ .idea/ is the most contentious: some teams commit a sanitized subset (code style, run configurations) and ignore the rest. The default in most generators is to ignore everything.

Logs and runtime

*.log
hs_err_pid*
replay_pid*

hs_err_pid* is a JVM crash dump file. replay_pid* is a related debug-replay file. Both are generated when the JVM crashes; never useful to commit.

*.log is broad — adjust if your project has intentional logs.

Test reports

test-output/
TEST-*.xml

JUnit, TestNG, and other test frameworks emit XML reports in standard locations. Regenerable; never useful to commit.

OS files

.DS_Store
Thumbs.db

Standard.

Spring Boot

If using Spring Boot:

HELP.md
.mvn/
*.factorypath

HELP.md is generated by Spring Initializr; harmless but noise.

Common pitfalls

Committing target/. Maven’s target/ after a full build is hundreds of MB. Add to .gitignore before the first build.
Committing the IntelliJ .idea/ directory uncritically. Lots of files in there are per-developer (workspace state, recent files). Either ignore the whole thing, or carefully cherry-pick which subfiles to commit.
Ignoring gradle-wrapper.jar blindly. Without it, the Gradle Wrapper doesn’t work. Use the negation !gradle/wrapper/gradle-wrapper.jar.
Forgetting NetBeans / Eclipse files if part of the team uses them. The IDE-specific ignores are union, not exclusive.
Tracking compiled .class files in the source tree. This usually means somebody ran javac directly instead of using the build tool. The .class ignore catches them; check for and remove existing tracked ones with git rm --cached.
Treating Lombok-generated classes specially. Don’t — they’re regenerated at compile time. Just ignore target//build/ and you’re fine.

For other stacks, see Python, Node.js, Go, Rust, .NET, Ruby, or the general .gitignore generator.

Java .gitignore