6

Commonスタンドアロンで使用でき、プロジェクトP1やで使用されるライブラリがあるとするとP2、必要なツリーは次のようになります。

/Common/.git
        ...
/P1/.git
    .gitmodules  # points to remote server
    Common/
    ...
/P2/.git
    .gitmodules  # points to remote server
    Common/
    ...

に変更を加えるときは、コミットする前にを使用し/Commonてテストできるようにしたいと思います。通常のコマンドセットでは、からコミットし、リモートにプッシュしてから、との両方からプルする必要があります。コミットが何かを壊した場合、悪い変更はすでに公開されているため、修正することはできません。または、リモートサーバーに触れずにプルできるようにすることもできます。しかし、これには矛盾の可能性がたくさんあり、壊れたコミットを削除してで修正できるようにするのは汚いです。P1P2git submodule/Common/P1/Common/P2/Commongit remote add quicktest /Common/P?/Common/P?/Common/Common

開発中は、作業ツリーをと/Commonで使用したいのですが、シンボリックリンクがディレクトリとは異なるものとして認識されるため、シンボリックリンクを作成できません。ディレクトリのハードリンクは、ほとんどのファイルシステムでは許可されていません。を使用してすべてのファイルをハードリンクできますP1P2/P1/Common/Commongit submodule

rm -rf /P1/Common
cp -rl /Common /P1/Common

これは、新しいファイルが追加されるまでは非常にうまく機能します。追加さ/Commonれた場合は、このプロセスを繰り返す必要があります。両方にエレガントな方法はありますか

  1. git clone --recursive git://remote/P1.gitエンドユーザーのために働き続け、そして
  2. との/Common作業の変化を簡単にテストできますか?P1P2
4

2 に答える 2

0

私はむしろ、どこに中間の裸のリポジトリを確立したいと思います:

  • Common新しいコミットをプッシュする
  • から引っ張っP1/CommonP2/Common

少なくとも、コミットが後で修正/削除された場合、その中間リポジトリは外部に公開されたことがなく、サブモジュールをその中間リポジトリコンテンツにリセットできP1/CommonますP2/Common


更新:を使用している場合はgit worktree、Git 2.5(2015年7月、この回答を書き込んでから5年後)以降、必ずGit 2.25(2020年第1四半期)を使用してください。
その前に、「 」はサブモジュールに影響を与えるgit worktree add「」を内部的に呼び出します。reset --hard

于 2010-12-06T14:21:59.250 に答える