4

私はComposer / Packagistトレインに乗ろうとしています。そのために、ワークフローを管理するための最良の方法を理解しようとしています。これにより、選択したフレームワークとアプリケーションを使用してコンポーザーパッケージを作成できますが、可能であれば気を悪くします。 Git/GithubまたはHg/BitBucket（あるいはその両方）でそれを行う方法を整理します。

現在の構造/ワークフロー 

%path%/sites/[framework]
 - contains up to date framework git repo  
%path%/sites/[framework]/application
 - contains app specific code and is a bitbucket repo
*%path%/www/[appname]_public
 - contains public files and is a bitbucket repo i.e. "public_html" folder

適切なエイリアシングを使用すると、これは現在のサイトで機能します（各サイトは「/ sites」内の個別のフォルダーです）。また、2つの別個のリポジトリメカニズムを使用しているため、アプリケーションに大きな影響を与えることなく、いつでもその特定のサイトのフレームワークを更新できます。その逆も可能です。

パッケージは「application」フォルダーのサブフォルダーとして含まれているため（作成してテストできます）、これらのフォルダーを個別のリポジトリとしてパッケージとして「ラップ」し、githubまたはで利用可能なスタンドアロンのコンポーザーパッケージとして提供するにはどうすればよいですか？ビットバケット？私はちょっと途方に暮れています。

%path%/sites/[framework]/application/[module]
 - contains controllers, models, views, etc... to be wrapped up as a composer
   "package" and made available on github or bitbucket as its own repo.

おそらく、ここの誰かが私にこれに関する論理、またはそれを設定する方法を教えてくれるでしょう。私はそれを行う方法を理解することができないからです。出来ますか？私は問題を考えすぎていますか？

たぶん私の考え方全体が間違っています。既存の構造でタスクを実行しようとしましたが、GitサブモジュールまたはHGネストリポジトリが期待どおりに機能していないようです。

私のワークフローには深刻な欠陥がありますか、それともこれを達成するためにGitの知識がもっと必要ですか？より簡単でより良い方法はありますか？フレームワーク/SiteApplicationCode/パッケージを、欠落しているメカニズム/ロジックを備えた個別のリポジトリとして保持できる場合は、構造/ワークフローを喜んで再構築します。

よろしくお願いします。

4

1 に答える 1

1

％path％/ sites / [framework] / application / [module]は、git.yourcompany.comなどの公開（必要な場合のみ会社に公開）の場所にプッシュすることで他のユーザーと共有するgitリポジトリである必要があります。

次に、satis.company.comでアクセス可能なsatis Composerリポジトリを作成し、パブリックリポジトリを参照するjsonファイルで初期化します。モジュールをcomposer-installableにするために、最初に各モジュールのcomposer.jsonファイルを作成してください。

次に、アプリケーションごとにcomposer.jsonファイルを使用してプロジェクトを再インストールします。これにより、目的のモジュールが目的のバージョンでフェッチされます。それらは％path％/ sites / [framework] / application / vendor /に表示され、自動ロードファイルが生成されます。

コードをgithubで公開できる場合は、git + satisの部分をスキップして、モジュールをpackagist.orgに送信できます。

私はあなたの構造を誤解したかもしれませんが、あなたがその考えを理解してくれることを願っています

于 2012-10-19T14:42:04.727 に答える