2

現在、次のディレクトリレイアウトを持つRプロジェクトに取り組んでいます。

proj1
  |-file.r

file.rプロジェクト1に固有の統計モデルを構築するために使用されます（したがってproj1）。

開発の過程で、私たちは多くのプロジェクトのために多くのモデルを構築します：

仕事
  |-proj1
  | └--file.r
  |-proj2
  | └--file.r
  ：
  └--プロジェクト
        └--file.r

file.r各プロジェクト間で90％は類似していますが、違いがあります。私の質問は、マスターfile.rファイルを作成し、プロジェクトごとにそれをフォークする方法はありますか？そうすれば、マスターのバグ修正/拡張をフォークに簡単にリベースでき、ファイル固有の変更が上に適用されるだけです。私が最初に考えたのはサブモジュールを使用することでしたが、ここでそれをどのように適用するかはわかりません。ありがとう！

4

3 に答える 3

3

プロジェクトごとに「トピック ブランチ」を使用します。

git checkout master
git add file.r ;# this is your master template upon which others are based
git commit -m "Committed the master file"

次に、各プロジェクトについて:

git checkout -B <project> master ;# create and checkout <project> branch
<hack away on file.r, commit when you want>
git push origin <project> ;# to share <project> with others

したがって、実際にmasterは、project1、project2、project3などの基になっている が得られます。あなたが望むことを正確に行い、それをすべて正気に保つ必要があります。

複数のリポジトリを推奨する他のソリューションに対するこのソリューションの利点:

  1. 管理が容易になります。実際には最大で 20 ～ 30 のブランチを持つリポジトリが 1 つしかありません。たくさんのように聞こえますが、明確なラベルがあれば、特に小さなファイル セットしか管理していない場合は、自分がどこにいるかを簡単に知ることができます。
  2. あなたが怠け者なら（私のように）簡単な差分。2 つのプロジェクト間のファイルの違いはfile.r、git diff projectA projectB -- file.r. 複数のリポジトリで同じことを行うことができますが、git diff projectA/master projectB/master -- file.r. 20 ～ 30 個のプロジェクト リポジトリがあるか、サブモジュールを使用している場合、混乱する可能性があります。
  3. 簡単な更新。更新の取得はgit fetch origin、出力を発行して監視するのと同じくらい簡単です。
  4. 簡単なクローン。新しいローカル リポジトリをセットアップするときは、1 つのリモートを複製します。すべてを取得するまで、オリジン、次にgit remote add <project>リポジトリのクローンを作成する必要はありません。

短所 (不完全なリスト):

  1. この方法は、チェックアウトしたブランチに細心の注意を払うことに依存しています。ディレクトリ構造については何もわからないため、file.r特定の瞬間に何を見ているかがはっきりしない場合があります。それは契約を破る可能性があります。私は知らないよ。ワークフローによると思います。
  2. KurzedMetal がコメントで指摘しているように、すべてのプロジェクトを 1 つにマージする必要がある場合、これはすぐに面倒になる可能性があります。そのため、ソースコードにはお勧めしません。ただし、個別のRプロジェクトの場合、これはあまり問題にならない場合があります。
于 2012-07-06T16:58:04.960 に答える
3

IMOこれを達成するための最良の方法は次のとおりです。

  1. 共有コードのライブラリとリポジトリを作成する
  2. プロジェクトごとにリポジトリを作成する
  3. git submodule共有コードを各プロジェクトに統合するために使用します
  4. r ライブラリをインポートし、プロジェクト固有のコードを追加します。
于 2012-07-06T17:00:44.660 に答える