因为gradle包装器的全部意义在于，不需要安装gradle，甚至不知道它是如何工作的，从哪里下载，哪个版本，就可以从VCS中克隆项目，执行它包含的gradlew脚本，无需任何额外步骤就可以构建项目。

如果你所拥有的只是一个gradle版本号。gradle文件，你将需要一个README解释每个人，gradle版本X必须从URL Y下载和安装，你将不得不这样做，每次版本是增量。

因为Gradle包装器的全部意义在于，在没有安装过Gradle的情况下

JDK也是一样，你也想提交吗?你是否也提交了所有的依赖库?

随着新版本的发布，依赖关系应该不断升级，以获得安全性和其他错误修复，因为如果您远远落后于更新，那么再次更新将是一项非常耗时的任务。

如果Gradle包装器为每个新版本都增加，并且被提交，那么回购将变得非常大。在使用分布式VCS时，这个问题很明显，因为克隆会下载所有版本的所有内容。

甚至不知道它是如何运作的

创建一个构建脚本，下载包装器并使用它进行构建。每个人都不需要知道脚本是如何工作的，他们需要同意通过执行脚本来构建项目。

从哪里下载，哪个版本

task wrapper(type: Wrapper) {
  gradleVersion = 'X.X' 
}

对于Gradle版本>= 5:

wrapper {
  gradleVersion = 'X.X' 
}

然后

gradle wrapper

下载正确的版本。

从VCS中克隆项目，执行其中包含的gradlew脚本，无需任何额外步骤即可构建项目。

通过上述步骤解决。下载Gradle包装器与下载其他依赖没有什么不同。脚本可以非常智能地检查当前的Gradle包装器，只有在有新版本时才下载它。

如果开发人员以前从未使用过Gradle，可能不知道项目是用Gradle构建的，那么运行build.sh比运行gradlew构建更明显。

如果你所拥有的只是一个gradle版本号。你需要一个README解释每个人gradle版本X必须从URL Y下载并安装，

不，您不需要README。你可以有一个，但我们是开发人员，我们应该尽可能地自动化。创建脚本更好。

每次版本增加的时候都要这样做。

如果开发人员同意正确的流程是:

克隆回购 运行构建脚本

然后升级到最新的Gradle包装是没有问题的。如果自上次运行以来版本增加了，脚本可以下载新版本。

我想推荐一个简单的方法。

在项目的README中，说明安装步骤是必需的，即:

gradle wrapper --gradle-version 3.3

这适用于Gradle 2.4或更高版本。这将创建一个包装器，而不需要将专用任务添加到“build.gradle”中。

使用此选项，忽略(不签入)这些文件/文件夹进行版本控制:

./gradle 格拉德卢 格拉德卢.bat

关键的好处是您不必将下载的文件签入源代码控制。它的安装需要额外的一步。我认为这是值得的。

什么是“项目”?

也许这个习惯用法的技术定义不包括构建脚本。但是如果我们接受这个定义，那么我们必须说你的“项目”并不是你需要版本化的所有东西!

但如果我们说“你的项目”是你所做的一切。然后我们可以说，你必须把它包括进去，而且只包括它。

这是非常理论性的，在我们的开发工作中可能并不实际。所以我们将其改为“您的项目是您需要直接编辑的每个文件(或文件夹)”。

“直接”是指“不间接”，“间接”是指通过编辑另一个文件，然后一个效果将反映到这个文件中。

所以我们得到了OP所说的(这里也说了):

我认为生成的文件不应该在VCS中。

是的。因为你没有创造它们。所以根据第二种定义，他们不是“你的项目”的一部分。

这些文件的结果是什么:

build.gradle: Yes. We need to edit it. Our works should be versioned. Note: There is no difference where you edit it. Whether in your text editor environment or in Project Structure GUI environment. Anyway you doing it directly! gradle-wrapper.properties: Yes. We need to at least determine Gradle version in this file. gradle-wrapper.jar and gradlew[.bat]: I haven't created or edited them in any of my development works, till this moment! So the answer is "No". If you have done so, the answer is "Yes" about you at that work (and about the same file you edited).

关于最新案例的重要注意是，克隆你的repo的用户需要在repo的<根目录>上执行这个命令来自动生成包装器文件:

> 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手动下载。但是如果他/她没有在包装器期望的路径中定位它，包装器将再次下载它!预期的路径是完全可预测的，但超出了主题(请参阅这里的最复杂部分)。

也有一些更简单(但肮脏)的方法。例如，他/她可以将包装器文件(.properties文件除外)从任何其他本地/远程存储库复制到他/她的存储库，然后在他/她的存储库上运行gradlew。它会自动下载合适的发行版。

根据Gradle文档，将Gradle - Wrapper .jar添加到VCS是预期的，因为让开发者可以使用Gradle Wrapper是Gradle方法的一部分:

要使Wrapper文件对其他开发人员和执行环境可用，您需要将它们检入版本控制。包括JAR文件在内的所有包装器文件都非常小。需要将JAR文件添加到版本控制中。有些组织不允许项目向版本控制提交二进制文件。目前，这种方法没有其他选择。

老问题，新答案。如果你不经常升级gradle(我们大多数人都不)，最好把它提交给vc。对我来说，主要原因是为了提高CI服务器上的构建速度。现在，大多数项目都是由CI服务器构建和安装的，每次都是不同的服务器实例。

如果您不提交它，CI服务器将为每次构建下载一个jar，这将显著增加构建时间。还有其他方法可以处理这个问题，但我发现这种方法最容易维护。