5

外部ライブラリ/ヘッダーと qa を git で管理するプロジェクトに取り組んでいます。すべての開発者のディレクトリ構造は次のようになります。

~/dev/proj 
~/dev/ext 
~/dev/qa

proj、ext、qa は異なるgit リポジトリです。svn では、これらのディレクトリの同期は簡単でした: ~/dev の下での単一の更新は、それらすべてを再帰的に更新します。git では、ディレクトリごとに個別に 'git pull' を実行する必要があります。これは良くありません。誰かが常にこれらのディレクトリの 1 つを更新 (git pull) するのを忘れると、そのプロジェクトは同期しなくなります (たとえば、新しい qa は古いコードでは通用しません)。「git submodules」を調べましたが、「git pull」がこれら 3 つの個別のモジュールを同時に更新するための単一のポイントを提供していません [訂正: ここで間違っていましたが、以下の私の回答を読んでください] .

proj、ext、qa を同じ git リポジトリに置くべきだったと主張する人もいるかもしれませんが、それは異なる概念を異なるリポジトリに保持するという git の哲学に反すると思いました。

この些細な問題に対する解決策はありますか ( ~/dev の下のすべてのディレクトリで git pull を実行するスクリプトを作成する以外に) ?

ありがとう、

アルタン

4

9 に答える 9

4

私の哲学は次のとおりです。常に X と Y をまとめる必要がある場合、論理的にはそれらは同じリポジトリに属します。サブモジュールを使用することは、適切な分離がある場合にのみ意味があります。外部ベンダーのライブラリを考えてみてください。更新を勝手に持ち込まれたくない場合や、チームがそれらを直接編集できるようにしたくない場合などです。これは理にかなっています。それでも、どのようにスライスしてもステップが追加されます。理論的にどのように分割してより「gitライク」にするかに関係なく、「1つのプロジェクトであれば1つのリポジトリに入れる」ことに固執します。

于 2012-10-03T01:02:16.100 に答える
3

Herr Doktor、

あなたはリンゴとオレンジを比較しています。git-submodulesは、 svn：externals、別名svn-submodulesに似ています。実際、を使用し-rて特定のリビジョンでsvnサブモジュールをアタッチする場合、動作はほぼ同じです。svn-submodulesでコミットするには、git-submodulesの場合と同様に、各サブモジュールディレクトリで個別にコミットする必要があります。

ただし、大きな違いがあります。ほとんどの開発者は、少なくとも開発のある段階では、git-submodulesでサポートされていない各サブモジュールのブランチに接続することを好みます。これは、調整された開発に役立ちます。（GoogleのRepoツールはGitのラッパーであり、コードレビューツールであるGerritで使用するためのものですが、私を信じてください：Repoに近づかないでください。別の問題を解決します。）大きな欠点は、回復できないことです。コードベースの正確な輪郭。それはしばらくの間は問題ないようですが、私は厄介な戦争の話を聞いたことがあります。

代わりの方法はSubversionではなく、Git、Subversionなどにある単一のリポジトリです。しかし、実際には、単一のリポジトリと複数のリポジトリの組み合わせが必要ですよね？それぞれのメリットが必要です。したがって、より洗練されたソリューションが必要です。

1つのアイデアは、開発の大部分を行う1つのプロジェクトリポジトリと、モジュールを配布するいくつかの個別のリポジトリを用意することです。

proj/.git
proj/subA
proj/subB
subA/.git
subB/.git

rsyncを使用してそれらの間でコードを移動できます。美しさは、開発と配布を明確に区別したことです。ブランチやマージなどを使用して、通常どおり大規模なプロジェクトを開発します。サブディレクトリをライブラリとして配布する準備ができたら、必要なライブラリのバージョンを正確に決定し、それを独自のリポジトリにコピーします。単にコピーするのではなくマージする必要がある場合は、gitサブツリーマージ戦略があります。

サブツリーマージ戦略の上に構築された別のシステムがあります。これはgit-subtreesと呼ばれ、 git-1.7.11の一部です。これがその動作の良い説明です。写真から、そのタイムラインが混乱しているように見えることがわかりますが、機能的にはまさにあなたが望むものです。これが最近の記事で、優れたアドバイスがあります。

