Как мне разрешить конфликты с подмодулями git?

Question

У меня есть суперпроект 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, который будет игнорировать мои подмодули?

Answer 1

Ну, технически это не конфликтует с подмодулями (то есть: сохраните это, но не это), но я нашел способ продолжить работу ... и все, что мне нужно было сделать, это обратить внимание на мой git status вывод и сброс подмодули:

git reset HEAD subby
git commit

Это сбрасывает подмодуль на предварительную фиксацию. Что в данном случае именно то, что я хотел. А в других случаях, когда мне нужны изменения, примененные к подмодулю, я буду обрабатывать их с помощью стандартных рабочих процессов подмодуля (мастер проверки, опускание нужного тега и т. Д.).

Answer 2

Я немного боролся с ответами на этот вопрос, и мне не очень повезло с ответами в аналогичном посте SO . Это то, что сработало для меня, учитывая, что в моем случае субмодуль поддерживался другой командой, поэтому конфликт возник из-за разных версий субмодулей в master и моей локальной ветки проекта, над которым я работал:

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 и вернуться к работе.

Answer 3

Я не видел этой точной ошибки раньше. Но я догадываюсь о проблеме, с которой вы столкнулись. Похоже, что ветви master и one.one supery содержат разные ссылки для подмодуля subby, когда вы объединяете изменения из master, git не знает, какой ref - v1.0 или v1.1 - должен храниться и отслеживаться веткой one.one supery.

Если это так, то вам нужно выбрать нужную ссылку и зафиксировать это изменение, чтобы разрешить конфликт. Именно это вы и делаете с помощью команды reset .

Это сложный аспект отслеживания разных версий подмодуля в разных ветках вашего проекта. Но подмодуль ref похож на любой другой компонент вашего проекта. Если две последовательные ветви продолжают отслеживать одинаковые ссылки соответствующих подмодулей после последовательных слияний, то git должен иметь возможность работать с шаблоном, не вызывая конфликтов слияний в будущих слияниях. С другой стороны, если вы часто переключаете ссылки подмодулей, вам, возможно, придется мириться с большим разрешением конфликтов.

Answer 4

Сначала найдите хеш, который вы хотите использовать в своем подмодуле. затем запустите

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

, который помог мне получить мой подмодуль с правильной ссылкой на хэш и продолжить работу без дальнейших конфликтов.

Answer 5

У меня была эта проблема с git rebase -i origin/master на ветке. Я хотел взять мастер версию подмодуля ref, поэтому я просто сделал:

git reset master path/to/submodule

, а затем

git rebase --continue

Это решило проблему для меня.

Answer 6

Получил помощь от этого обсуждения. В моем случае

git reset HEAD subby
git commit

у меня сработало :) 1004 *

Answer 7

Ну, в моем родительском каталоге я вижу:

$ 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