ドキュメントとプロジェクト管理にGitを使用する必要がありますか？コードは別のリポジトリに配置する必要がありますか？

グループプロジェクトのGitリポジトリを起動しています。コードと同じGitリポジトリにドキュメントを保存するのは理にかなっています -これはgitリビジョンフローの性質と矛盾するようです。

ここに私の質問の要約があります：

• コードとドキュメントの両方が同じリポジトリにチェックインされている場合、Gitリビジョンスタイルは混乱するでしょうか？これでの経験？

• Gitはドキュメントのリビジョン管理に適していますか？

• 私はありません一般的にはリビジョン管理システムは、またはマニュアルのために使用すべきではないかどうかを尋ねる-それがなければなりません。

これまでのフィードバックに感謝します！

ドキュメントは常にSVNに保存されます。実際、ユーザーマニュアル全体はLaTeXで記述され、SVNに保存されています。LaTeXを選択した理由は、テキストベースの言語であり、行ごとの差分を簡単に表示できるためです。

また、必要に応じて、Microsoft Office .docファイル、スプレッドシート、.zipファイルなどの非テキスト形式のファイルも保存します...差分

重要なのは、ドキュメントがきちんと整理されていることを確認することです。そうすれば、必要なときにドキュメント（およびソース）を見つける（および更新する）ことができます。

まあ、それはドキュメントにどのフォーマットを使用するかによります。それがテキストベースの何かである場合、それはすべて良いです。

Gitはバイナリコンテンツも保存でき、リビジョンを追跡できますが、差分出力は意味がありません。

また、perldoc podのようなコード自体にドキュメントを保存することもできます。javaには、このためのフォーマット/注釈もあります。

ドキュメントにgitや他のバージョン管理システムを使用することに問題があると思われる理由を想像することはできません。ソースコードと同様に、ドキュメントには完全な履歴があり、必要に応じて以前のバージョンに戻す機能が必要です。バージョン管理システムはこれに最適です。

ある種のバージョン管理システムを使用してドキュメントを保存するのは簡単です。質問のより興味深い部分は、ソースコードと同じ場所にドキュメントを保存することをお勧めしますか？ここで起こりうる問題は、その場合、コードとドキュメントに異なるアクセス権限を設定するのが難しいかもしれないということです。また、多くのビジネスケースでは、マーケティングや学部など、ソースコードではなくドキュメントにアクセスする必要があります。

私が働いている会社では、ドキュメントをSVNに入れています。ただし、競合がほとんどなく、共有する必要があるため、Mediawikiに移動することにしました。

最初はtracでしたが、その後Mediawikiに移行したので使いやすくなりました...

SVNの主な問題は、SVNの承認システムがあった原因です。

• リポジトリに単なるソースコード以上のものがあることは非常に良いことです。

  すべてのリソースをグループ化して、プロジェクトを分散したファイルのコレクションではなく、まとまりのある一元化されたエンティティにします。貢献者/従業員は、「機能xのドキュメントをどこで変更しますか？」を送信するのではなく、すべての場所を知っています。メール。

  物事を整理しておく必要があります。srcからを分離するシステムがimagesありdocsます。いつでも.gitignoreディレクトリにa を追加して、リポジトリと履歴をきれいに保つことができます。Gitのコミットはファイルベースであるため、*ソースの変更をドキュメントの変更から自由に分離できます。

• 他の人が言ったように、Gitはテキストベースであればドキュメントのバージョン管理に最適です。

• 同意します; ドキュメントは、コードと一緒にバージョン管理する必要があります。

私の信頼性は、GitHubユーザーであり、1つのプロジェクトに貢献し、他の多くのプロジェクトを調査することから生まれました。私の経験では、完全で統一されたプロジェクトは、半分欠けているプロジェクトから簡単にわかります。可能な限り、すべてのプロジェクトを単一のディレクトリに収めるようにしています。

私も同じような質問で来ました。プロジェクトに関連するすべての資料を同じリポジトリに保持するのは基本的に簡単なSVN環境に由来します。SVNの性質上、リポジトリの一部を簡単にチェックアウトできるため、ソースコード（たとえば、Webサイトの展開）だけが必要な場合は問題ありません。

Gitでは、状況は異なります。チェックアウトは常にルートレベルにあるため、すべてを同じリポジトリに配置する場合は、常に同じディレクトリ構造になります。私が遭遇したアプローチの1つは、すべてを別々のブランチに配置することです。つまり、コードブランチ（通常は通常のマスター、開発などのブランチ）と、独自の個別のディレクトリ構造を持つdocブランチがあります。それが最良のアイデアであるかどうかはまだわかりませんが、それはあなたの質問の根底にあると私が想像する問題を回避する提案です。

私は内部ドキュメント用にwikiを使用しています...リビジョンに加えて、目立つアクセス/簡単な編集を取得します。ドキュメントが同期していない場合、その場で更新します。エンドユーザー向けのドキュメントについては、Madcap Flareなどのプロフェッショナルツールを検討してください。ドキュメントの共有、作成、変換にXMLダイアレクトを使用します。

コードでは、思考は通常、行ごとに分けられます。私はソフトラインラップでドキュメントを書く傾向があります。これらのファイルをコミットすると、行は段落全体になります。で読むのはあまり役に立ちませんgit diff。それが、Googleでこのページを見つけたときに解決しようとしていた問題です。Arne Hartherzを紹介してくれてありがとうgit diff --word-diff。git diff --color-wordsもっといいかもしれません。