我想提供一个中间路线的选择。

不要在git中添加node_modules。 使用包锁。Json文件来确定你的依赖版本。 在CI或发布过程中，当你发布一个版本时，复制node_modules文件夹并备份它(例如在云存储中)。

在极少数情况下，你不能访问NPM(或你使用的其他注册表)或NPM中的特定包，你有一个node_modules的副本，可以继续工作，直到恢复访问。

不使用源代码控制跟踪node_modules是正确的选择，因为一些NodeJS模块，如MongoDB NodeJS驱动程序，使用NodeJS c++附加组件。这些附加组件是在运行npm install命令时编译的。所以当你跟踪node_modules目录时，你可能会不小心提交一个OS特定的二进制文件。

我想提供一个中间路线的选择。

不要在git中添加node_modules。 使用包锁。Json文件来确定你的依赖版本。 在CI或发布过程中，当你发布一个版本时，复制node_modules文件夹并备份它(例如在云存储中)。

在极少数情况下，你不能访问NPM(或你使用的其他注册表)或NPM中的特定包，你有一个node_modules的副本，可以继续工作，直到恢复访问。

答案并不像阿尔贝托·扎卡尼所说的那么简单。如果您开发应用程序(特别是企业应用程序)，在git repo中包含node_modules是一个可行的选择，选择哪种替代方案取决于您的项目。

因为他很好地反对node_modules，所以我将集中讨论支持它们的论点。

想象一下，你刚刚完成了一个企业应用程序，你必须支持它3-5年。你肯定不想依赖别人的npm模块，它明天就会消失，你就不能再更新你的应用了。

或者你有你的私有模块，不能从互联网上访问，你不能在互联网上创建你的应用。或者，出于某些原因，你可能不想依赖于npm服务的最终构建。

你可以在Addy Osmani的这篇文章中找到优缺点(尽管它是关于Bower的，但情况几乎相同)。我将引用Bower主页和Addy文章中的一段话作为结束:

“如果你正在创作的包不是要被其他人使用(例如，你正在构建一个web应用程序)，你应该始终将已安装的包检查到源代码控制中。”

如果package.json中提到了依赖关系，则Node_modules不需要检入。任何其他程序员都可以通过npm install来简单地获得它，npm足够聪明，可以让node_modules在你的项目工作目录中。

还有一件事需要考虑:签入node_modules会使使用dependencies和devDependencies之间的差异变得更加困难/不可能。

另一方面，有人可能会说，将经过测试的完全相同的代码推向生产是令人放心的——因此包括devDependencies。