Magento で Git を使用するためのベスト プラクティスは何ですか?

StackOverflow https://stackoverflow.com/questions/4564622

質問

私は、ベンダーのライブラリ (この場合は 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 subtree では、同じ中心的な前提 (ベンダー ブランチは、その名前が示すとおり、サブツリーであるという) が当てはまりません。Magento はサブツリーではなく、私のプロジェクトが収まるコア ライブラリです。あれは正しいですか？

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

私が追求したくない最後のオプションは、(tarball から取得した) 最新のベンダー変更に適用するだけのリポジトリを作成することです。ベンダーのログ情報 ( https://github.com/magentomirror/magento-mirror）は、新しいアップデートを分類し、どのような変更が私に影響を与えたかを把握するのに非常に役立ちます。

役に立ちましたか？

解決

これにはmodgitツールを使用できると思います。 https://github.com/jreinke/modgitModGitクローンコマンドを使用して、いくつかのMagentoモジュールをクローンすることができます。ここで完全な例をご覧ください： http://www.bubblecode.net/en/2012/02/06/install-magento-modules-with-modgit/

他のヒント

あなたが言及した方法のうち、本当に私のために働いた...

現在、私は使用しています 梨 コアモジュールとコミュニティモジュールのアップグレードをインストールおよび管理し、次の.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;

私が考えた別のアイデアは、ベンダー分岐モデルを試してみることですが、特にいくつかの大きな依存ツリーの場合、それは余分な頭痛を追加するのではないかと心配しています。ダウンロードされたモジュールは自動的に分岐する必要があるため、今のところ、有料拡張機能でのみ使用することは良いようです。

私はMagento Forumで主題を解雇しようとしましたが、返信もありませんでした。http://www.magentocommerce.com/boards/viewthread/78976/

アップデート：

Magento Composerインストーラー - 見る価値があります。

作曲 PHPの標準的な依存関係管理ツールになるため、プロジェクトでそれを利用してより多くの利点を得ることができます。

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

ありがとう。

あなたの質問は、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 を独自の phtml に置き換えます。いずれにせよ、デザインを適切にカスタマイズするには、大規模な変更作業とレイアウト作業が必要になります。

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

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

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

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

ここでMagentoストアを管理するためのチームとしてGitをどのように使用するかについての記事を作成しました。

Magentoの展開のためのベストプラクティス

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

これはまさに以前にキルトで行われていたことであり、あなたが今日やっていることです 積み重ねられたgit （gitの上）、 水銀キュー （HGの上）または 織機 （バザールの上）。

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

純粋なgit

以下は、Magento Git Repoをクローニングしていることを考慮してください。 Gitを使用していない場合でも、最初に履歴をGitに翻訳することで、たとえばで実行できます。 仕立て屋.

リベース

gitを使用すると、歴史の一部を別の出発点から簡単に再申請できます。 リベッシング. 。そのため、Magentoをクローンして、コードを動かし、Magentoを更新するときに、最後のクリーンMagentoの改訂からそれを行い、新しいClean Magentoの改訂にあなたの作品を再baseすることもできます。

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

枝

さらに別の方法は、単に枝を使用することです。 Magentoのリポジトリ、Branch from It、Do Your Choneをクローンし、Magentoの最新の改訂を取得すると、2つのブランチをマージします。それはただ 典型的なDVCSワークフロー, 、あなたをメインブランチに決して到達しない機能ブランチで作業するMagento DevelopPerと考えると…

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top