What files in a Cargo project should be in my .gitignore?

Question

I created a "hello world" Rust app using cargo new. When I executed git status it showed a bunch of files:

A  rust/welcomec/Cargo.lock
A  rust/welcomec/Cargo.toml
A  rust/welcomec/src/main.rs
A  rust/welcomec/target/debug/.cargo-lock
A  rust/welcomec/target/debug/.fingerprint/welcomec-2d68725c8fae6fd1/bin-welcome-2d68725c8fae6fd1
A  rust/welcomec/target/debug/.fingerprint/welcomec-2d68725c8fae6fd1/bin-welcome-2d68725c8fae6fd1.json
A  rust/welcomec/target/debug/.fingerprint/welcomec-2d68725c8fae6fd1/dep-bin-welcome-2d68725c8fae6fd1
A  rust/welcomec/target/debug/deps/welcome-2d68725c8fae6fd1
A  rust/welcomec/target/debug/welcome
A  rust/welcomec/target/debug/welcome.d

Can I safely ignore any of these files and/or directories?

Answer 1

Summary

.gitignore for library crates

# Generated files
/target/

# The library shouldn't decide about the exact versions of 
# its dependencies, but let the downstream crate decide.
Cargo.lock

.gitignore for executable crates

# Generated files
/target/

---

Details

You need one or two entries in your .gitignore, depending on what kind of crate you're building. The target/ folder can be ignore completely regardless of crate type; it only contains generated files (e.g. compile artifacts).

The Cargo.lock file should be included in the repository if you're writing an executable, and should be ignored if you're writing a library. You can read more about this in the FAQ. To quote the most important part:

The purpose of a Cargo.lock is to describe the state of the world at the time of a successful build. [...]

This property is most desirable from applications and projects which are at the very end of the dependency chain (binaries). As a result, it is recommended that all binaries check in their Cargo.lock.

For libraries the situation is somewhat different. [...] If a library ends up being used transitively by several dependencies, it’s likely that just a single copy of the library is desired (based on semver compatibility). If all libraries were to check in their Cargo.lock, then multiple copies of the library would be used, and perhaps even a version conflict.

---

Also, please note that cargo new and cargo init automatically generates a .gitignore file in the project, unless the parameter --vcs none is passed.

Answer 2

You can take some inspiration from GitHub's gitignore for Rust. At the time of writing, the file goes as follows:

# Generated by Cargo
# will have compiled files and executables
debug/
target/

# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
Cargo.lock

# These are backup files generated by rustfmt
**/*.rs.bk

# MSVC Windows builds of rustc generate these, which store debugging information
*.pdb