18

私は、ベンダーのライブラリ（この場合はMagento）と統合しながら、カスタムコードの自分のリポジトリ内で最適に機能する方法を模索しています。私の場合、ベンダーにパッチをプッシュする必要はありません（ただし、それは大きな副次的なメリットになります）。

gitサブモジュールとgitサブツリーを調べました。私はgitサブモジュールが私が必要とするもののために働くとは思わない。Magentoには、次のタイプのツリー構造があります。

/app
  /code
     /community *
     /core
     /local *
  /design
     /adminhtml
     /frontend
        /base
        /yourtheme *
/lib
  /Zend
  /Varien
  /yourlib *
/js
  /yourjs *
  /varien
  /mage

gitサブモジュールの使用は、別々のフォルダーで最適に機能するようです（たとえば、/はアプリで、/ vendor / magentoはサブモジュールです）。ただし、この程度の絡み合いでは、サブモジュールは適切なソリューションとは思えません。私はこれについて間違っていますか？

それは私にgitサブツリーを残します。しかし、gitサブツリーでは、同じコアの仮定（ベンダーブランチは、名前が示すように、サブツリーである）は当てはまりません。Magentoはサブツリーではありませんが、私のプロジェクトが収まるコアライブラリです。あれは正しいですか？

これらの2つのgitの方法が機能しない場合、私が達成しようとしていることを実行するために知っておくべき他の方法はありますか？

私が追求するのを嫌がる最後のオプションは、レポを用意して、それを最新のベンダーの変更（tarballからプルイン）に適用することです。ベンダーのログ情報（ https://github.com/magentomirror/magento-mirrorから取得）を入手すると、新しい更新を並べ替えたり、どのような変更が影響を受けたかを把握したりするのに非常に役立つと思うので、これを追求するのは気が進まない。 。

4

5 に答える 5

3

あなたが言及するそれらの方法のどれも私にとって本当にうまくいきませんでした...

現在、pearを使用してコアモジュールとコミュニティモジュールのアップグレードをインストールおよび管理しており、次の.gitignoreファイルを使用してmagento構造全体をgitリポジトリにコミットしています。

# Dynamic data that doesn't need to be in the repo
/var/*
/media/*
/downloader/pearlib/cache/*
/downloader/pearlib/download/*
/app/etc/use_cache.ser
local.xml

次のシェルコマンドを使用して、空のディレクトリを保持します。

for i in $(find . -type d -regex ``./[^.].*'' -empty); do touch $i"/.gitignore"; done;

私が考えたもう1つのアイデアは、ベンダーブランチモデルを試してみることですが、特にいくつかの大きな依存関係ツリーの場合、つまり、実際の効率のためには、ペアレベルで統合する必要があります。ダウンロードしたモジュールは自動的に分岐する必要があるため、現時点では有料の拡張機能でのみ使用することをお勧めします。

私はmagentoフォーラムで主題を取り上げようとしましたが、返信もありませんでした：http: //www.magentocommerce.com/boards/viewthread/78976/

アップデート：

MagentoComposerインストーラー-一見の価値があります。

ComposerはPHPの標準的な依存関係管理ツールになるため、プロジェクトでComposerを使用するとさらに多くの利点が得られます。

拡張機能、テーマ、ライブラリをプロジェクトツリーにコミットしたり分岐したりする必要はありませんが、常に適切なバージョンと依存関係があります。

ありがとう。

于 2011-03-10T06:32:19.990 に答える
3

これにはmodgitツールを使用できると思います：https ：//github.com/jreinke/modgitmodgitclone コマンドでいくつかのMagentoモジュールのクローンを作成できます。完全な例はここにあります：http ：//www.bubblecode.net/en/2012/02/06/install-magento-modules-with-modgit/

于 2012-03-01T21:45:49.400 に答える
2

キルトのようなワークフロー

これは、以前はキルトで行われていたこととまったく同じです。現在では、Stacked Git（Gitの上）、Mercurial Queues（Hgの上）、またはLoom（Bazaarの上）で行っています。

アイデアは、SCMによってバージョン管理されたファイルに適用される、互いに積み重ねられた一連のパッチを維持することです（場合によっては、新しいファイルも作成されます）。いつでも、スタックを完全にポップし、アップストリームコードを更新してから、すべてのパッチを1つずつ再スタックできます。それらがすべて正常に適用される場合、それは自動的に実行されます。そうでない場合、プロセスは最初の障害のあるパッチで停止します。

純粋なGit

以下は、MagentoGitリポジトリのクローンを作成していると見なします。彼らがGitを使用していない場合でも、たとえばテーラーを使用して、最初に彼らの履歴をGitに変換することでそれを行うことができます。

リベース

Gitを使用すると、リベースすることで、履歴の一部を別の開始点から簡単に再適用できます。したがって、Magentoのクローンを作成し、コードを操作し、Magentoを更新するときに、最後のクリーンなMagentoリビジョンからそれを実行してから、新しいクリーンなMagentoリビジョンに基づいて作業を行うこともできます。

基本的に、通常のGitツールを使用してQuiltのワークフローに従います。

ブランチ

それを行うさらに別の方法は、単にブランチを使用することです。Magentoのリポジトリのクローンを作成し、そこから分岐して、自分のことを実行します。Magentoの最新のリビジョンを取得するときに、2つの分岐をマージします。これは典型的なDVCSワークフローであり、メインブランチに到達することのない機能ブランチに取り組んでいるMagento開発者と見なされます…</ p>

于 2011-07-21T08:27:06.337 に答える
1

あなたの質問は、gitのサブモジュールと一般的なサブツリーについてです。比較に影響を与えるMagentoの詳細は考えられません。おそらくあなたは私が推奨するサブツリーのマージ戦略を知っていますが、そもそもなぜマージする必要があるのか​​わかりません。

マージのベストプラクティスはそれを回避することであり、Magentoアーキテクチャはそれを可能にするのに十分な柔軟性があります。簡単なルールセットに従ってください。

  1. ベンダーコードにパッチを適用することは避けてください。
  2. できない場合。パッチを適用する前に、変更をカスタムMagentoモジュールにパックし、app / code/localに配置することを検討してください。

変更がPHPコードに関係する場合：

  1. OOPの恩恵を受け、特定のメソッドへの変更のみを最小限に抑えることができます。それぞれのクラスを拡張します。
  2. config.xmlのMagento構成メカニズムを使用して、それぞれのクラスを上書きします。
  3. 以前の方法を実行できない場合は、変更（パッチを適用したクラス）をapp / code / localに配置します。つまり、ベンダーのコードの代わりにコードが効率的に使用されるように、include_pathの順序を高くします。

変更がphtmlテンプレートに関係する場合は、Magentoレイアウトメカニズムを使用してベンダーのphtmlを自分のものに置き換えます。適切な設計のカスタマイズには、とにかく大幅な変更作業とレイアウト作業が必要になります。

変更がJS->に関係する場合は、レイアウトを使用して、jsまたはスキンフォルダーに配置されたコードをリンクします。

于 2011-01-23T20:06:03.187 に答える
1

あなたは別のことについて話していると思います。

Yauhenの提案は完全に正しいです。これらすべてをgitで実行でき、サブモジュールやサブツリーは必要ありません。

私はあなたとほぼ同じ.gitignoreファイルを持っているので、それはよさそうです。

私はここでMagentoストアを管理するためのチームとしてgitをどのように使用するかについて書きました、多分それはあなたに役立つでしょう：

Magentoデプロイメントのベストプラクティス

于 2011-06-09T20:58:12.780 に答える