Introduction

In a Maven project, the target/ directory is build output, not source code. Git should usually ignore it, otherwise the repository fills up with compiled classes, packaged archives, and generated files that change on almost every build.

Why target/ should usually be ignored

Maven writes compiled classes, test reports, generated sources, and packaged artifacts into target/. Those files are reproducible from the real project inputs: pom.xml, source code, and resources. Because of that, checking them into Git usually creates noise without adding value.

A clean .gitignore for a Maven repository often starts with this:

1# Maven output
2target/
3
4# IDE noise
5.idea/
6.classpath
7.project
8
9# OS files
10.DS_Store

If you have a multi-module build, use a recursive rule:

**/target/

That pattern catches target/ directories in submodules as well as the repository root.

Ignoring files is not enough if Git already tracks them

This is the point that trips people up most often. .gitignore only affects untracked files. If someone already committed target/app.jar or target/classes/..., adding target/ to .gitignore does not remove those files from version control.

You need to untrack them explicitly:

git rm -r --cached target
git commit -m "Stop tracking Maven build output"

For a multi-module project:

git rm -r --cached .
git add .
git commit -m "Refresh index with .gitignore rules"

The second pattern is broader, so use it carefully. It is helpful when ignore rules have drifted and you want Git to re-evaluate everything.

A practical Maven repository layout

A typical Java repository should commit these inputs:

• 'pom.xml'
• 'src/main/...'
• 'src/test/...'
• wrapper files such as mvnw and .mvn/

And it should ignore generated outputs such as:

• 'target/classes/'
• 'target/test-classes/'
• 'target/surefire-reports/'
• packaged artifacts like .jar or .war files under target/

That keeps diffs focused on real code changes instead of local build state.

Useful Git commands when ignore rules seem wrong

If Git still shows a file you expected to ignore, inspect the rule that matched it:

git check-ignore -v target/my-app.jar

To see ignored files in status output:

git status --ignored

Those two commands are much faster than guessing whether the problem is the pattern, the file location, or the fact that the file is already tracked.

When not to ignore generated output

There are exceptions. Some teams commit generated code if the generation step is expensive or requires unavailable tooling. A release repository may also intentionally publish build artifacts. If you do that, make the exception narrow and document it clearly.

For example, ignoring all of target/ is fine, but you may choose to commit a wrapper JAR under .mvn/wrapper/:

target/
!.mvn/wrapper/maven-wrapper.jar

The key is to treat committed generated output as a deliberate policy, not an accident.

Common Pitfalls

The most common mistake is expecting .gitignore to remove files that are already in the repository history. It only prevents new untracked files from being added.

Another problem is putting the ignore rule in the wrong place. A module-level .gitignore affects paths relative to that directory, while a root .gitignore can cover the whole repository.

Be careful with overly broad patterns such as *.jar. That may ignore artifacts you do want to commit outside of target/, including wrapper binaries or test fixtures.

Finally, do not try to solve sensitive-file problems with .gitignore after the file has already been committed. At that point, you need history cleanup, not just a new ignore rule.

Summary

• Maven target/ directories are build artifacts and should normally be ignored by Git.
• Use target/ or **/target/ in .gitignore depending on the project layout.
• If files are already tracked, remove them with git rm --cached before the ignore rule takes effect.
• Use git check-ignore -v and git status --ignored to debug ignore behavior.
• Commit generated output only when there is a clear, explicit reason.