Contents

What not to commit

When you put Dart source code in a repository—using the pub tool, GitHub, or another source code management system—don’t include most of the files that your IDE or code editor, the pub tool, and other tools generate.

The rules

Don’t commit the following files and directories created by pub:

.dart_tool/
.packages
build/
pubspec.lock  # Except for application packages

Don’t commit the API documentation directory created by dartdoc:

doc/api/

Don’t commit files and directories created by other development environments. For example, if your development environment creates any of the following files, consider putting them in a global ignore file:

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

# Mac
.DS_Store

For more details, read on.

Details

As a rule, commit only the files that people need to use your package or source code repository. Including additional files is unnecessary, could be counterproductive, and might have security implications if you expose details about your machine’s setup. In many source code repositories, the common practice is not to commit generated files, at all.

To avoid committing files that are specific to your personal workflow or setup, consider using a global ignore file (for example, .gitignore_global).

When you use pub from within a Git repo, pub ignores the same files that Git does. For example, if you run pub publish from a Git repo that has a .gitignore file containing keys.txt, then your published package won’t contain the keys.txt file.

For more information on .gitignore files, see the GitHub help page Ignoring files.

.packages

The .packages file contains a list of dependencies used by your application. Users of your code should generate their own packages information using pub get.

pubspec.lock

The pubspec.lock file is a special case, similar to Ruby’s Gemfile.lock.

For library packages, do not commit the pubspec.lock file.

For application packages, it’s up to you whether you commit the pubspec.lock file. Consider checking it in if you want to track the dependencies that are used for production or across a team.