Як мені керувати конфліктами з підмодулями 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і one.oneгілки superyмістять різні посилання на subbyпідмодуль, коли ви зливаєте зміни з mastergit, не знаєте, який ref - v1.0або v1.1- повинен зберігатися і відслідковуватися one.oneгілкою supery.

Якщо це так, то вам потрібно вибрати необхідний перелік та здійснити цю зміну для вирішення конфлікту. Це саме те, що ви робите з командою скидання .

Це складний аспект відстеження різних версій підмодуля в різних галузях вашого проекту. Але посилання на підмодуль - це як і будь-який інший компонент вашого проекту. Якщо дві різні гілки продовжують відслідковувати однакові відповідні підмодулі після послідовного злиття, то git має бути в змозі розробити схему, не викликаючи конфліктів злиття у майбутніх злиттях. З іншого боку, якщо підмодуль перемикається часто, то, можливо, доведеться змиритися з вирішенням багатьох конфліктів.

Ну, це технічно не керує конфліктами з підмодулями (тобто: зберігайте це, але не це), але я знайшов спосіб продовжувати роботу ... і все, що я повинен був зробити, це звернути увагу на свій git statusвихід та скинути підмодулі:

git reset HEAD subby
git commit

Це призведе до скидання підмодулю до попереднього виведення. Що в цьому випадку - саме те, що я хотів. І в інших випадках, коли мені потрібні зміни, застосовані до підмодулю, я оброблятиму їх із стандартними робочими процесами підмодуля (майстер оформлення замовлення, витягнути потрібний тег тощо).

Я трохи боровся з відповідями на це питання, і мені не пощастило з відповідями в аналогічному дописі ЗП. Отже, це працювало для мене - маючи на увазі, що в моєму випадку підмодуль підтримував інша команда, тому конфлікт виходив з різних версій підмодуля в майстер і мій локальний відділ проекту, над яким я працював:

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філією. Я хотів взяти версію підмодулю для master, тому просто зробив:

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