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

Question

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

715 7

git conflict branch git-submodules

7 ответов:

Comments

Ничего не найдено.

Jesse Hallett · Accepted Answer · 2015-03-03 16:33:25

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

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

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

Tyler · Accepted Answer · 2009-05-07 18:33:52

Ну, это не технически управление конфликтами с подмодулями (т. е.: держите это, но не то), но я нашел способ продолжить работу...и все, что мне нужно было обратить внимание на мой git status вывод и сброс подмодулей:
git reset HEAD subby
git commit
это приведет к сбросу подмодуля к предварительной фиксации. Что в данном случае именно то, что я хотел. И в других случаях, когда мне нужны изменения, применяемые к подмодулю, я буду обрабатывать их со стандартными рабочими процессами подмодуля (checkout master, опустите нужный тег, и т. д.).

Emma Burrows · Accepted Answer · 2017-09-05 12:19:04

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

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

git reset HEAD path/to/submodule
на данный момент у вас есть бесконфликтная версия вашего подмодуля, которую теперь вы можете обновить до последней версии в репозитории подмодуля:
cd path/to/submodule
git submodule foreach git pull origin SUBMODULE-BRANCH-NAME
теперь вы можете commit вот и возвращайся к работе.

hellatan · Accepted Answer · 2013-01-09 04:01:29

во-первых, найдите хэш, который вы хотите, чтобы ваш подмодуль ссылался. тогда беги
~/supery/subby $ git co hashpointerhere
~/supery/subby $ cd ../
~/supery $ git add subby
~/supery $ git commit -m 'updated subby reference'
это сработало для меня, чтобы получить мой подмодуль к правильной ссылке хэша и продолжить свою работу без каких-либо дальнейших конфликтов.

marathon · Accepted Answer · 2017-05-01 16:35:41

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

git reset master path/to/submodule

а то

git rebase --continue

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

Mithun Das · Accepted Answer · 2017-08-29 12:20:13

получил помощь от этой дискуссии. В моем случае
git reset HEAD subby
git commit
работала на меня :)

Kjeld Flarup · Accepted Answer · 2018-01-16 10:25:59

Ну в моем родительском каталоге я вижу:
$ 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