Share the settings with the whole team — a year later
Earlier this year I published a post, Share the settings with the whole team, as part of a series of Android Studio tips. In that post, I advocated for keeping some of the IDE settings under version control, to make sure the team is aligned on which code style settings and other settings to use. Now, after eights months, it’s time to share my further findings on the matter.
How does that work, in practice?
As it turns out, very, very well! Even people that wasn’t initially sold on it are now very happy about it. In the project I’m working on, we’ve been having our IDE configuration in VCS for almost a year now. We’ve hit some minor issues, but we’ve overcome them all with very low effort and I still think it’s a very valuable thing to do.
What didn’t work
So far we’ve mostly have had minor issues with some files popping up in the .idea folder, that shouldn’t have been versioned but weren’t included in .gitignore and would risk getting staged/committed by mistake.
There’s two main sources for these files:
- IDE version changes, moving settings around (e.g., going from Android Studio 2.1 to 2.2, given they’re based on different versions of IDEA) — on a side note, this is the same if some people are using IntelliJ IDEA versus Android Studio; the latter is usually based on months-old IDEA codebases
- IDE plugins writing their own settings files (e.g., the Atlassian IDE plugin, or some Markdown plugins)
The latter can be solved by having people aligned on plugins by having all needed plugins and no more than that (more on that later). The former can be solved by mandating people to use the same version of the same IDE.
But it doesn’t have to be mandated.
All those issues are solved by simply switching the .gitignore from explicitly ignoring some files in .idea to ignoring the whole .idea folder by default, explicitly excluding the files we know we need:
# IDEA/Android Studio ignores
*.iml
*.ipr
*.iws
/.idea/*# IDEA/Android Studio Ignore exceptions
!/.idea/vcs.xml
!/.idea/fileTemplates/
!/.idea/inspectionProfiles/
!/.idea/scopes/
!/.idea/codeStyles/
!/.idea/encodings.xml
!/.idea/copyright/
!/.idea/compiler.xml
That makes sure the vast majorities of those changes will never be committed. Problem solved!
Note: before IDEA 2017.3 codestyles were saved in
.idea/codeStyleSettings.xmlinstead of.idea/codeStyles/— you will need to change that if you are using older versions of the IDE.
What did work
Everything else! We recently felt the need to have a shared scope to use when searching in the codebase, such that some specific folders wouldn’t be included. Easy! I created a scope, and ticked the Share scope checkbox. Now it’s on everybody’s search dialog.
You can do the same thing for anything that carries the “for current project” icon (yeah, the one that looks like the copy icon). Run configuration to launch the debug screen? Done! Enforcing an empty line at the beginning of a class? Done! Maximum line length? Done! And so on and so forth.
Bonus round: enforcing needed plugins
Does your project need some plugins to be worked on? For example, your project is written in Kotlin, or maybe you need Fabric to be installed, or any other plugin, really.
Well, there’s a setting for that! Of course enforcing plugins only really makes sense if you have your settings in version control… one more reason to do it!
Is it worth doing it?
In conclusion, after a year of sharing the project configuration, and after the iterations and refinements over time, I’d say it’s very much worth it. It takes a couple a minutes to set up, a few minutes to explain to the team, and almost zero maintenance over time. In exchange, you get the ability to transmit code style changes and new settings to the whole team very quickly.
