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

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

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

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

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

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

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

Допустим, что нет необходимости в замене подменю другим подмодулем (до git, оригинал и fork подмодуля - две разные вещи).

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

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

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

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

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

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

Ответ 1

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

ветвь супермодуля
проверить версию компании в подмодуле
update .gitmodules в супермодуле, если разработчик изменил это из версии выше
и зафиксировать это изменение
проверить все
выдать запрос на извлечение

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

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

Допустим, что нет необходимости в замене подменю другим подмодулем (до git, оригинал и fork подмодуля - две разные вещи).

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

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

Отредактируйте параметр url для подмодуля в .gitmodules, чтобы указать на репозиторий компании.
cd lib
git remote add company [email protected]:/srv/git/lib.git
git fetch company
git checkout -b upstream-master company/master
cd ..
git add .gitmodules lib
git commit -m "Switch the lib submodule to point back to the company version"

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

Ответ 2

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

Ответ 3

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

Пример:

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

Workflow:

cd path/to/submodule
git remote add developer [email protected]/developer/submodule.git

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

cd path/to/submodule
git push developer branchname

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

Просто мои быстрые мысли.

Ответ 4

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

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

Чтобы надавить на вашу подмодульную вилку,

Конфигурация проекта .gitmodules может быть изменена в вашей клонированной вилке (но поддерживается на вашей стороне).
или ваша подмодульная вилка может быть добавлена как удаленная