私のプロジェクトでは、いくつかのGitリポジトリに格納されているサードパーティのコードを使用する必要があります。私のプロジェクトはGitリポジトリにも格納されています。メインプロジェクトには私と一緒に働いている人がいて、私はメンテナーです。Git submodules workflow
以前のプロジェクトでは、Gitワーキングツリーに依存関係を手動でコピーして、私が使用しているバージョンを指定した小さなファイルを追加していました。
毎日の依存関係を更新する必要があり、ほとんどの場合、主なプロジェクトの変更に伴うコードを自分自身に寄付する必要があるので、これはむしろ不快です。
私は管理を行うためにGitサブモジュールを試してみることにしました。私がそれらを試してみるほど、私はもっと不満を感じます。マニュアルコピーは、おそらく、より良いと思われる。我々は(git checkout
が今git submodule update --init
を必要とする)は、もはや単一のコマンドで一貫性のあるリポジトリの状態を取得することができます
- :ここ
は私の懸念のいくつかではありません。
- Gitツールを正しく使用することができません(
git archive
が最も顕著です)。 - ステータス変更/差分をメインプロジェクトからサブモジュールに表示することはできません。
- ちょうど難しい方法で見つかったように、
git submodule
は--git-dir
と--work-tree
オプションでは機能せず、カレントディレクトリを「作業ツリーのトップレベル」に物理的に変更する必要があります。
私たちのサブモジュールワークフロー(1つの操作== 1つのコマンド)を合理化するために、Gitの周りにかなり厚いラッパーを書く必要があるようです。これは悲しいことだ。
Gitから離れたり、メインプロジェクトにサブプロジェクトの開発を完全にマージすることはできません。
おそらく私はgit submodules
を間違った方法で使用していますか?ワークフローに関する良いチュートリアルはありますか?
あなたが適切な答えを知らなくても、私の懸念を分かち合ってください。 :-)
一つあなたがサブモジュールを削除し、同じ場所に新しいサブモジュールと交換した場合、それは皆のためのリポジトリを壊すです。 (例えば、誰かがgithub上のライブラリをフォークし、代わりにフォークを指すようにサブモジュールを切り替えます)。回避策は、サブモジュールを削除し、誰もがプルして更新してから、サブモジュールを置き換えて、 –
私は誰かがこの投稿を盗んだと思って、参照なしにhabrに公開したと思っていましたが、私はその名前を見ました... :-D まだ、SOへの参照はいいと思います。 –
1つあります。テキスト内のリンクを詳しく見てください。 –