Gitサブモジュールの混乱:gitに慣れていない開発者と一緒にgitサブモジュールを使う方法は?

私は本当にgitのサブモジュール機能の使用について不満を持っています。私はまだそれを正しくしないか、または私がこれを期待しているようにちょうど動作しません。以下のプロジェクト状況が与えられる:

Project
  | .git
  | projsrc
  | source (submodule)
  | proj.sln

このシナリオでは、ソースは、すべてのプロジェクト全体の共通ソースデータを含む別のリポジトリを指しています。 source の下で projsrc の下にも多くの開発が行われています。残念ながら、プロジェクトは、ソースサブモジュールのコミットを指し、実際のHEADではありません。これは私が知っている限り、通常のgitの動作です。

私はすでにそれを知った

git submodule update

メインプロジェクトと一緒にコミットされたサブモジュールのバージョンを取得するだけです。しかし、私は実際にサブモジュールの開発に関して常に最新のものにしたいと思っていますが、これをどうやって行うのか本当の手がかりはありません。したがって、私の質問は:

サブモジュールのHEADに[プロジェクト]を添付することは可能ですか? これがProjectのコンパイルを破るかどうかは事実ではない。 私はちょうどサブモジュールに常に行きたいとは思わない git pull してください。私は私の変更が緩んだと思うので サブモジュールディレクトリには、これは単純な コミットして本当にどんなブランチにもそうではありません。

Please consider following constraints:

  • グループ内の開発者は、すべてのVCSに精通しているわけではありません。私たちは以前には本当に巨大なsvnリポジトリを使用していましたが、外部repo機能は一切使用していませんでした。
  • Windowsで作業しています
  • プロジェクトメンバーのほとんどがコマンドラインインターフェイスを使用して怖がっているので、クリックしないでください:
6
「サブモジュールディレクトリで行った変更を緩和することができます。これはコミットに単純なものであり、実際にはどのブランチにも属していないからです。常に枝があります。あなたは頭が孤立しているときにあなたがコミットするまであなたの変更を失うことはありません。
追加された 著者 Vanuan,

3 答え

サブモジュールが特定のリビジョンを指す理由は重要です。 HEADをポイントすると、ビルドは再現不可能になります。私。もしあなたが昨日のプロジェクトのバージョンをチェックアウトすれば、昨日のソース@ HEADの正確なバージョンは分かりません。

そのため、常に特定のリビジョンを保存しています。

To pull all submodules you could use Easy way pull latest of all submodules

7
追加された
あなたはまだソースにcdして、チェックアウトヘッドを行うことができます。さらに、ソースに変更をコミットする場合、ソースを変更する必要があります。 projsrcにネストされた単純なgitリポジトリとしてsourceを考慮する必要があります。それはサブモジュールが本当に何であるかです。唯一の違いは、projsrcにソースサブモジュールの起源と特定のコミットに関する情報があることです。共通ソースを常に他のプロジェクトと同じバージョンにしたい場合は、すべてのプロジェクトを共通の同じレポに配置する必要があります。
追加された 著者 Vanuan,
submodule update は変更を削除しません。わかっているように、参照されたリビジョンをチェックアウトするだけです。作成された変更は依然としてrepoであり、チェックアウトした後、プロジェクトを更新してリビジョンを参照し、サブモジュールリビジョン参照をメインプロジェクトにコミットします。
追加された 著者 kan,
変更がコミットされない場合、 submodule update は何も変更しません(少なくとも私のPC上ではそうです)。変更がコミットされた場合、それらは失われません、あなたはチェックアウトすることもできますそれはあなたが他の何かをチェックアウト。さらに、あなたは submodule update を呼び出していますか?
追加された 著者 kan,
私は彼らが壊れることに完全に同意する、しかし私はその状況で大丈夫です。サブモジュールソースが期待通りに機能しないというプロジェクトで協力している、gitに慣れていない開発者を説明するのは面倒です。彼らはいつもそこでの変更に基づいてソースをコミット/プッシュしています。さらに重要なのは、プロジェクトで git submodule update を行うだけで、その特定のリビジョンで上書きされるため、ソースに対するすべての変更が緩和されることです。
追加された 著者 cgart,
あなたがコミットしておらず、まだプッシュしていない場合(親の変更をプッシュしていない場合)、変更を削除してください。ソース/は分離されたHEAD(デフォルトの動作)を持つサブモジュールであるため、gitサブモジュールの更新は常にソース/ディレクトリを親リポジトリが指し示す状態にします。これは、私のローカルでの変更が上書きされることを私に通知することもないので、これは私の目ではgitの非常に悪い動作です(git 1.7.7)
追加された 著者 cgart,

