模块详细信息存储在packages.json中，这就足够了。不需要签入node_modules。
人们过去常常在版本控制中存储node_modules来锁定模块的依赖关系，但对于npm shrinkwrap，这不再需要了。
这一点的另一个理由，正如@ChrisCM在评论中写道：
同样值得注意的是，任何涉及原生扩展的模块都不能在架构间工作，需要重新构建。为不将它们包含在repo中提供具体的理由。

我建议不要检入node_modules，因为例如，像node-sass和nectomJS这样的包，它们会为当前系统安装适当的二进制文件。
这意味着如果一个Dev在Linux上运行npm install并检入node_modules -它将不适用于另一个在Windows上克隆存储库的Dev。

最好检查npm install下载的tarball并指向npm-shrinkwrap.json。您可以使用shrinkpack自动执行此过程。

这个主题很老了，我明白。但是由于npm生态系统的变化，我错过了这里提供的参数的一些更新。
我总是建议不要将node_modules置于版本控制之下。几乎所有这样做的好处都在接受答案的上下文中列出，到目前为止都已经过时了。
1.已经发布的包不能再轻易从npm registry中撤销了。所以你不必担心失去你的项目之前依赖的依赖。
1.将package-json.lock文件放在MySQL中有助于频繁更新依赖项，可能会导致不同的设置，尽管依赖于相同的package.json文件。
因此，在使用离线构建工具的情况下，将node_modules放入MySQL可能被认为是唯一符合条件的用例。然而，node_modules通常增长得非常快。任何更新都会更改很多文件。这会以不同的方式影响存储库。如果你真的考虑长期影响，这可能也是一个障碍。
像svn这样的集中式目录需要在网络上传输提交和 checkout 的文件，这在 checkout 或更新node_modules文件夹时会非常慢.
当使用git时，大量的额外文件会立即污染存储库。请记住，git不会跟踪任何文件版本之间的差异，但是只要有一个字符发生变化，就会存储文件的任何版本的副本。对任何依赖项的每次更新都会导致另一个大的更改。由于这会影响备份和远程备份，因此您的git存储库将迅速变得巨大。同步。如果你决定稍后从git仓库中删除node_modules，由于历史原因，它仍然是它的一部分。如果你已经将git仓库分发到某个远程服务器（例如用于备份），清理它是另一个痛苦且容易出错的任务。
因此，如果您关心高效的流程并喜欢保持“小”，我宁愿使用单独的工件存储库，如Nexus/Artifactory（或只是一些带有ZIP存档的HTTP服务器），提供一些先前获取的依赖项集供下载。

不使用源代码控制跟踪node_modules是正确的选择，因为一些NodeJS模块，如MongoDB NodeJS驱动程序，使用NodeJS C++加载项。这些加载项在运行npm install命令时编译。因此，当您跟踪node_modules目录时，您可能会意外提交操作系统特定的二进制文件。

我同意ivoszz的观点，即检查node_modules文件夹有时是有用的，但是...

情景1：

一种情况是：您使用的是从npm中删除的包。如果您的node_modules文件夹中有所有的模块，那么您就不会有问题。如果您的package.json文件夹中只有包名，那么您就无法再获取它。如果一个包的发布时间不到24小时，那么您可以轻松地将其从npm中删除。如果它的发布时间超过24小时，那么您需要与他们联系。但是：
如果您连络支援人员，他们会检查移除该版本的套件是否会中断任何其他安装。如果是，我们将不会移除。
阅读更多
所以这种可能性很低，但有第二种情况...

情景2：

另一种情况是：您开发了一个企业版软件或一个非常重要的软件，并在包中编写了.json：

"dependencies": {
    "studpid-package": "~1.0.1"
}

字符串
您可以使用该封装的方法function1(x)。
现在，studpid-package的开发人员将方法function1(x)重命名为function2(x)，他们犯了一个错误......他们将包的版本从1.0.1更改为1.1.0。这是一个问题，因为当您下次调用npm install时，您将接受版本1.1.0，因为您使用了波浪号（"studpid-package": "~1.0.1"）。
现在调用function1(x)可能会导致错误和问题。
"但是"
将整个node_modules文件夹（通常超过100 MB）推送到仓库中会占用您的内存空间。与数百MB（package.json & node_modules）相比，只有几KB（仅package.json）......请考虑一下。
如果出现以下情况，您可以/应该考虑一下：

• 软件是非常重要。
• 当某件事失败的时候，你要花钱。
• 你不信任npm注册表。npm是集中式的，理论上可以关闭。

在以下情况下，在99.9%的情况下，您不需要**发布node_modules文件夹：

• 你只为自己开发了一个软件。
• 你已经编写了一些东西，只是想在GitHub上发布结果，因为其他人可能会对它感兴趣。

如果您不希望node_modules在您的存储库中，只需创建一个.gitignore文件并添加行node_modules。

我想提供一个中间的选择。
1.不要在git中添加node_modules。
1.使用一个package-lock.json文件来确定你的依赖版本。
1.在您的CI或发布过程中，当您发布一个版本时，请复制node_modules文件夹并备份（例如在云存储中）。
在极少数情况下，您无法访问NPM（或您使用的其他注册表）或NPM中的特定软件包，您可以拥有node_modules的副本，并且可以继续工作，直到您恢复访问。

还有一件事需要考虑：签入node_modules使得使用dependencies和devDependencies之间的差异变得更加困难/不可能。
但另一方面，可以说将经过测试的完全相同的代码推向生产是令人放心的-因此包括devDependencies。

如果在package.json中提到依赖项，则不需要签入node_modules。任何其他程序员都可以通过执行npm install来获取它，并且npm足够智能，可以将node_modules置于项目的工作目录中。

答案并不像Alberto Zaccagni suggests那么简单。如果你开发应用程序（尤其是企业应用程序），在你的git repo中包含node_modules是一个可行的选择，你选择哪种替代方案取决于你的项目。
因为他很好地反对node_modules，所以我将集中讨论它们的论点。
想象一下，你刚刚完成了企业应用程序，你将不得不支持它3-5年。你肯定不想依赖于某人的npm模块，明天可能会消失，你不能再更新你的应用程序。
或者你有你的私人模块，不能从互联网上访问，你不能在互联网上构建你的应用程序。或者也许你不想依赖于你的最终构建在npm服务出于某种原因。
你可以在这篇Addy Osmani的文章中找到优点和缺点（虽然它是关于Bower的，但情况几乎相同）。我将引用Bower主页和Addy的文章结束：
如果您创作的软件包不是供其他人使用的（例如，您正在构建Web应用程序），则应始终将已安装的软件包检入源代码控制。