3

私は git を使い始めたばかりで、これまで取り組んできたプロジェクトを実際に「整理」しようとしたことはありませんでした。しかし、最近個人用の開発サーバーを購入したばかりで、すべてのプロジェクトを整理し、バージョン管理を使用したいと考えていました。

過去 8 時間かけて、プロジェクト内のファイルを整理するためのさまざまな推奨方法を調査しましたが、それは非常に主観的な問題であることがわかりました。しかし、私は自分にとってほぼすべての原因で機能すると思われるシステムを開発しました。ディレクトリ構造で特定のタスクを達成する方法に関して、非常に客観的な質問が 1 つあります。

現在、私は次のような構造を検討しています。

src/ - All deliverables in an uncompiled form (PHP files, c source files, etc)
data/ - Crucial but unrelated data (SQL databases, etc.)
lib/ - Dependencies -- THIS IS WHERE MY QUESTION LIES
docs/ - Documentation
build/ - Scripts to aide in the build process
test/ - Unit tests
res/ - Not version controlled. Contains PSD files and non-diff-able stuff
.gitignore
README
output.zip - Ready-to-install finished product (just unzip and go)

前述したように、私の本当の問題はこのlib/ディレクトリを中心に展開しています。これには、プロジェクトで実行する必要があるすべてのファイルとプログラムを含める必要がありますが、これらはプロジェクトの範囲外であり、編集しません。このフォルダに必要ないくつかの機能:

  • これらは最終製品を実行するために必要なので、output.zip に含める必要があります。
  • このフォルダーをバージョン管理して、git リポジトリをダウンロードした人がすべての依存関係にアクセスできるようにしたいと考えています。
  • 複数のプロジェクトに同じ依存関係がある場合、サーバー上に同じファイルの 18 個の冗長コピーを保持したくありません
  • これらの依存関係を私の他のプロジェクトから取得できるようにしたいと思います (1 つのプロジェクトが別のプロジェクトのライブラリとして機能できる必要があります)。

仮想ディレクトリ（シンボリックリンク）を使用することで、同じファイルの18個の冗長コピーを回避できますが、私の理解では、gitはファイルをコピーせずにこのシンボリックリンクをそのままリポジトリにコピーします。したがって、他の誰かが私のリポジトリを取得した場合、ダングリング ポインターがあり、ライブラリがありません。

最初は、 git-submoduleを使用してやりたいことができるように見えました。ただし、私の理解では、これは別のリポジトリのコンテンツ全体を取得し、それをサブディレクトリとして扱います。したがって、「依存関係 A」を含めた場合、ライブラリ フォルダーは次のようになります。

/lib/A/src/
/lib/A/data/
...
/lib/A/test/
.gitignore
README
output.zip

スクリプト (PHP、Perl など) の場合、おそらく を使用して依存関係を読み込むことができますrequire('lib/A/src/dependency.php')が、DLL またはバイナリ ファイルの場合、output.zip から出力ファイルを読み取る簡単な方法はありません。完成したプロジェクトをきれいな zip ファイルにまとめるのではなく、ルート レベルに直接保存することもできますが、プロジェクトがたとえば Web サイトの場合、何百ものファイルがリポジトリ ルートに散らかってしまう可能性があります。

別のリポジトリを自分のライブラリとして含め、自分のプロジェクト内のライブラリ ファイルを簡単に参照し、自分のリポジトリをフェッチする人にライブラリを意味のある形でコピーし、開発サーバーで同じファイルの重複コピーを防ぐにはどうすればよいですか?

編集:Googleでしばらく検索した後、この同様の問題が見つかりましたが、PHPプロジェクトのみに対応しています。オートローダを使用すると、PHP 環境で基盤となるファイル システムをマスクできますが、同様のアプローチを C++ プロジェクトにどのように適用しますか? それとも Python プロジェクトですか? それともJavaプロジェクトですか？

今日このプロジェクトについてもっと考えてみると、新しい方向性が必要かもしれない他のいくつかの考えが頭に浮かびました。1 つ目は、ライブラリの入れ子が非常に深いという問題です。プロジェクト A が、プロジェクト D に依存するプロジェクト C に依存するプロジェクト B に依存している場合、ディレクトリ構造は次のようになります。

A/lib/
A/lib/B/
A/lib/B/lib/
A/lib/B/lib/C/
A/lib/B/lib/C/lib/
A/lib/B/lib/C/lib/D/

明らかに、これは迷惑になるだけでなく、それ自体が冗長になります。

通常の人は、git リポジトリを実行するときに依存関係をどのように処理しますか?

4

4 に答える 4

3

