76

I have now switched to Android Studio and saving my projects in Git with Source Tree. Whenever I add or remove any library from my module, its .iml file also changes. It really doesn't matter if I commit the *.iml because they get auto-generated in others Android Studio. However, here it says you should store *.iml . My question is, do we really need to share our *.iml with others? If yes, why?

Improve this question
8
  • Yes!!! when you develope gradle base project then .iml file store your project info so i think it good store on version control. Commented Aug 26, 2014 at 11:42
  • 2
    IMHO, only pay attention to the answers from 2014 from Haresh's link. Commented Aug 26, 2014 at 11:55
  • 8
    I disagree that .iml files should be submitted to source control. They're entirely generated, and the IDE has freedom to rewrite them at will based on changes to the Gradle files. That makes them redundant with the Gradle files, and it will just be one more thing you need to check out, maintain, and check back in when the Gradle files change. Commented Aug 26, 2014 at 21:25
  • 12
    In latest Android Studio (1.5.1) when you create a new Android project from scratch, the Android Studio creates .gitignore file automatically and adds *.iml in .gitignore. So now in 2016 the the answer would be "No, its not mandatory to save .iml files in Version Control System." Commented Feb 26, 2016 at 10:43
  • 3
    Personally, I've found that Android Studio is constantly making minor rearrangements and alterations to the .iml files, so maintaining them in version control is a hassle. Commented Jun 14, 2016 at 10:21

5 Answers 5

Reset to default
70

General best practice is to:

  • make projects as IDE-agnostic as possible,
  • do not commit generated files.

So the answer is: it's better to make such files ignored for VCS.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

I always get dual answers! The above comment from Haresh says yes, and you say 'no'. Where am I to go? I think it is doesn't matter because *.iml do not share any user's project path. So it seems fine to share. Can you share a link where all this is otherwise explained.
I'm not sure if in the thread you invoke maven is taken into consideration - it is perfectly possible to have Idea project without maven, in which case it should be indeed commited (as it's the only place where project conf is stored). If you use maven however, and iml are only generated, I don't see the point.
18

Yes, .iml Files are suitable for version control (see this comment)

It is also true to make projects as IDE-agnostic as possible, however, sharing .iml files does not break anything for people developing with another IDE. For them, they are just a bunch of relatively small files that don't concern them.

A good practice for teams using different IDEs simultaneously is to store each IDE's project files in the VCS, only excluding those which contain paths, environment variables etc. specific to a single developers environment. This way, anyone using one of the supported IDEs can enjoy the benefits of a proper, shared setup, like for example:

  • sharing build configurations
  • sharing dependencies
  • configurations for automatic code quality checks

There are more use cases, depending on the specific IDEs in play. Edit: For IntelliJ, also see this FAQ

Improve this answer

Comments

2

I agree that they are IDE-dependant files irrelevant to code and they should not be shared. But, then you should know how to regenerate them.

You may encounter with situations while your remote repo does not contain these files and when you clone the code and open in IDEA, it just shows a bunch of errors. Why? *.iml files are not regenerated.

You must import from IDEA with "File" - "New" - "Project from Version control". Only this can generated the files for you.

Improve this answer

1 Comment

There's another way to generate the files. stackoverflow.com/a/36542677/463304
0

Rule of thumb - "Anything thats can be generated from source code should not be checked in" .

Improve this answer

Comments

0

The current top answer - July 2025 is great for beginners, but most rules have exceptions, here's my 2 cents:

Rule of thumb:

"Don't commit generated files"

However...

  1. Is regeneration of the files straight forward?
  2. Can it be automated as part of on-boarding to your project (e.g. with package manager installation or init scripts)?
  3. Do the files change often enough to make 1 and 2 a headache?
  4. Do the files contain hardcoded local environment settings?
  5. (Specific to this Stack Overflow Question) Do most of your developers use the same IDE anyway?

Sometimes even though a file is generated, the benefits of source-controlling those files outweigh the best-practice benefits. In the case of IDE files, it enables sharing of common things like run configurations and module setup that could be tedious to import and maintain manually for medium to highly complex projects and does not have an easy means of automation integrated with the standard IDE-agnostic build/setup process of a project.

Intellij .idea folders contain some hard-coded environment variables, however there is a default .idea/.gitignore file generated when first importing a project that contains recommended ignore settings.

If you have the patience to monitor any changes in .idea folders that cause future conflicts, it could potentially speed up on-boarding when others use the same IDE.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.