Component || Keep?
-------------------------
build.gradle || Yes
settings.gradle || Yes
gradlew || Yes
gradlew.bat || Ideally
.gradle || No
Рекомендуется регистрировать gradlew в хранилище кода.Причина: другие разработчики, инструменты тестирования, инструменты сборки получат возможность использовать ту же конфигурацию сборки, что и на локальном компьютере, что обеспечит согласованность и не вызовет неожиданных проблем, которые необходимо устранять по отдельности.
Для несколькихрепозитории кода проекта, верхний уровень имеет один settings.gradle, в то время как каждый подпроект должен иметь свой собственный build.gradle.Для многопроектных репозиториев каталог верхнего уровня также может иметь build.gradle, который предназначен для поддержки общих плагинов и зависимостей для всех подпроектов.
settings.gradle устанавливает структуру проекта, именамодули, имена корней верхнего уровня и т. д. Хотя build.gradle, как ожидается, будет содержать требования к плагинам (how should these tests run?, how to get coverage report?), а также набор зависимостей, которые необходимы проекту.
gradlew.batфайл - это оболочка Gradle для систем Windows - для полной гигиены я бы включил его в VCS, но если вас интересуют только * nix экосистемы, вы сможете удалить этот файл.
Теперь,Возвращаясь к первому пункту, который я сделал, в зависимости от системы, в которой вы работаете, gradle init может создать другую оболочку Gradle, которая может неожиданно взаимодействовать с этими файлами.Следовательно, хорошей практикой является проверка их всех в VCS.
Я бы определенно не проверял каталоги .gradle или /build - он содержит кучу кэширования и файлы для этапов временной сборки.Эти вещи должны быть в .gitignore для обеспечения оптимальной скорости локального разработчика, но нет смысла помещать эти вещи в VCS.