私が携わってきたプロジェクトでは、サブモジュールは依存関係管理に関して特定のケースにのみ適しています。他のケースでは、これは他のフレームワークによって補完されます。ほとんどの場合、プロジェクト間で共有できる共通のビルド スクリプトがある場合など、完全なリポジトリが必要な場合にサブモジュールを使用することを好みます。

さまざまなスタックの依存関係管理に焦点を当てた特定のツールがあります -

等

これらのツールは、冗長性管理を処理します。

現在、私はこのセットアップがある.netプロジェクトにいます-

  1. Powershell build scripts shared across projects using submodules. Buildscript repository contains all 3rd party executables required to deploy any of our .net applications and the respective wrapper powershell scripts, plus some scripts to load the conventions, config etc.
  2. Nuget server (via Teamcity) hosting nuget packages for common binaries shared across projects. Nuget Package restore is a feature that allows fetching packages as part of the build.
于 2013-03-08T15:47:35.750 に答える
2

ワークフローを統一するのは良いことですが、飼いならそうとしている獣を尊重する必要があります。プロジェクトごとに異なるディレクトリ構造が必要です。3DアニメーションプロジェクトからPHPプロジェクト、C ++プロジェクトに至るまで、そしてその間のあらゆる場所で、同じワークフローに準拠するようにそれらを絞ると、長期的には作業と頭痛の種が増えるだけであることがわかりました。ほとんどのIDEは、箱から出してすぐに優れた「新しいプロジェクト」構造を備えており、他の開発者がすぐに知って理解できるものです。

依存関係の問題については、スーパープロジェクトアプローチを実装してみてください：http： //git-scm.com/book/en/Git-Tools-Submodules

于 2013-03-10T19:59:34.903 に答える
0

ライブラリを埋め込まないでください。これはセキュリティ上の悪夢です! たとえば、libpng、libjpeg、libtiff などの画像形式ライブラリをアプリケーションに埋め込むと、その画像形式を使用したい場合、それらのライブラリに含まれる可能性のあるセキュリティの脆弱性に対してアプリケーションが開かれ、ユーザーはそれを簡単に知る方法がありません。セキュリティの問題を解決するには、プログラムを更新する必要があります。アプリケーションの範囲外に依存関係を残すと、パッケージ マネージャーはライブラリを認識し、セキュリティの脆弱性が明らかになったときにアクションを実行できます。

依存するライブラリは、プロジェクトの範囲外のままにしておきます。複数のプロジェクトで使用するライブラリを個人的に開発した場合は、それを独自のリポジトリに入れて、個別にリリースします。

Unix のような OS (linux/bsd/solaris/etc.) の場合、ユーザーはパッケージ マネージャーを使用して個別にインストールします。ソフトウェアをリリースすると、パッケージ マネージャーは依存関係を認識し、アプリケーションをインストールする前に必要な依存関係をインストールするため、マニュアルはありません。アクションが必要です。

Windows の場合、個別のバンドル プロセスを使用して、依存するライブラリをコンビニエンス インストーラにバンドルします。このインストーラは、ライブラリをプログラム ディレクトリではなく、共有システム ディレクトリにインストールします。

ところで、大量の重複なしにやりたいことを行うための技術的な手段は git にはありません。

于 2013-03-13T07:27:27.920 に答える
0

あなたは一般的な質問をしましたが、いくつかの事例について具体的に質問しました。私はより一般的な方向に傾きます。簡単に言えば、これはビルド システムの問題であり、バージョン管理システムの問題ではありません。

Java の場合、使用できるいくつかの異なる依存関係管理/解決ツールがあります。ビルド システムは、ビルド時にこれらの依存関係をフェッチして利用可能にする方法を理解する必要があります。ただし、これらは一時的なものであり、バージョン管理にチェックインしません。さらに、Maven は、たとえば/target、両方の出力を含むフォルダーを使用します (例: output.zip - 出力のクリーニングが容易になるため、これもお勧めします。複数の出力ファイルがある場合はどうなりますか?バリアントはどうなりますか?など)。 ) および静的分析出力などの他のアイテム - また、外部ディレクトリを使用して依存関係をローカルにキャッシュしますが、これは一時的なものである可能性があり、気にしません。結論: バージョン管理には永続化されません。

私の知る限り、これは C++ ではそれほど簡単ではありません。CMakeは外部プロジェクトのビルドをサポートしているようです。私は最近、何が可能かを確認するためにこれをいじり始めたばかりなので、「簡単に実行できる」と言って誤解を招きたくないのですが、それが実行できるのは当然のことです。どれだけの労力を費やす必要があるかだけです。したがって、フォルダーを呼び出すかどうかに関係なく/libs、ビルドで依存関係を推移的に扱うようにする必要があります (推移的な依存関係で頑張ってください)。

于 2013-03-08T15:48:06.373 に答える