As far as I understood, the best practice for the gradle.properties is to keep it outside of version control, because team members may use it to customize builds, and it is not desirable to have them accidentally commit changes to that file.
This is reflected here: http://chimera.labs.oreilly.com/books/1234000001741/ch04.html “Using gradle.properties is viable only if it can be kept out of source control though a mechanism like the .gitignore file or the svn:ignore property, or a similar technique appropriate for the version control system in use.”
I am aware the gradle manual suggests the opposite: http://www.gradle.org/docs/current/userguide/build_environment.html “While it’s possible to configure these in your local environment via GRADLE_OPTS or JAVA_OPTS, certain settings like JVM memory settings, Java home, daemon on/off can be more useful if they can versioned with the project in your VCS so that the entire team can work with consistent environment.”
and Peter also explicitly suggests to use gradle.properties in SCM: http://stackoverflow.com/questions/17262856/gradle-how-to-set-the-project-name-group-version-plus-source-targetcompatibi
So there seems to be two schools of thought: One school that recommends keeping the gradle.properties under version control to make sure all team members (or CI build environments) use the same defaults at the risk of one commit breaking all other builds. The other school recommends leaving gradle.properties out of version control to allow individual developers to customize the build process without impacting the other build environments, at the risk of having very different build environments and thus inconsistent build results.
While both views are viable, I think it might be nice if the gradle community found a single best practice approach that combines the best of both worlds. Meaning one file with properties to share among team members for a single given project, and one file with custom properties overriding the defaults.
This is somewhat related to the boilerplate code necessary to load settings from other property files: