Buenas prácticas de Git en Flutter: ¿Es necesario hacer flutter clean antes de cada commit o basta con .gitignore?

Existe una creencia muy extendida entre desarrolladores noveles en Flutter de que es necesario ejecutar flutter clean antes de cada commit en Git para evitar subir archivos pesados o residuales al repositorio. Sin embargo, esta práctica no solo es innecesaria, sino contraproducente. Un archivo .gitignore bien configurado es más que suficiente.

¿Por qué no hace falta hacer flutter clean antes de un commit?

Para eso existe precisamente el archivo .gitignore. Cuando Flutter crea un proyecto, genera automáticamente un .gitignore oficial exhaustivo que ya excluye:

• La carpeta build/ (donde se generan todos los binarios, APKs, JS compilado y archivos temporales).
• La carpeta .dart_tool/ (metadatos del analizador de Dart y de los paquetes descargados).
• Archivos de configuración local de cada máquina: .flutter-plugins, local.properties de Android, etc.
• Caches de IDEs como .vscode/ o .idea/.

Si ejecutas git status, verás que Git ni siquiera detecta esos miles de archivos generados. Tu repositorio solo subirá tu código fuente en lib/, el pubspec.yaml y los recursos que tú decidas versionar. El repositorio queda 100% limpio sin necesidad de limpiar nada a mano.

¿Por qué hacer flutter clean antes de cada commit es contraproducente?

flutter clean borra de un plumazo todas las carpetas de caché de compilación incremental. Esto significa que:

• La siguiente vez que pulses F5 o quieras probar la app, el ordenador tendrá que reconstruir todo el árbol de Gradle en Android o compilar de nuevo todo el motor web desde cero.
• Pierdes entre 2 y 5 minutos en cada compilación posterior esperando que se descarguen y reensamblen cosas que ya estaban listas.

¿Cuándo conviene realmente hacer flutter clean?

Solo se debe ejecutar flutter clean cuando existe un problema real de caché corrupta:

1. Tras actualizar la versión mayor del SDK de Flutter (por ejemplo, saltar de Flutter 3.19 a 3.24).
2. Tras cambiar de rama de Git (branch) donde se hayan modificado versiones de librerías nativas o paquetes de Gradle.
3. Cuando el compilador arroja un error inexplicable de vinculación de paquetes nativos que no desaparece reiniciando el editor.

Para el flujo de trabajo diario y para el control de versiones con Git: basta con el .gitignore.