3

私は git プロジェクト P を持っています。私のプロジェクト P 内には、サードパーティ ライブラリのマスター ブランチから複製されたサブモジュール Q があります。

P
|
 - src
 - Vendor
    |
     - Q

サードパーティ ライブラリのリモート リポジトリに変更をプッシュする権限がありません。

私はいくつかの修正を行いましたが、それらをプロジェクトのブランチにQプッシュして、チーム メンバーもそれらを使用できるようにしたいと考えています。現在、' ' ブランチ で開発中です。masterP
dev

内から次の手順を試しましたP。

  1. cd Vendor/Q
  2. git branch my-fixes
  3. git checkout my-fixes
  4. 修正する
  5. git add
  6. git commit -m 'My fixes to 3rd Party Library Q'
  7. cd ../..
  8. git add Vendor/Q
  9. git commit -m 'Changes/fixes made to submodule Q'
  10. git push

しかし、これは私の問題を解決していないようです。誰かが私を助けることができますか？

4

3 に答える 3

1

サブモジュールを使用する代わりにgit-subtreeがあります (サブツリーのマージ戦略と混同しないでください)。サブモジュールに対する主な利点は、Q への変更をベンダーに戻す機能を保持しながら、Q が P の履歴とリポジトリの一部になることです。また、Q がどこから来たのか気にしないユーザーは、git-subtree をインストールする必要さえありません。

git-subtree はコア git の一部ではありませんが、最近メインの git ディストリビューションにマージされたため、半公式になっています。

于 2012-09-07T06:12:23.677 に答える
1

2 つのリポジトリ (Q とプロジェクト) を統合することを考えると、修正を GitHub Q リポジトリに戻す必要はありません (Q は GitHub で更新されなくなったため)。

  • サブツリーは2つのリポジトリを一緒にマージします
  • 修正を行います
  • 開発者が使用できるように、プロジェクト (Q を含む) をプッシュ バックします。
于 2012-09-07T05:58:45.753 に答える
1

プロジェクト P をプッシュすると、サード パーティ ライブラリのリモート リポジトリに変更をプッシュする権限がないため、誰もステップ 6 からコミットを取得できなくなります。

サブモジュールをサードパーティのリモートに登録する代わりに、Q に対する会社の変更を保存するリポジトリを作成することを検討しましたか? Q への変更を会社のサーバーに保存できるようにします。

于 2012-09-07T03:51:25.077 に答える