17

rails_appfoo/とbar/(正当な理由で別々に) の 2 つがあります。どちらもフォルダー内のいくつかのモデルなどに依存しており、現在はおよび とcommon/並行しています。foobar

現在の svn セットアップではsvn:externals、共有に使用されますcommon/。今週末、私たちは git を試してみました。多くの調査の結果、これを解決するための「コーシャ」の方法は を使用しているようgit submoduleです。foo、bar、commonを別々のリポジトリに分離した後、それが機能するようになりましたが、すべての文字列が添付されていることに気付きました:

  1. 親をコミットする前に、必ずサブモジュールをコミットしてください。
  2. 親をプッシュする前に、必ずサブモジュールをプッシュしてください。
  3. コミットする前に、サブモジュールの HEAD がブランチを指していることを確認してください。(bash ユーザーの場合は、git-completion を使用して現在のブランチ名をプロンプトに入力することをお勧めします。)
  4. ブランチを切り替えたり、変更をプルしたりした後は、常に「git submodule update」を実行してください。

これらすべての落とし穴は、、、よりもさらに複雑addにcommitなりpushます。commongitで共有するためのより簡単な方法を探しています。この男は拡張機能を使用して成功しているようですgit subtreeが、それは標準の git から逸脱しており、まだそれほど単純には見えません。

プロジェクト構造を考えると、これが私たちにできる最善のことですか? Rails プラグイン/エンジンについてはよくわかりませんが、ライブラリを共有する RoR っぽい方法のように思えます。

前もって感謝します。

4

7 に答える 7

8

git サブモジュール システムには、svn:externals またはシンボリック リンクよりも大きな利点があると思います (また、それが使用をより困難にします): 実際のサブモジュールのバージョンは、スーパープロジェクトのバージョンごとに保存されます。したがって、下位互換性を破るサブモジュールに変更を加えるのは非常に安全です。スーパープロジェクトには適切なサブモジュールコードへの参照が含まれるため、適切なサブモジュールバージョンでスーパープロジェクトの任意のバージョンをチェックアウトできます。サブモジュールの 2 つのブランチ (たとえば、v1.0.x と v2.0.x) を維持し、異なるプロジェクトで異なるブランチを問題なく使用することもできます。

したがって、多少複雑であってもサブモジュールを使用する価値はあると思います。Git 1.7 では、この分野でいくつかの主要な改善が行われgit statusています。優れた GUI も役立つかもしれません (私はこれに関する小さなペット プロジェクトを持っています。こちらを参照してください)。

サブモジュールのバージョンを本当に気にしたくない場合 (共通コードに下位互換性のない変更を加えない場合) は、シンボリック リンクを使用することもお勧めします。コミットとフェッチは、サブモジュールよりもはるかに簡単ではありませんが...

于 2010-05-29T10:35:39.853 に答える
6

サブモジュールへのシンボリック リンクを好む傾向があります。

1) foo、bar、および共通コード ( common) を 3 つの別々のリポジトリに持つ。

2) のディレクトリにfoo、必要に応じて へのシンボリック リンクを追加しcommonます。

$ cd フー
$ ln -s /path/to/common lib/common

3) リンクをチェックインします。

$ git add lib/common
$ git コミット

4) 繰り返しますbar

これは、git がシンボリック リンクを尊重し、(リンクをたどるのではなく) ターゲットの場所を保存するという事実を利用しています。

もちろん、 に対して一貫して同じターゲット パスを使用することが期待されますcommon。私はシンボリックリンクをチェックインせず、各プロジェクトに README.setup ファイルを追加して、初期化時に必要なシンボリックリンクを追加するように促すことで、この問題を回避しています。この種の初期化を行うdevsetup.shがあると、ここでも役立ちます。

IMO、これはサブモジュールよりもはるかに扱いやすいです。

于 2010-04-20T06:06:49.720 に答える
5

プラグインは完全に道のりであり、2つ以上のプロジェクトでプラグインを使用することになった場合、または一般の人々に役立つ場合は、プラグインを宝石にするために努力する価値があります。

これは、このテーマに関する優れたリソースです。

http://nubyonrails.com/articles/the-complete-guide-to-rails-plugins-part-i

そして更に重要なことに ...

http://nubyonrails.com/articles/the-complete-guide-to-rails-plugins-part-ii

最終的に、3つのgitリポジトリがあります。1つはfoo用、1つはbar用、もう1つはプラグイン用です。

次に、各プロジェクトでデータを維持するために、次のことができるようになります。

./script/plugin install --force git://github.com/path/to/plugin/repository

それを最新の状態に保つために。

幸運を！

-ジョナサン

于 2010-04-19T21:08:43.307 に答える
2

Git サブツリーは 1.7.11 以降の GIT の一部であり、Rails アプリケーション間でのコード共有に関する記事を書きました: http://igor-alexandrov.github.com/blog/2013/03/28/using-git-subtree-to -share-code-before-rails-applications

要するに: はい git-subtree は機能し、うまく機能します!

于 2013-03-28T12:07:44.093 に答える
1

プラグインの作成を検討している場合は、gem の作成も検討する必要があります。使い方は非常に似ていますが、gem の方が操作が簡単で、依存関係の管理がサポートされており、コミュニティとの共有や配布が簡単です。

Railscastの Ryan Bates が、gem の作成に関する素晴らしいチュートリアル ビデオを公開しています。

于 2010-06-19T21:35:43.663 に答える
0

共通コードでリポジトリを作成し、それを 2 回複製できます。両方のクローンが foo と bar になります。両方のプロジェクトの別々のブランチで共通コードを開発し、そのブランチを共通コード リポジトリにプッシュすることもできます。プロジェクトの共通コードを更新するには、共通ブランチを foo と bar のマスター ブランチにマージするだけです。

更新: これは、common、foo、bar の 3 つのブランチを持つ単一のリポジトリと考えることができます。common ブランチに共通コードを配置し、プロジェクト固有のコードを foo または bar ブランチにのみ追加します。これで、このリポジトリを foo と bar として 2 回複製し、両方から 1 つのブランチを削除できます (bar リポジトリから foo をブランチし、foo リポジトリから bar をブランチします)。次に、最初のリポジトリから foo と bar の両方を削除します。これが共通リポジトリになります。最終的な結果は上記と同じになります。

于 2010-04-19T19:16:12.297 に答える
0

あなたができる最善のことは、あなたの共通ライブラリ、または宝石のためのプラグインを作成することです。そうすれば、それを更新/配布するための良い方法になります.

于 2010-06-19T11:02:00.163 に答える