web-dev-qa-db-ja.com

gitサブモジュールとの競合を管理するにはどうすればよいですか？

いくつかのサブモジュールを参照するgitスーパープロジェクトがあり、残りのプロジェクトメンバーが作業できるようにワークフローをロックダウンしようとしています。

この質問では、私のスーパープロジェクトはsuperyと呼ばれ、サブモジュールはsubbyと呼ばれます。 （それから私がやろうとしていることの単純化です...私は実際にバージョンにブランチを使用していませんが、質問としてレイアウトするのが最も簡単だと思いました。）

superyのマスターブランチには、サブプロジェクトとして参照されるgitプロジェクトsubbyのタグv1.0があります。 superyのブランチはone.oneを呼び出し、サブモジュールの参照を変更して、subbyのタグv1.1を指すようにしました。

支障なくこれらの各ブランチ内で作業できますが、masterブランチからの変更でone.oneブランチを更新しようとすると、いくつかの競合が発生し、それらを解決する方法はありません。

基本的に、subbyブランチでgit pull . masterを実行した後、追加のサブモジュールが作成されるようです。

プル/マージの前に、git submoduleブランチからone.oneから目的の応答を取得します。

$ git checkout master
$ git submodule
qw3rty...321e subby (v1.0)
$ git checkout one.one
$ git submodule
asdfgh...456d subby (v1.1)

しかし、プルの後、git submoduleを実行すると、追加のサブモジュールが追加されます。

$ git pull . master
Auto-merged schema
CONFLICT (submodule): Merge conflict in subby - needs qu3rty...321e
Automatic merge failed; fix conflicts and then commit the results.

$ git submodule
qw3rty...321e subby (v1.0)
asdfgh...456d subby (v1.1)
zxcvbn...7890 subby (v1.1~1)

不要なサブモジュール参照を削除/無視し、競合と変更をコミットするにはどうすればよいですか？または、サブモジュールを無視する元のgit pullで使用できるパラメーターはありますか？

gitbranchgit-submodulesconflict
106
Tyler

私はその正確なエラーを見たことがありません。しかし、私はあなたが直面しているトラブルについて推測しています。 masterの変更をマージすると、superyのsubbyおよびone.oneブランチにmasterサブモジュールの異なる参照が含まれているため、 v1.0またはv1.1のどのrefを保持し、superyのone.oneブランチで追跡する必要があるかはわかりません。

その場合は、必要なrefを選択し、その変更をコミットして競合を解決する必要があります。 resetコマンドを使用して、まさにこれを実行しています。

これは、プロジェクトのさまざまなブランチにあるサブモジュールのさまざまなバージョンを追跡する際の注意が必要です。ただし、サブモジュールrefは、プロジェクトの他のコンポーネントとまったく同じです。 2つの異なるブランチが連続したマージ後に同じそれぞれのサブモジュールrefを追跡し続ける場合、gitは将来のマージでマージの競合を引き起こすことなくパターンを解決できるはずです。一方、サブモジュールrefを頻繁に切り替える場合は、多くの競合解決に耐えなければならない場合があります。

19
Jesse Hallett

さて、サブモジュールとの競合を技術的に管理していません（つまり、これを維持しますが、そうではありません）が、私は作業を続ける方法を見つけました...そして、私がしなければならなかったことは私のgit statusサブモジュールを出力してリセットします。

git reset HEAD subby
git commit

これは、サブモジュールをプリプルコミットにリセットします。この場合、まさに私が望んでいたものです。また、サブモジュールに変更を適用する必要がある他のケースでは、標準のサブモジュールワークフロー（チェックアウトマスター、目的のタグのプルダウンなど）でそれらを処理します。

75
Tyler

私はこの質問の答えに少し苦労し、 同様のSO post のいずれかの答えにもあまり運がありませんでした。 -私の場合、サブモジュールは別のチームによって維持されていたため、マスターとプロジェクトの私のローカルブランチの異なるサブモジュールバージョンから競合が発生したことに注意してください。

  1. 実行git status-競合するサブモジュールフォルダーを書き留めます

  2. サブモジュールを現在のブランチで最後にコミットされたバージョンにリセットします。

    git reset HEAD path/to/submodule

  3. この時点で、サブモジュールの競合のないバージョンがあり、サブモジュールのリポジトリで最新バージョンに更新できます。

    cd path/to/submodule 
 git submodule foreach git pull Origin SUBMODULE-BRANCH-NAME

  4. そして今、あなたはそれをcommitして仕事に戻ることができます。

44
Emma Burrows

最初に、参照するサブモジュールに必要なハッシュを見つけます。その後、実行します

~/supery/subby $ git co hashpointerhere
~/supery/subby $ cd ../
~/supery $ git add subby
~/supery $ git commit -m 'updated subby reference'

それは私のサブモジュールを正しいハッシュ参照に導き、それ以上競合することなく私の仕事を続けるために私のために働いた。

15
hellatan

ブランチへのgit rebase -i Origin/masterでこの問題が発生しました。私はマスターのバージョンのサブモジュールrefを取得したかったので、次のようにしました。

git reset master path/to/submodule

その後

git rebase --continue

これで問題は解決しました。

10
marathon

この議論から助けを得ました。私の場合

git reset HEAD subby
git commit

私のために働いた:)

3
Mithun Das

私の親ディレクトリには次のように表示されます：

$ git status
On branch master
Your branch is up-to-date with 'Origin/master'.
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)

だから私はこれをやった

git reset HEAD linux
1
Kjeld Flarup