回答:
その答えは、Alberto Zaccagniが示唆するほど簡単ではありません。アプリケーション（特にエンタープライズアプリケーション）を開発する場合、git repoにnode_modulesを含めることは実行可能な選択であり、どちらを選択するかはプロジェクトによって異なります。
彼はnode_modulesに対して非常によく議論したので、それらの引数に集中します。
エンタープライズアプリが完成し、3〜5年間サポートする必要があるとします。あなたは間違いなく明日消える可能性がある誰かのnpmモジュールに依存したくはなく、あなたはもはやあなたのアプリを更新することができません。
または、インターネットからアクセスできないプライベートモジュールがあり、インターネット上でアプリを構築できません。あるいは、何らかの理由でnpmサービスの最終ビルドに依存したくない場合もあります。
このAddy Osmaniの記事には長所と短所があります（Bowerに関するものですが、ほとんど同じ状況です）。そして、私はバウアーのホームページとAddyの記事からの引用で終わります：
「他のユーザーが使用することを目的としたパッケージを作成していない場合（たとえば、Webアプリを構築している場合）は、インストールされているパッケージを常にソース管理にチェックインする必要があります。」
git checkout fooです。node_modulesがVCSの下にない場合–ブランチの切り替えがgit checkout foo ; npm installあり、現在のNPMバージョンが機能するために必要なものは何でも;）
モジュールの詳細はに保存されていpackages.jsonます。これで十分です。チェックインする必要はありませんnode_modules。
人々node_modulesはモジュールの依存関係をロックするためにバージョン管理に格納するために使用されましたが、npmシュリンクラップではもはや必要ありません。
@ChrisCMがコメントで書いたように、この点についての別の正当化：
また、注目に値するのは、ネイティブ拡張を含むモジュールはアーキテクチャーごとに機能しないため、再構築する必要があることです。それらをレポに含めないための具体的な正当化を提供します。
現在のシステムに適切なバイナリをインストールするPhantomJSやnode-sassなどのパッケージがあるため、node_modulesをチェックインしないことをお勧めします。
これは、1つのDevがnpm installLinuxで実行され、node_modulesをチェックインする場合、Windowsでリポジトリを複製する別のDevには機能しないことを意味します。
npmがダウンロードをインストールするtarballをチェックインして、npm-shrinkwrap.jsonそれらをポイントすることをお勧めします。このプロセスは、shrinkpackを使用して自動化できます。
npm install --global shrinkpack、縮小されたパッケージをインストールするために他のパッケージを要求することによって、それ自体に遅延が生じないのではないでしょうか？これはAddyのアドバイスに反します。
shrinkpackビルドの依存関係を確実にインストールするには、依存関係が必要です。したがって、ビルドツール自体のインストールは、すべてのビルドの依存関係をバージョン管理に提出しないという議論の弱点になります。
このトピックはかなり古いと思います。しかし、npmのエコシステムの状況が変化したため、ここで提供された引数に対するいくつかの更新がありません。
私は常にnode_modulesをバージョン管理下に置かないことをお勧めします。受け入れられた回答のコンテキストにリストされているように、そうすることによるほぼすべての利点は、現在のところかなり時代遅れです。
公開されたパッケージは、npmレジストリから簡単に取り消すことができなくなりました。したがって、プロジェクトが以前に依存していた依存関係が失われることを恐れる必要はありません。
VCSにpackage-json.lockファイルを配置すると、頻繁に更新される依存関係が解消され、同じpackage.jsonファイルに依存しているにもかかわらず、セットアップが異なる可能性があります。
したがって、オフラインビルドツールがある場合にnode_modulesをVCSに配置することが、残っている唯一の適格なユースケースと見なされる場合があります。ただし、node_modulesは通常、かなり速く成長します。更新を行うと、多くのファイルが変更されます。そして、これはさまざまな方法でリポジトリに影響を与えています。あなたが本当に長期的な影響を考慮するならば、それも障害になるかもしれません。
svnのような集中化されたVCSは、コミットおよびチェックアウトされたファイルをネットワーク経由で転送する必要があり、node_modulesフォルダーのチェックアウトまたは更新に関しては非常に遅くなります。
gitに関しては、この大量の追加ファイルがリポジトリを即座に汚染します。gitはファイルのバージョン間の違いを追跡するのではなく、1つの文字が変更されるとすぐにファイルのどちらかのバージョンのコピーを保存することに注意してください。依存関係を更新するたびに、別の大きな変更セットが発生します。バックアップとリモート同期に影響を与えるため、gitリポジトリは急速に大きくなります。後でgitリポジトリからnode_modulesを削除することを決定した場合、歴史的な理由により、それはまだその一部です。gitリポジトリをリモートサーバー（バックアップなど）に配布している場合、それをクリーンアップすることは、実行中に発生するもう1つの痛みを伴うエラーが発生しやすいタスクです。
したがって、効率的なプロセスを重視し、物事を「小さく」したい場合は、以前にフェッチした依存関係のセットをダウンロードするために、Nexosリポジトリなどの個別のアーティファクトリポジトリ（または単にZIPアーカイブを備えたHTTPサーバー）を使用したいと思います。
node_modulesフォルダーを確認すると便利な場合があるというivoszzに同意しますが、 ...
シナリオ1：
1つのシナリオ：npmから削除されるパッケージを使用します。node_modulesフォルダーにすべてのモジュールがある場合は、問題ありません。package.jsonにパッケージ名しかない場合、それを取得することはできません。パッケージが24時間以内の場合は、npmから簡単に削除できます。24時間以上経過している場合は、連絡する必要があります。だが：
サポートに連絡すると、そのバージョンのパッケージを削除すると他のインストールが失敗するかどうかが確認されます。その場合は削除しません。
したがって、この可能性は低いですが、シナリオ2があります...
シナリオ2：
これが当てはまる別のシナリオ：ソフトウェアのエンタープライズバージョンまたは非常に重要なソフトウェアを開発し、package.jsonに書き込みます。
"dependencies": {
"studpid-package": "~1.0.1"
}function1(x)そのパッケージのメソッドを使用します。
studpidパッケージの開発者はメソッドの名前を変更今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を超える）をリポジトリにプッシュすると、メモリ容量が消費されます。数百メガバイト（package.json＆node_modules）と比較して数キロバイト（package.jsonのみ）...考えてみてください。
あなたはそれを行うことができます/次の場合にそれについて考える必要があります：
ソフトウェアは非常に重要です。
何かが失敗するとお金がかかります。
npmレジストリを信頼していません。npmは集中管理されており、理論的にはシャットダウンできます。
次の場合、99.9％のケースでnode_modulesフォルダーを公開する必要はありません。
自分だけのためのソフトウェアを開発します。
あなたは何かをプログラムし、誰か他の人がそれに興味を持っているかもしれないので、結果をGitHubに公開したいだけです。
node_modulesをリポジトリに入れたくない場合は、.gitignoreファイルを作成して行を追加しますnode_modules。
npm install、WindowsとMacOSで呼び出すと、一部のパッケージで異なるファイル（OS依存ファイル）が生成される可能性があることです。しかし、それについてはよくわかりません。誰かがこれが本当であることを確認できますか？
package-lock.json。studpid-packageの更新で将来問題が発生した場合は、ロックファイルをロールバックして、機能していた正確なバージョンを確認できます。
途中の代替案を提供したいと思います。
node_modulesgitに追加しないでください。package-lock.jsonファイルを使用して、依存関係のバージョンを特定します。NPM（または使用する他のレジストリー）またはNPM内の特定のパッケージにアクセスできないというまれなイベントでは、node_modulesのコピーがあり、アクセスを復元するまで作業を続けることができます。
もう1つ検討する必要があります。チェックインnode_modulesすると、との違いを使用することが難しく/不可能にdependenciesなりdevDependenciesます。
一方、テストを行ったのとまったく同じコードをプロダクションにプッシュすることは安心できると言えdevDependenciesます。