2

私は多くのサブレポを持っています。つまり、小さなレポを持つ 1 つの大きな傘レポです。これで、リーフ リポジトリでコミットを行うと、自動的にその親に変更が加えられたことを意味します。構造をバイナリ ツリーと仮定すると、ばかげていることに気付くかもしれません。5 つの git-repo の深い構造を持つことは、簡単に$ git commit -m 'did 1'; cd ..; git commit -m 'did 1 as mentioned'; ... git commit -m 'did 1 same as earlier'. この種の繰り返しのコミットを避けるにはどうすればよいですか?

例 1: 問題に関するグラフィカルな例

X---------|
          |
Y---------A --------|
                    |
          B --------|<-----Pictures (graphic designers, animators--have repo)
                    |
          C --------|

Pictures の変更は、A、B、C、X、Y を変更します -- 肥大化したコミット、1 つの変更による 6 つのコミット、悪い繰り返し! 現在、ピクチャを使用する人々は、X、Y、A、B、および C を使用して作業を行う人々とはまったく異なる可能性があり、物事がより曖昧になります。

例 2: ハンズオン -sub-sub... -repos で試す例

この実践的な例をここにコピーしてください。3 レベルの -sub-repos を使用してそこでテストできます。

これまでのところ

  1. Git の基本的なサブモジュール。詳細はこちら.

  2. ここでGitslave 。

4

3 に答える 3

1

リポジトリ内にリポジトリを作成しないでください。これにより、コミットの繰り返しが回避されます。おそらく他の問題も解決します。

リポジトリ内にリポジトリが必要だと本当に思っている場合は、サブモジュールを使用してください。

于 2012-04-09T03:24:09.793 に答える
0

リポジトリ内のファイルには、他のリポジトリ内の他のファイルに関連する変更が伴うことがよくありますか? もしそうなら、複数のリポジトリはあなたの友達ではありません。複数のリポジトリは、互いに完全に (またはほぼ完全に) 独立している場合にのみ使用してください。

一方、それらが完全に独立している場合は、別々のリポジトリを使用できます。次に、各リポジトリのファイルを使用する可能性がある (つまり、他のリポジトリに依存する) ある種のマスター プロジェクトを構築するには、サブモジュールを使用します。

別のリポジトリのサブモジュールであるリポジトリは、そのサブモジュールに依存することを意味します。サブモジュール間の依存関係リンクは、API が安定していない場合はおそらく悪い考えですが、API が安定しているため、一方の変更が他方に直接影響を与えない場合 (つまり、コードの変更は必要ありません)、2 つのトップレベルのサブモジュールを使用できます。お互いに依存します。

さて、私はずっとサブモジュールについて話してきましたが、あなたが好むものをチェックアウトしたい場合は、「サブツリー」と呼ばれる代替手段が存在します。メインの git リポジトリの contrib/ セクションにあるため、デフォルトではインストールされません。サブツリー戦略も存在します（コメントでリンクされているProGitの章）

于 2012-08-19T17:02:04.587 に答える
0

おそらく GoZoner のコマンドの背後にある前提として、設計または構造が貧弱で"Don't create repositories within repositories."ある可能性がありますが、プロジェクトがより強力なツールを必要とする段階に達している可能性もあります。基本的なサブモジュールでは不十分で、リポジトリが広すぎる場合があります。その場合は、GitSlave! を参照する必要があります。これは、スーパー リポジトリを指定してからスレーブ リポジトリを指定するワークフロー ツールです。繰り返しコミットする代わりに、gits -command --manual here を使用します。

関連スレッド

于 2012-08-19T16:45:59.070 に答える