Предположим, у нас есть следующая структура репозитория на 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.
Мы ' Я пробовал несколько рабочих процессов, и указанная выше проблема - единственная, в которой у нас еще нет хорошего рабочего процесса.