Why ignore the target/ and build/ folders?

Maven writes compiled output to target/ and Gradle writes to build/. Both are fully regenerated from your source on every build, so committing them adds noise and merge conflicts without any benefit.

Should I commit the Gradle and Maven wrapper?

Yes. The wrapper scripts and gradle-wrapper.jar / maven-wrapper pin the exact build-tool version, so they belong in the repo. The Gradle block keeps the wrapper jar with a negation pattern while still ignoring the .gradle cache.

Do I need to ignore .idea and .classpath?

These are IDE-specific settings. Many teams ignore them so each developer keeps their own setup, while some commit a shared subset. Tick the Eclipse or IntelliJ block to exclude the per-developer parts.

Why ignore *.class files?

Compiled .class files are produced by javac from your .java source and are environment-specific. They should never be tracked because they are derived artifacts that change on every compile.

Is anything uploaded to a server?

No. Every template is built into the page and the file is assembled in your browser, so nothing about your project leaves your machine.

What is the .gitignore Builder for Java / Maven / Gradle?

Build a .gitignore for Java projects. Covers target/, build/, .gradle, *.class, .classpath, .project and IDE files for Maven, Gradle, Eclipse and IntelliJ — copy or download in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

.gitignore Builder for Java / Maven / Gradle

Name: .gitignore Builder for Java / Maven / Gradle
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

A .gitignore builder tuned for Java projects built with Maven or Gradle. Pick your build tool and IDE, and the tool assembles the right ignore patterns for compiled output, dependency caches and editor settings into one labelled file.

What makes Java .gitignore different from other languages

Java projects have two distinct categories of generated files to ignore: compiled bytecode (.class files and packaged .jar/.war/.ear artifacts) and build tool caches and state (Maven’s target/ directory, Gradle’s build/ and .gradle/ directories). The added complication is that you generally want to commit the build tool wrappers (gradlew, mvnw, gradle-wrapper.jar) even though they live alongside generated artifacts.

Getting this wrong in either direction causes problems: committing compiled output bloats the repository and causes merge conflicts across Java versions; missing a pattern leaves caches polluting git status.

How the patterns work

Each toggle adds a curated block of patterns under a # Header comment.

Maven block: Ignores target/ — the entire Maven build output directory — plus pom.xml.tag, pom.xml.releaseBackup, and other files created by the Maven Release Plugin during a release cycle. Keeping these out of the repo prevents accidental commits mid-release.

Gradle block: Ignores .gradle/ (the per-user Gradle cache and daemon files) and build/ (the compiled output). Crucially, it uses a negation pattern to keep the wrapper jar:

.gradle/
build/

# Keep the Gradle wrapper
!gradle/wrapper/gradle-wrapper.jar

The wrapper jar (gradle-wrapper.jar) and scripts (gradlew, gradlew.bat) pin the Gradle version for every developer and CI runner. They should be committed.

Compiled output: *.class files are the bytecode output of javac — machine-specific, reproducible from source, and pointless to commit. The same applies to *.jar, *.war, and *.ear when generated as build artifacts (as opposed to third-party libraries, which live in the Maven/Gradle dependency cache and are not stored in the repo at all in modern projects).

Log and crash files: hs_err_pid*.log files are generated by the JVM during crashes. They can be large and are specific to the crash instance, so they should never be committed.

IDE-specific patterns

Eclipse: The .classpath, .project, and .settings/ files are Eclipse’s project metadata. These differ between workspace paths and machine-specific Java installations. While some teams commit a shared subset, the per-developer parts cause conflicts and should stay local.

IntelliJ IDEA: The .idea/ directory contains project-level settings including run configurations, code style, and inspections. Some teams commit a subset of .idea/ (for example, runConfigurations/ to share launch configs), but the default is to ignore the whole directory. *.iml files are module-level IntelliJ metadata and are always machine-specific.

Tips for multi-module projects

For a Maven multi-module project (a parent POM with multiple submodule directories), place the .gitignore at the repository root. The target/ pattern applies recursively, so every submodule’s build output is ignored automatically — you do not need to add .gitignore files inside each submodule.

For Gradle multi-project builds, the same applies: build/ at the root covers subproject build directories.

Always commit your build tool wrapper so all contributors and CI pipelines use the exact same build-tool version, eliminating “works on my machine” build failures. If a derived file is already tracked, run git rm --cached <file> before the .gitignore entry takes effect.