git サブモジュールとの競合を管理するにはどうすればよいですか?
-
05-07-2019 - |
質問
いくつかのサブモジュールを参照する git スーパープロジェクトがあり、残りのプロジェクト メンバーがその中で作業できるようにワークフローをロックダウンしようとしています。
この質問では、私のスーパープロジェクトが次の名前であるとします。 supery
そしてサブモジュールは呼び出されます subby
. 。(これは私がやろうとしていることの簡略化です...実際にはバージョンのブランチを使用していませんが、質問としてレイアウトするのが最も簡単だと思いました。)
私のマスターブランチ supery
タグが付いています v1.0
git プロジェクトの subby
サブモジュールとして参照されます。の支店 supery
呼ばれた one.one
サブモジュールの参照をタグを指すように変更しました v1.1
の subby
.
これらの各ブランチ内では問題なく作業できますが、 one.one
からの変更を含むブランチ master
ブランチ いくつかの競合が発生しましたが、解決方法がわかりません。
基本的に、実行した後、 git pull . master
中にいる間 subby
ブランチを開くと、追加のサブモジュールが作成されるようです。
プル/マージの前に、次から目的の応答を受け取ります。 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
それは私のサブモジュールを無視しますか?
解決
その正確なエラーは以前見たことがありません。しかし、私はあなたが直面しているトラブルについて推測しています。 supery
の master
および one.one
ブランチには、 subby
サブモジュールの異なる参照が含まれているため、 master
からの変更をマージする場合、gitは v1.0
または v1.1
のどちらの参照を保持し、 >
supery
のブランチ。
その場合は、必要なrefを選択し、その変更をコミットして競合を解決する必要があります。これは、まさに reset コマンドで行っていることです。
これは、プロジェクトのさまざまなブランチにあるサブモジュールのさまざまなバージョンを追跡する際の注意が必要な側面です。ただし、サブモジュールrefは、プロジェクトの他のコンポーネントとまったく同じです。 2つの異なるブランチが連続したマージ後に同じそれぞれのサブモジュールrefを追跡し続ける場合、gitは将来のマージでマージの競合を引き起こすことなくパターンを解決できるはずです。一方、サブモジュールrefを頻繁に切り替える場合は、多くの競合の解決に耐えなければならない場合があります。
他のヒント
まあ、それはサブモジュールとの競合を技術的に管理していません(つまり、これを維持しますが、そうではありません)が、作業を続ける方法を見つけました...そして、私がしなければならなかったのは、私の git status
を出力し、サブモジュールをリセットします:
git reset HEAD subby
git commit
それはサブモジュールをプル前コミットにリセットします。この場合、まさに私が望んだものです。また、サブモジュールに変更を適用する必要がある他のケースでは、標準のサブモジュールワークフロー(チェックアウトマスター、目的のタグのプルダウンなど)でそれらを処理します。
この質問の答えに少し苦労しましたが、次の質問の答えはうまくいきませんでした。 同様のSO投稿 どちらか。これが私にとってうまくいったことです - 私の場合、サブモジュールは別のチームによって保守されていたため、マスターと私が取り組んでいたプロジェクトのローカルブランチの異なるサブモジュールバージョンから競合が発生したことに留意してください。
- 走る
git status
- 競合のあるサブモジュールフォルダーをメモします。 サブモジュールを現在のブランチで最後にコミットされたバージョンにリセットします。
git reset HEAD path/to/submodule
この時点で、競合のないバージョンのサブモジュールが完成しました。これをサブモジュールのリポジトリで最新バージョンに更新できます。
cd path/to/submodule git submodule foreach git pull origin SUBMODULE-BRANCH-NAME
そして今、できるのは
commit
それから仕事に戻りましょう。
まず、参照するサブモジュールに必要なハッシュを見つけます。実行
~/supery/subby $ git co hashpointerhere
~/supery/subby $ cd ../
~/supery $ git add subby
~/supery $ git commit -m 'updated subby reference'
これは、サブモジュールを正しいハッシュ参照に取得し、それ以上競合することなく作業を続行するために機能しました。
ブランチへの git rebase -i origin / master
でこの問題が発生しました。サブモジュールrefのマスターバージョンを取得したかったので、次のようにしました。
git reset master path / to / submodule
そして
git rebase --continue
これで問題は解決しました。
この議論から助けてください。 私の場合、
git reset HEAD subby
git commit
私のために働いた:)
まあ私の親ディレクトリで私は見る:
$ 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