git-submodulesの余分な「更新」ステップを気にしないが、競合の処理方法に腹を立てている場合は、giternalを試すことができます。作成者は、その動作がgit-submodulesおよびbraid（サブモジュールを販売するためのものですが、それらをマージするためのものではありません）とどのように比較されるかを示すスクリプトを含めました。

個人的には、gitの単純なラッパーであるgit-slaveが好きです。基本的に、コマンドをすべてのリポジトリにgitsコマンドとして適用します。gitそれは本当に便利です。非常に理解しやすく、個々のリポジトリに影響を与えることはなく、ブランチの切り替えに最適です（git-subtreesではまだサポートされていません）。

于 2012-10-04T05:40:34.213 に答える
2

「git submodule」を試しましたが、満足のいくものではありません。git submodule は、あまり変更されないモジュール用に設計されているようです。モジュールに変更を加えてプッシュする手順は次のとおりです。

cd ~/dev/proj
git checkout master
git pull
... make changes to your files ...
git commit -a -m "comment"
git push
cd ..   
git commit -a -m "comment"
git push

そして、これを ~/dev の下のモジュールごとに繰り返す必要があります。すみませんが、これはばかげていると思います。svn では、同じことが次の方法で実現されます。

cd ~/dev
svn commit -m "done in one line"

svn に対する git の利点は理解していますが、適切なサブモジュールのサポートがなく、適切な大きなファイルのサポートがないため、おそらく git から svn に切り替える必要があります (ここで解決策が得られない限り --- 私はむしろ git を使用したいと思います)。 . 正直なところ、これが git でまったく発生していないことに驚いています。さまざまなプロジェクトが [ライブの] 共通のモジュールを常に共有しています。

proj、ext、qa を同じリポジトリに置くことに反対します。

  • ext は他のプロジェクト (リポジトリ) と共有されます
  • qa はコードなしでチェックアウト (複製) できる必要があります

アルタン

于 2012-10-03T19:40:48.957 に答える
2

サブモジュールは引き続き使用できます。

git submodule update

すべてのサブモジュールを一度に更新します。

于 2012-10-03T01:01:30.510 に答える
1

git-レポを使用する

https://github.com/android/tools_repo http://source.android.com/source/using-repo.html

Android 開発者は、複数のリポジトリの管理に使用します

見る

https://github.com/android/tools_repo/blob/master/docs/manifest_xml.txt

および Android リポジトリ マニフェスト リポジトリ

https://android.googlesource.com/platform/manifest/+/master

于 2014-03-13T18:39:04.233 に答える
1

git-multi が答えです。https://github.com/grahamc/git-multi

git-multi をセットアップし、「~/dev」フォルダーの下に必要なすべてのリポジトリーを複製します。

「~/dev」から「git multi pull」または「git multi status」などのコマンドを実行すると、インターンはすべての子リポジトリで対応するコマンドを実行します。

于 2014-07-07T18:14:08.730 に答える
-1

私見、サブモジュールはここに行く方法です。

X と Y を常に一緒にする必要があるかどうかを尋ねる代わりに、X と Y のまったく同じバージョンを常に一緒にする必要があるかどうかを自問する必要があります。

Git サブモジュールは、Y を更新することなく、X のバグをすばやく修正するための非常に強力なツールを提供します。

たとえば、異なるオペレーティング システム (たとえば、Mac OS X と Windows など) で動作する製品を開発している場合、オペレーティング システム固有のコードを別のサブモジュールに分割することは理にかなっています。これは、さまざまな人がこれらのさまざまなオペレーティング システム ポートで作業している場合に特に当てはまります。git サブモジュールを使用すると、他の OS で QA プロセスを実行する必要なく、1 つのオペレーティング システムの修正を顧客に簡単に展開できます。

もう 1 つの非常に強力な使用例は、「ワークスペース」モジュールです。単純にローカル モジュール (たとえば/Workspace) を作成し、作業中のすべての依存関係を追加します。

git サブモジュールの優れた点は、使用するモジュールだけでなく、特定のリビジョンも記録することです。バグを修正している間、いくつかの依存関係の特定のバージョンをテストする必要があることがよくあります。git サブモジュールを使用すると、これらをワークスペース モジュールの履歴に簡単に記録でき、後で正確な状態に簡単に戻すことができます。

于 2012-10-03T05:30:26.127 に答える