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

Question

У меня есть суперпроект git, который ссылается на несколько подмодулей, и я пытаюсь заблокировать рабочий процесс, чтобы остальные члены моего проекта могли работать внутри него.

Допустим, в этом вопросе мой суперпроект называется supery , а подмодуль - subby . (Это упрощение того, что я пытаюсь сделать ... На самом деле я не использую ветки для версий, но я подумал, что было бы проще изложить их в виде вопроса.)

Моя основная ветвь supery содержит тег v1.0 git проекта subby , упоминаемый как подмодуль. Ветвь supery называется one.one и изменяет ссылку на подмодуль, указывая на тег v1.1 в subby .

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

Обычно после запуска git pull . master , находясь в ветви subby , похоже, что он создает дополнительные подмодули.

Перед извлечением / слиянием я получаю желаемый ответ от подмодуля git из ветви 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

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

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

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

Answer 2

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

git reset HEAD subby
git commit

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

Answer 3

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

<Ол>

Запустите git status - запишите папку подмодуля с конфликтами

Сбросьте подмодуль до версии, которая была последний раз зафиксирована в текущей ветви:

git reset HEAD path / to / submodule

На данный момент у вас есть бесконфликтная версия вашего подмодуля, которую вы теперь можете обновить до последней версии в хранилище подмодуля:

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

И теперь вы можете зафиксировать и вернуться к работе.

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 для ветки. Я хотел взять основную версию ссылки на подмодуль, поэтому я просто сделал:

главный путь git reset / к / субмодулю

а затем

git rebase --continue

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

Answer 6

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

git reset HEAD subby
git commit

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

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