web-dev-qa-db-ja.com

リポジトリに最適な構造は何ですか？

私は多くのオープンソースソフトウェアリポジトリを調べましたが、いくつかの共通の要素と、人々が互いに異なる方法で行うことを見つけました。

たとえば、すべてのリポジトリには、READMEファイル、INSTALLファイル、COPYINGファイルなどがあります。

他のものは異なります：

  • Gitなどの一部のプロジェクトはルートレベルにソースコードを持っていますが、他のプロジェクトはsrc/フォルダーにソースコードを持ち、Linuxカーネルなどの他のプロジェクトはルートレベルの異なるフォルダーにソースコードを展開しています。コードを領域で分割します。
  • 一部のテストはt/フォルダーにあり、他のテストはtests/フォルダーにあるか、別の名前が付けられています。
  • パッチの提出とメンテナが誰であるかに関するファイルがあるものもあり、それらは一部のDocumentation/内またはルートレベルにある可能性があります。

推奨事項はありますか？ベストプラクティス？

例：個人的には、ルートレベルのgit-fashionのコードは好きではありません。それは厄介に見え、寄稿者として始めようとしている人を混乱させます（特に、フォルダー内にいくつかのコードがあり、ルートレベルにもスクリプトがあるため、本当に厄介です）。

自分でプロジェクトを始めて、最初からやりたいと思ったら、おすすめはありますか？ベストプラクティス？どうすればクリーンでクリアな構造を作ることができますか？

open-sourceversion-controlgitproject-structure
1
jpmelos

その他のビット用にルートを予約し（リポジトリに保存するのに役立つその他の関連ディレクトリやファイルのための場所を確保します）、ソースツリーを1レベル下に開始します。複数のコンポーネントの場所に対応するには、最初のコンポーネントに2番目のレベルを追加します。

Gitを使用している場合は、後でいつでも再形成できますが、あまり気にしないでください。

5
Joppe

この質問はかなり前に尋ねられましたが、あなたが解決策をマークしなかったので、私は貢献を追加すると思います。

オープンソースでの私の経験に基づいて、構造を設定する前にいくつかのことを考慮する必要があります。

考慮事項

  1. 言語とテクノロジー：フレームワークと言語は、構造がどのように見えるかを決定します。たとえば、PHPを使用したWeb開発構造は、C++デスクトップとは異なります

  2. Deployment：このコードをこのrawフォームでデプロイする必要がある場合（たとえば、pythonのプログラム））、構造はコンパイルされたプログラムとは大きく異なります。Python構造は実際にはエンドユーザーに表示されるため、外観に影響を与えます。

  3. フレームワークとインクルード：プロジェクトでサードパーティのライブラリを使用している場合は、構造を調整する必要があります。

  4. ソース管理：使用しているソース管理プロバイダーは、特定のファイルが配置される場所に影響を与える可能性があります。

ただし、これらすべてにもかかわらず、ほとんどの構造を次のように一般化できます。

株式構造

  1. ルート：ルートは、構成ファイル、ドキュメント（README.mdなど）用に予約する必要があります。また、VSソリューションファイルとgitファイルを含めることもできます。
  2. / src：私たちは皆これを知っています。これは、すべてのソースファイルが配置される場所です。ただし、ヘッダーを使用する言語（またはアプリケーションのフレームワークがある場合）では、これらのファイルをここに配置しないでください。
  3. / lib、/ dep、/ incなど：これは、すべての依存関係を保存するディレクトリです。また、プロジェクトが複数のファイルにある場合は、ヘッダーと添付ソースをここに配置します。
  4. / doc：ドキュメントはここにあります。たとえば、docs.mdです。
  5. / res：あまり一般的ではありません。プロジェクト内のすべての静的リソース。たとえば、画像や音声。
  6. / tools、/ scripts：使用に便利なディレクトリ。スクリプトの作成、スクリプトの名前変更など、プロジェクト内のタスクを自動化するためのスクリプトを含める必要があります。通常、たとえば.sh、.cmdファイルが含まれます。
  7. / build：ビルドされたファイルが移動する場所。通常、DebugとReleaseの2つのディレクトリに分割され、バイナリ、.DLL、およびコンパイル済みファイルを含めることができます。 makefileなどのビルドスクリプトも含まれる場合がありますが、通常はルートにある必要があります。
  8. / test：ユニットテストが含まれています...いいえ、実際にはすべてのテストです！

注目すべき例

私はあなたのための良い構造のいくつかの素晴らしい例を見つけました：

これらのプロジェクトはどちらも、非常に明確に定義された構造を持つ大規模なオープンソースプロジェクトです。

これがお役に立てば幸いです。

2
EMarshall

リポジトリがパッケージとして配布または展開する予定のライブラリである場合は、特定の構造が必要になる場合があります。たとえば、pipには、さまざまなファイルとその場所に関するいくつかの厳格なルールがあり、リポジトリの特定の構造に変換されます。

フレームワークは、いくつかのルールを指示することもできます。

使用するツールにも特定の期待がある場合があります。たとえば、Visual Studioで作成されたプロジェクトの場合、ルートディレクトリに.slnファイルがあり、Visual Studioのソリューションの仮想構造は、必ずしもファイルの物理構造を反映しているとは限りません。たとえば、プロジェクトはIDEの仮想構造にグループ化されていても、すべてディスク上のルートディレクトリに格納されている場合があります。

あなたのコミュニティも特定のスタイルを持っているかもしれません。たとえば、C＃プロジェクトが次のようにグループ化されることは珍しくありません。

  • /Project1
  • /Project1Tests
  • /Project2
  • /Project2Tests

/srcおよび/testsディレクトリを持つ代わりに。 /tが一般的な言語を使用しているようです。 /tディレクトリが含まれているリポジトリを見たことがありません。

最後に、バージョン管理に関連するツールにも制約がある場合があります。たとえば、GitHubを使用する場合、GitHubはこのファイル内のドキュメントを自動的に表示するため、README.mdを使用することをお勧めします。

次のルールを収集したら：

  • パッケージマネージャー、
  • 枠組み、
  • IDE、
  • 地域社会・共同体、
  • バージョン管理エコシステム、

適用するルールについて明確なビジョンを持っている必要があります。疑問がある 選択した言語/テクノロジーのオープンソースリポジトリを確認してください で、その構造をコピーしてください。

0
Arseni Mourzenko