Flutter .gitignore template

.flutter-plugins and .flutter-plugins-dependencies are generated manifests listing which plugins the project uses and where their packages live on this machine. They contain absolute paths into the package cache in your home directory, which is exactly why they are regenerated rather than shared, and a committed copy points at a directory that does not exist for anyone else.

The Android rules cover /android/app/debug, /android/app/profile and /android/app/release. Those are the three build modes, and each produces a full set of compiled output. The framework's own scaffolding creates them lazily, so a fresh clone will not have them until the first build for that mode runs.

The iOS rules are more interesting. /ios/Pods holds the dependency manager's installed sources, restored from a manifest, and /ios/.symlinks holds generated symbolic links pointing back into the plugin packages. /ios/Flutter/Flutter.framework and Flutter.podspec are the engine binary and its specification, copied in by the tooling during a build rather than authored.

pubspec.lock is ignored, and for an application that is the wrong default. The lockfile pins every dependency to an exact version, and an app is exactly the case where you want a build in CI to resolve the same packages a developer tested against. Most teams remove that line. Only a published package has a real argument for leaving it out.

.metadata records which framework version created the project and which platform scaffolds have been migrated. It is genuinely used by the upgrade tooling, so ignoring it is another line worth reviewing rather than accepting: without it, a migration command has to guess where the project started. Between that line and the lockfile line, this is a template where two of the defaults are worth changing before the first commit rather than after.