Java .gitignore Template
Java development generates a distinctive set of build artifacts, IDE project files, and dependency caches that should always be excluded from version control. The combination of multiple popular build tools (Maven, Gradle), major IDEs (IntelliJ IDEA, Eclipse, VS Code), and Java's compilation model creates more categories of excludable files than most other languages.
Build output directories are the highest priority exclusions. Maven stores all compiled output and downloaded artifacts in the target/ directory. Gradle uses both the .gradle/ directory (for its internal cache and daemon files) and the build/ directory (for compilation output, test results, and generated artifacts). Neither of these should ever be committed — they are fully regenerable and can contain hundreds of megabytes of dependencies and compiled bytecode.
Maven's local repository (.m2/repository) is where all Maven dependencies are cached locally. This is typically in your home directory (~/.m2) rather than the project directory, so it is usually not an issue for per-project .gitignore files — but for unusual project setups that configure a local Maven repository inside the project, this directory must be excluded.
IntelliJ IDEA creates .idea/ directories containing project configuration files. Some of these should be committed (compiler output settings, run configurations used by the whole team, code style settings) and some should not (workspace.xml which contains per-developer state). The recommended approach is to exclude .idea/ entirely and then use git negation to include specific shared files: !.idea/compiler.xml, !.idea/codeStyles/, !.idea/runConfigurations/. This gives fine-grained control over what IntelliJ configuration is shared.
Eclipse generates project files (.classpath, .project) and .settings/ directories. If your team uses multiple IDEs, decide whether to commit IDE-specific files at all or use a policy of excluding all IDE files and configuring them locally. Maven's IDE plugin (mvn eclipse:eclipse) or Gradle's Eclipse plugin can regenerate Eclipse project files from the build script.
Compiled class files (*.class) are the bytecode output of Java compilation. They should never be committed — they live in the build or target directory which is already excluded, but an explicit *.class exclusion prevents edge cases where compiled files end up in unexpected locations during development.
Template Preview
{"environment":"java","buildTool":"maven","includesMaven":true,"includesGradle":true,"includesIntelliJ":true,"includesEclipse":true,"includesClassFiles":true,"includesEnvFiles":true}Customize this template with your own details using the free generator:
▸Open in GeneratorFAQ
- Should I commit IntelliJ IDEA .idea/ files?
- Selectively. Exclude the .idea/ directory globally, then un-exclude specific files that benefit from being shared: .idea/codeStyles/ (code formatting settings), .idea/inspectionProfiles/ (static analysis rules), .idea/compiler.xml (output path settings), and .idea/runConfigurations/ (shared run/debug configurations for tests and local server). Never commit workspace.xml — it contains developer-specific state like open files and window positions.
- What is the difference between Maven and Gradle in terms of .gitignore?
- Maven's primary exclusion is the target/ directory where all build output goes. Gradle requires excluding both .gradle/ (daemon files, build cache) and build/ (compilation output). If your project uses the Gradle wrapper (gradlew files), those should be committed — they allow others to build without having Gradle installed globally. The gradle/wrapper/ directory containing gradle-wrapper.jar and gradle-wrapper.properties should be committed.
- Should I commit the Maven wrapper (mvnw) files?
- Yes, commit mvnw, mvnw.cmd, and .mvn/wrapper/maven-wrapper.properties. The Maven wrapper allows developers without Maven installed to build the project using the project-specified Maven version, eliminating version discrepancies. Only exclude .mvn/wrapper/maven-wrapper.jar if you want to avoid binary files in your repository — in that case, the wrapper downloads it on first use.