生成されたドキュメントをGitリポジトリに保存する必要がありますか？
jsdocs などのツールを使用すると、コード内のコメントに基づいて、コードベースに静的HTMLファイルとそのスタイルが生成されます。
これらのファイルをGitリポジトリにチェックインする必要がありますか、それとも.gitignoreで無視する必要がありますか？
特定の必要性がない場合、バージョン管理にチェックインされた他のファイルを使用してビルドツールからビルド、再作成、構築、または生成できるファイルはチェックインしないでください。ファイルが必要な場合、他のファイルから（再）ビルドできます。ソース（通常、ビルドプロセスの一部として）。
したがって、これらのファイルは.gitignoreで無視する必要があります。
私のルールは、リポジトリを複製して「ビルド」ボタンを押すと、しばらくするとすべてがビルドされるということです。生成されたドキュメントでこれを実現するには、2つの選択肢があります。誰かがこれらのドキュメントを作成してgitに配置する責任があるか、開発マシンで必要なソフトウェアを正確にドキュメント化して、「ビルド」を押すことを確認します。ボタンは私のマシン上にすべてのドキュメントをビルドします。
生成されたドキュメントの場合、ヘッダーファイルを1つ変更するだけでドキュメントが変更されるので、誰かが更新したときだけでなく、常に正しいドキュメントが欲しいので、各開発者のマシンでこれを行うのが良いでしょう。何かを生成するのに時間がかかり、複雑で、ライセンスが1つしかないソフトウェアが必要になるなどの状況もあります。その場合、1人の人にgitに物事を入れる責任を与える方が適切です。
@Curt Simpson：すべてのソフトウェア要件があること文書化は、私が多くの場所で見たよりもはるかに優れています。
これらのファイルは、生成するためのデータがすでに存在しているため、チェックインしないでください。データを2回保存したくない（DRY）。
CIシステムを使用している場合は、ドキュメントをビルドさせて、そのビルド用に保存/ Webサーバーに発行することができます。
それらをいくつかのリポジトリ（同じまたは異なるもの、できれば自動的に生成される）に置くことの1つの利点は、ドキュメントに対するすべての変更を確認できることです。ソースコードの差分よりも、これらの差分の方が読みやすい場合があります（特に、実装の変更ではなく、仕様の変更のみに関心がある場合）。
ただし、他の回答で説明されているように、ほとんどの場合、それらをソース管理に含める必要はありません。
無視されます。とにかく、リポジトリのユーザーがそれらを再構築できるようにする必要があります。これにより、ドキュメントが常に同期していることを確認する複雑さがなくなります。すべてを1つの場所に配置し、何も構築する必要がない場合は、構築されたアーティファクトを1つの場所にバンドルしない理由はありません。ただし、ソースリポジトリは実際にはこれを行うのに適した場所ではありませんが、複雑なため、ほとんどの場所よりも害が大きくなります。
展開プロセスによって異なります。ただし、生成されたファイルをリポジトリにコミットすることは例外であり、可能であれば回避する必要があります。 Yesで次の両方の質問に答えられる場合、ドキュメントのチェックインが有効なオプションである可能性があります。
- ドキュメントは本番環境の要件ですか？
- デプロイメントシステムには、ドキュメントを構築するために必要なツールが不足していますか？
これらの条件が当てはまる場合、レガシーシステムまたは特別なセキュリティ制約のあるシステムで展開している可能性があります。別の方法として、生成されたファイルをリリースブランチにコミットして、マスターブランチをクリーンな状態に保つことができます。
場合によります。それらのドキュメントの場合：
readme.mdのようにリポジトリの一部である必要がある場合は、それらをgitリポジトリに保持することをお勧めします。これらの状況を自動化された方法で処理するのは難しいためです。CIシステムのように、それらを構築および更新する自動化された方法がなく、一般ユーザー向けに表示することを目的としている場合は、それらをgitリポジトリに保持することをお勧めします。
それらを構築するのにかなりの時間がかかり、それらを維持することは正当化できます。
一般ユーザー向け（ユーザーマニュアルなど）に表示することを目的としており、ビルドにかなりの時間がかかりますが、以前のドキュメントにアクセスできなくなり（オフライン）、gitリポジトリに保持することは正当化できます。
一般の視聴者向けであり、その変更/進化の履歴を示す必要があります。以前のドキュメントバージョンをコミットし続け、以前のバージョンにリンクされた新しいバージョンをビルド/コミットする方が簡単です。正当。
すべてのチームがコミットされる特定の受け入れられた理由があり、それらをgitリポジトリに保持することは正当化できます。 （私たちはあなたのコンテキストを知りません、あなたとあなたのチームは知っています）
他のシナリオでは、無視しても問題ありません。
ただし、それらをgitリポジトリに保持する正当な理由がある場合は、チームが直面している別のより大きな問題の兆候である可能性があります。 （CIシステムまたは同様の、恐ろしいパフォーマンスの問題がない、構築中のダウンタイムなどに直面している）
バージョン管理の原則として、「プライマリオブジェクト」のみをリポジトリに保存し、「派生オブジェクト」は保存しないでください。
ルールには例外があります。つまり、派生オブジェクトを必要とするリポジトリのコンシューマーがあり、それらを生成するために必要なツールがないことが合理的に予想される場合です。材料の量が扱いにくいなど、その他の考慮事項が考慮されます。 （プロジェクトがすべてのユーザーにツールを入手させるだけの方が良いでしょうか？）
この極端な例は、コンパイラーがその言語自体で記述されているまれなプログラミング言語を実装するプロジェクトです（よく知られている例には Ocaml または Haskell が含まれます）。コンパイラのソースコードのみがリポジトリにある場合、誰もそれをビルドできません。仮想マシンで実行できるコンパイラのコンパイル済みバージョンがないため、そのコンパイラのソースコードをコンパイルできます。さらに、言語の最新機能はコンパイラソース自体ですぐに使用されるため、ビルドには常に最新バージョンに近いコンパイラが必要です。個別に取得した1か月前のコンパイラ実行可能ファイルは、現在のコードをコンパイルしません。 1か月前には存在しなかった言語機能を使用しています。この状況では、コンパイラのコンパイル済みバージョンをリポジトリにチェックインして最新に保つ必要があります。