Что такое хороший рабочий процесс для подмодульных вилок?

Question

Предположим, у нас есть следующая структура хранилища на github:

company:project.git
  \- company:submodule.git

Разработчик в моей компании разветвляет проект компании, заставляя свое рабочее пространство выглядеть так:

developer:project.git
  \- company:submodule.git

Это хорошо для 90% разработчиков, поскольку они не меняют библиотеку подмодулей, они работают только в проекте. Теперь предположим, что есть новая функция, которая требует улучшений в подмодуле. Разработчик, которому поручено это, преобразует свое рабочее пространство в следующее:

developer:project.git
   \- developer:submodule.git

Добраться туда нетривиально, так как ему нужно заменить подмодуль другим подмодулем (для git оригинал и ответвление подмодуля - две разные вещи).

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

Как только он будет готов к разработке, он создаст запрос на извлечение. Проблема в том, что при объединении запроса извлечения основной репозиторий будет выглядеть так:

company:project.git
   \- developer:submodule.git

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

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

Мы перепробовали несколько рабочих процессов, и вышеупомянутая проблема - единственная, где у нас пока нет хорошего рабочего процесса.

Answer 1

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

1. филиал супермодуль
2. Оформить версию компании в подмодуле
3. обновить .gitmodules в супермодуле, если разработчик изменил это с предыдущей версии
4. поставить и зафиксировать это изменение
5. проверить все
6. выдать запрос на извлечение

Затем он может вернуться к своей обычной ветке разработки в супермодуле.

Одна вещь, которую я не понимаю в вашем вопросе:

Добраться туда нетривиально, так как ему нужно заменить подмодуль другим подмодулем (для git оригинал и ответвление подмодуля - две разные вещи).

Напротив, подмодулем может быть любой репозиторий git, если он содержит коммит, на который указывает супермодуль. Если есть два разных удаленных репозитория, он может просто добавить дополнительный пульт в подмодуль. (Разработчик также должен изменить .gitmodules, если он собирается поделиться своим хранилищем с кем-либо еще.)

---

В ответ на ваш комментарий ниже, возможно, стоит разобраться, как переключить подмодуль с указания на одну версию в другой. Предположим, что разработчик использует свои собственные репозитории для супер и субмодуля, но оба они клонированы из версий компании (т.е. большая часть истории одинакова), а субмодуль находится по пути lib. Теперь разработчик хочет переключить субмодуль, чтобы он указывал на версию компании. Они могут делать следующее:

1. Измените параметр url для подмодуля в .gitmodules, чтобы он указывал на репозиторий компании.
2. cd lib
3. git remote add company developer@company:/srv/git/lib.git
4. git fetch company
5. git checkout -b upstream-master company/master
6. cd ..
7. git add .gitmodules lib
8. git commit -m "Switch the lib submodule to point back to the company's version"

Шаги с 3 по 5 можно изменить на git checkout <whatever> после настройки пульта и филиала.

Answer 2

Другое, простое решение - заставить git игнорировать .gitmodules и убрать их из отслеживания. Как сказано выше, .gitmodules используются только для инициализации подмодулей, поэтому он необходим только один раз при проверке подмодулей.

Answer 3

Для того, чтобы он мог на нем развиваться, разработчику не нужно менять сам подмодуль - они могут добавить еще один пульт и нажать на него.

Пример:

developer:project.git
  \- company:submodule.git
        Origins: company/submodule.git
                 developer/submodule.git

Рабочий процесс:

cd path/to/submodule
git remote add developer git@gitserver/developer/submodule.git

// взломать проект

cd path/to/submodule
git push developer branchname

Это определенно не идеально и может вызвать проблемы, если запрос на извлечение проекта / проекта передается в компанию / проект перед разработчиком/ submodule делает это для компании / submodule.

Только мои быстрые мысли.

Answer 4

Теперь предположим, что есть новая функция, которая требует улучшений в подмодуле.

Вклад, выполняемый в подмодуле, только коммиты в подмодуле git repo, как обычно, должны быть запрошены.1005 *

Для того, чтобы нажать на ваш форк субмодуля, конфигурацию .gitmodules проекта

• можно изменить на вашем клонированном форке (но он будет на вашей стороне)
• илиПодмодульная вилка может быть добавлена ​​как удаленная