私はGitとサブモジュールがうまくいかない。しかし、私はいくつかの簡単なルールは非常に役に立つと思う。

  1. サブディレクトリからコミットしてプッシュします。
  2. プロジェクトのルートに戻り、コミットして再度押す必要がある場合はステータスを確認します。

いつプル。スクリプトを使用して、 "プル/サブモジュール更新"をバンドルすることができます。そして、あなたのプロジェクトのルートでそれを行うだけです。

2
追加された

このことを考慮:

  1. ソースがHEADを指しています(必要に応じて)。
  2. プロジェクト内のソースを変更します(コミットしますが、プッシュしません)。
  3. 2つのHEADがあります:1つはプロジェクトのソースに、もう1つは共通ソースにあります。

サブモジュールの更新を行うときに、あなたはあなたのプロジェクトに存在したいでしょうか?

あなたの場合のgitの問題(と主な機能)は、コミットとアトミック操作としてのプッシュを考慮することです。そうではありません。 Gitは分散されています。共通のHEADはありません。異なるHEADを持つ複数のリポジトリがあるかもしれません。

このことを考慮:

  1. gitプロジェクトで3人の開発者(A、B、C)がいます。
  2. プロジェクトのHEADをすべて引き出します。
  3. 各開発者がプロ​​ジェクトに変更を加えました
  4. それぞれに3つの見出し:A HEAD、B HEAD、およびC HEADがあります。

あなたは「真の」HEADとみなすHEADはどれですか?

したがって、あなたの質問に答える:共通ソースサブモジュールを常に中央リポジトリと同期させたい場合、gitはあなたの選択ではありません。おそらくVCSのどれもそれを手伝ってくれるものではありません。

gitサブモジュールを第三者のライブラリとして扱う必要があります。これらのライブラリは、次の2つの手順で手動で更新する必要があります。

  1. サブモジュールを引き出します(「thirdpartyライブラリをダウンロードする」)
  2. 更新されたサブモジュールでプロジェクトをコミットする(「第三者のライブラリの新しいバージョンをプロジェクトに追加する」)

サブモジュールを変更したい場合は、逆の順序で同じ作業を行う必要があります:

  1. サブモジュールをコミットする(「第三者のライブラリに変更を加える」)
  2. サブモジュールをプッシュする(「第三者の図書館管理者に変更を送信する」)
  3. 更新されたサブモジュールでプロジェクトをコミットする(「第三者のライブラリの新しいバージョンをプロジェクトに追加する」)
2
追加された
説明するのを恐れないでください。 Gitは、分散バージョン管理が可能なほど簡単です。あなたの共同開発者が理解しなければならないことの1つは、git repoの各コピーが自己完結型のローカル "svn-server"であることです。 "サーバ"間の同期化の必要性は、gitでいくつかのことができない理由です。
追加された 著者 Vanuan,
Vanuanに感謝します。はい、私はgitのアイデアを知っています。あなたは正しいかもしれませんが、正しい選択ではないかもしれません。問題は、これまでgitが以前に使用されていたsvnと比べて実際に何をしているのかを理解するのは非常に長い時間がかかりました。私はすでにこれを私の共同開発者に説明することを本当に恐れています...しかし、私はgitを使ってワークフローをすでに見つけたと思います。
追加された 著者 cgart,