来自Gradle的文档： https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html
此任务生成的脚本旨在提交 你的版本控制系统。此任务也会生成一个小的 gradle-wrapper.jar引导JAR文件和属性文件应该 也致力于您的VCS。脚本委托给这个JAR。
来自： What should NOT be under source control?
我认为Generated files不应该在VCS中。
何时需要gradlew和gradle/gradle-wrapper.jar？
为什么不在gradle version文件中存储build.gradle？
答案 0 :(得分：91)
因为gradle包装器的全部要点是能够的，没有安装gradle，甚至不知道它是如何工作的，从哪个版本下载它，从VCS克隆项目，执行它包含的gradlew脚本，并且无需任何额外步骤即可构建项目。
如果您拥有的只是build.gradle文件中的gradle版本号，那么您需要一个README来解释每个人必须从URL Y下载gradle版本X并安装，并且每次版本都必须这样做增加。
答案 1 :(得分：67)
因为gradle包装器的整个要点是能够的，所以没有安装过gradle
同样的论点适用于JDK，你也想提交它吗？您是否也提交了所有的依赖库？
在发布新版本时，应继续升级依赖项。获取安全性和其他错误修复。而且，如果你远远落后于它，那么再次更新可能是一项非常耗时的任务。
如果每个新版本的gradle包装器递增，并且它已提交，则repo将变得非常大。使用分布式VCS时，问题很明显，克隆将下载所有版本的所有版本。
，甚至不知道它是如何工作的
创建一个构建脚本，下载包装器并使用它来构建。每个人都不需要知道脚本是如何工作的，他们需要同意通过执行它来构建项目。
，从哪里下载，哪个版本
task wrapper(type: Wrapper) {
gradleVersion = 'X.X'
}
然后
gradle wrapper
下载正确的版本。
，从VCS克隆项目，执行它包含的gradlew脚本，并构建项目而无需任何额外步骤。
通过上述步骤解决。下载gradle包装器与下载任何其他依赖项没有什么不同。该脚本可以智能检查当前的gradle包装器，只有在有新版本时才下载它。
如果开发人员以前从未使用过Gradle，可能不知道该项目是使用Gradle构建的。然后更明显地运行＆＃34; build.sh＆＃34;与跑步＆＃34; gradlew build＆＃34;相比。
如果你所拥有的只是build.gradle文件中的gradle版本号，那么你需要一个README来解释每个人必须从安装的URL Y下载gradle版本X，
不，你不需要自述文件。你可以有一个，但我们是开发人员，我们应该尽可能自动化。创建脚本更好。
并且每次增加版本时都必须这样做。
如果开发人员同意正确的流程是：
然后升级到最新的gradle包装器没问题。如果自上次运行后版本增加，则脚本可以下载新版本。
答案 2 :(得分：28)
我想推荐一种简单的方法。
在项目的自述文件中，记录需要安装步骤，即：
gradle wrapper --gradle-version 3.3
这适用于Gradle 2.4或更高版本。这将创建一个包装器，而无需将专用任务添加到＆＃34; build.gradle＆＃34;。
使用此选项，忽略（不要签入）这些文件/文件夹以进行版本控制：
主要好处是您不必将下载的文件签入源代码控制。安装需要额外一步。我认为这是值得的。
答案 3 :(得分：3)
根据Gradle docs，预期会在VCS中添加gradle-wrapper.jar，因为使Gradle Wrapper可供开发人员使用是Gradle方法的一部分：
要将包装器文件提供给其他开发人员和执行环境，您需要将其检入版本控制。包括JAR文件在内的所有包装程序文件都非常小。期望将JAR文件添加到版本控制中。一些组织不允许项目将二进制文件提交给版本控制。目前，该方法没有其他选择。
答案 4 :(得分：1)
什么是“项目”？
也许存在此成语的技术定义，但不包括构建脚本。但是，如果我们接受这个定义，那么我们必须说您的“项目”不是您需要版本控制的所有内容！
但是，如果我们说“您的项目”是 您所做的一切。然后我们可以说您必须将并且只有它包括在VCS中。
这是非常理论性的，对于我们的开发工作可能不切实际。因此，我们将其更改为“ 您的项目是您需要直接编辑它们的每个文件（或文件夹） ”。
“直接”是指“不是间接地”，“间接”是指通过编辑另一个文件，然后效果会反映到该文件中。。
因此，我们达到了OP所说的（并称为here）：
我认为生成的文件不应位于VCS中。
是的。因为您尚未创建它们。因此，根据第二个定义，它们不属于“您的项目”。
这些文件的结果是什么？
build.gradle ：是。我们需要对其进行编辑。我们的作品应进行版本控制。
注意：编辑位置没有任何区别。无论是在您的文本编辑器环境中，还是在项目结构 GUI环境中。无论如何您直接 ！
gradle-wrapper.properties ：是。我们至少需要确定此文件中的Gradle版本。
gradle-wrapper.jar 和 gradlew [.bat] ：到目前为止，我还没有创建或编辑它们！因此答案是“否”。如果您这样做了，那么答案是对您的工作（是关于您编辑的同一文件）的肯定。
有关最新情况的重要说明是克隆您的存储库的用户，需要在存储库的<root-directory> 上执行此命令以自动生成包装文件：
> gradle wrapper --gradle-version=$v --distribution-type=$distType
$v和$distType由 gradle-wrapper.properties 确定：
distributionUrl=https\://services.gradle.org/distributions/gradle-{$v}-{$distType}.zip
有关更多信息，请参见https://gradle.org/install/。
gradle可执行文件在本地分发中为bin/gradle[.bat]。不需要本地分布与回购中确定的相同。创建包装器文件之后，gradlew[.bat]可以自动下载确定的Gradle发行版（如果本地不存在）。然后，他/她可能必须按照上述说明使用新的gradle可执行文件（在下载的发行版中）重新生成包装文件。
注意：在上述说明中，假设用户至少本地个一个 Gradle分发（例如~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10）。它涵盖了几乎所有实际案例。但是如果用户还没有任何分发，会发生什么？
他/她可以使用.properties文件中的URL手动下载它。但是，如果他/她没有将其放置在包装器预期的路径中，则包装器将再次下载它！预期的路径是完全可以预测的，但是超出主题范围（最复杂的部分请参见here）。
还有一些更简单（但肮脏）的方法。例如，他/她可以将包装文件（.properties文件除外）从任何其他本地/远程存储库复制到他/她的存储库，然后在他/她上运行gradlew资料库。它将自动下载合适的发行版。
答案 5 :(得分：1)
旧问题，新答案。如果您不经常升级gradle（我们大多数人不升级），最好将其提交到VCS。我的主要原因是提高CI服务器上的构建速度。如今，大多数项目都是由CI服务器来构建和安装的，每次都使用不同的服务器实例。
如果不提交，CI服务器将为每个构建下载一个jar，这会大大增加构建时间。还有其他方法可以解决此问题，但是我发现这种方法最容易维护。