Как управлять конфликтами с подмодулями git?

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

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

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

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

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

git reset HEAD subby
git commit

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

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

1. Выполнить git status- отметить папку подмодуля с конфликтами

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

   git reset HEAD path/to/submodule

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

   cd путь / к / подмодулю
   git submodule foreach git pull origin SUBMODULE-BRANCH-NAME

4. А теперь вы можете 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