ドキュメントとプロジェクト管理にGitを使用する必要がありますか？コードは別のリポジトリにある必要がありますか？
グループプロジェクトのGitリポジトリを起動しています。ドキュメントを保存することは理にかなっていますかコードと同じGitリポジトリに-これはgitリビジョンフローの性質と競合するようです。
これが私の質問の要約です：
コードとドキュメントの両方が同じリポジトリにチェックインされているの場合、Gitリビジョンスタイルは混乱するでしょうか？ これでの経験？
Gitはドキュメントのリビジョン管理に適していますか？
私は[〜＃〜] not [〜＃〜]改訂管理システムを一般的にドキュメントに使用すべきか、または使用すべきでないかを尋ねています-すべきです。
これまでのフィードバックに感謝します！
ドキュメントは常にSVNに保存されます。実際、ユーザーマニュアル全体はLaTeXで記述され、SVNに保存されています。特にLaTeXを選択した理由は、それがテキストベースの言語であり、行ごとの相違を簡単に表示できるためです。
Microsoft Officeの.docファイル、スプレッドシート、.Zipファイルなど、テキスト以外の形式のファイルも必要に応じて保存します...差分。
重要なのは、ドキュメントが適切に構成されていることを確認し、必要なときにドキュメント（およびソース）を検索（および更新）できるようにすることです。
まあそれはあなたがドキュメンテーションに使用するフォーマットに依存します。それがテキストベースの何かであるならば、それはすべて良いです。
Gitはバイナリコンテンツも保存でき、リビジョンを追跡できますが、diff出力は意味がありません。
Perldoc podのようにコード自体にドキュメントを保存することもできます。Javaにも、このための形式/注釈があります。
ドキュメンテーションのためにgitまたは他のバージョン管理システムを使用する際に問題があると思われる理由を私は想像できません。ソースコードと同様に、ドキュメントには完全な履歴があり、必要に応じて以前のバージョンに戻す機能が必要です。これにはバージョン管理システムが最適です。
ドキュメントを保存するためにある種のバージョン管理システムを使用することは簡単です。質問のより興味深い部分は、同じ場所にドキュメントをソースコードとして保存するのが良いアイデアかどうかです。ここで考えられる問題は、その場合、コードとドキュメントに異なるアクセス権限を設定することが難しい場合があることです。また、多くのビジネスケースでは、ドキュメントにアクセスする必要がありますが、マーケティングやBA部門などのソースコードは必要ありません。
私が働いている会社では、ドキュメントをSVNに入れています。ただし、競合がいくつかあり、それを共有する必要があったため、Mediawikiに移動することにしました。
最初はそれはTracでしたが、その後Mediawikiに移動したので、使いやすさが向上しました...
SVNの主な問題は、SVNの認証システムがあった共有の原因でした。
私は同様の質問でここに来ました。私たちはSVN環境から来ており、プロジェクトに関連するすべての資料を同じリポジトリに保持することは基本的に非常に簡単です。 SVNの性質上、リポジトリの一部を簡単にチェックアウトできるため、ソースコード（たとえば、Webサイトのデプロイメント）だけが必要な場合でも問題ありません。
Gitでは、状況が異なります。チェックアウトは常にルートレベルにあるため、すべてを同じリポジトリに配置する場合は、常に同じディレクトリ構造になります。私が遭遇した1つのアプローチは、すべてを別々のブランチに置くことです。つまり、コードブランチ（通常は通常のマスター、開発などのブランチ）と、独自の個別のディレクトリ構造を持つdocブランチがあります。それが最良のアイデアかどうかはまだわかりませんが、それは私があなたの質問の根底にあると私が想像する問題を回避する提案です。
私は内部ドキュメントにwikiを使用しています...リビジョンPLUSの目立つアクセス/簡単な編集を取得してください。ドキュメントが同期していない場合は、その場で更新してください。エンドユーザー向けのドキュメントについては、 Madcap Flare のような専門的なツールを検討してください。ドキュメントの共有、作成、変換にXML方言を使用しています。