LINUX.ORG.RU

Git, субмодули, bitbucket

 ,


0

1

Добрый день!

В своих проектах я использую субмодули git. Каждый проект логически состоит из частей. Эти части хранятся в своих репозиториях и обычно входят в другие проекты. Проекты хранятся в своих репозиториях. Все репозитории хранятся на bitbucket. Таким образом, если зайти на bitbucket и ткнуть sources, можно посмотреть весь проект вместе с субмодулями. Когда кликаешь на субмодуль, автоматически переходишь в его репозиторий. Проект выглядит связано. Очень красиво.

Знатоки Git, посоветуйте пожалуйста как лучше сделать.

Как лучше организовать рабочий процесс?

Допустим другой разработчик делает форк проекта и отдельные форки субмодулей. Когда он заходит в свой репозиторий и кликает на субмодули, он видит что они ссылаются на мои репозитории. (Это все потому что в .gitmodules url указаны на репозитории в моем аккаунте. Файл .gitmodules индексируется)

Разработчик делает git clone ..., затем git submodules update --init. Потом он может поменять .gitmodules, задав свои url, и тогда bitbucket будет красиво показывать проект в его аккаунте.

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

Если изменения будут внесены в несколько субмодулей и в проект, как их объединить в один пулл реквест?

Вообще, как правильно поступать, когда нужно чтобы части проектов существовали отдельно и их можно было дорабатывать из любого проекта? Например, есть модуль Minilib, в нем находятся классы, которые нужны почти в каждом проекте. Например, логгер, класс исключений, функции для работы со строками, и т д. Ведь не правильно будет его копипастить в каждый проект, где он может понадобиться. Потом новый функционал придется вручную переносить в несколько проектов. Хорошей идеей будет расположить его в своем репозитории и подключать в виде субмодуля в каждый проект.

Тогда как можно решить описанные проблемы: добиться связности проекта и субмодулей в разных аккаунтах bitbucket и организовать пулл реквесты из нескольких репозиториев. Может есть другой, более правильный подход при работе с bitbucket?

А может это особенность bitbucket и стоит перейти на другой подобный сервис?


Вообще, наибольшая гибкость в отправке пулл-реквестов возможна если ты используешь git format-patch и шлешь их по email :)

annulen ★★★★★ ()
Ответ на: комментарий от annulen

То есть разработчик делает патч своих изменений и шлет их по почте, а я потом применяю его патч пержу и пушу на bitbucket?

А можно в одном патче пересылать изменения из нескольких репозиториев?

silart ()

Сабмодули на то и сабмодули, что могут и должны развиваться самостоятельно. Не должен никто форкать основной проект, менять там .gitmodules и отправлять изменения в модулях и в основном проекте одним PR. Сначала делаются нужные изменения в модуле, потом основной проект переключается на свежую версию модуля, потом добавляются изменения использующие нужную функциональность модуля.

slovazap ★★★★★ ()
Ответ на: комментарий от annulen

Не смешите, никто уже 20 лет патчи из email не выковыривает.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

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

С модулями все получается: делаешь форк модуля из основного репозитория в свой, пушишь изменения в свой репозиторий, делаешь пулл реквест. А с репозиторием проекта все не так красиво. Нужно дождаться пока будут приняты изменения модулей, потом обновить модули из основного репозитория, и только после этого вносить изменения. Получается что целостный проект как бы разделяется на модули и с ними приходится работать отдельно. А на практике очень часто приходится одновременно вносить изменения и в проект и в субмодули.

silart ()
Ответ на: комментарий от silart

лучше переходи с submodules на другие способы организации зависимостей

submodules редко используются именно из-за запутанности и из-аз того что не вписываются в современные реалии. С ними будешь натыкаться на проблемы на каждом шагу: при форках, при реквестах, при запуске ci, версионировании и т.п.

alpha ★★★★★ ()
Ответ на: комментарий от annulen

Вообще, наибольшая гибкость в отправке пулл-реквестов возможна если ты используешь git bundle и шлешь их по email

Поправил, не благодари.

Dendy ★★★★★ ()

Я для работы с несколькими репозиториями завёл на bitbucket обычный repo: http://source.android.com/source/using-repo.html. Всё клонируется и синхронизируется одновременно, патчи на каждый проект отправляются отдельно или скопом. Правда пул-реквесты ещё не пробовал, можно ли их группировать (как в Gerrit) и насколько оно гибко.

Dendy ★★★★★ ()
Ответ на: комментарий от alpha

лучше переходи с submodules на другие способы организации зависимостей

А куда можно перейти? Посоветуйте.

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

silart ()
Ответ на: комментарий от Dendy

Пожалуйста поясните что такое repo. Это не связано с git?

silart ()
Ответ на: комментарий от silart

ну это обычно зависит от контекста

если нужно независимое версионирование - то независимые библиотеки и соответственно зависимости на библиотеки как это принято в выбранном языке программирования

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

ну либо «умные» сборочные скрипты которые тащат данные из нескольких реп и готовят дерево исходников предварительно до начала сборки

alpha ★★★★★ ()
Ответ на: комментарий от alpha

Вот мои проекты:

QtDriversim WebDriversim

Если зайти в source, в папке src, можно увидеть какие там используются модули, и то, что часть модулей входит в оба проекта. Можно видеть, что, к примеру, модуль Minilib содержит всякие рутинные компоненты вроде класса исключений, логера, и т д. Этот модуль входит почти во все проекты и в него время от времени что-то добавляется. Модули оформлены как папка с исходниками и make-файлом. В проекте есть головной make-файл, где указан список используемых модулей. Во время сборки каждый модуль собирается как static library, и потом все эти *.a компонуются в один исполняемый файл.

Как лучше с точки зрения git организовать хранение проектов?

silart ()
Ответ на: комментарий от silart

Пожалуйста поясните что такое repo.

По ссылке что я кинул можно всё прочитать. Если вкратце, это утилита для одновременной работы нескольких независимых Git-проектов. Зависимости между ними указываются в отдельном файле-манифесте в простом формате XML, который тоже заводится в отдельный Git-проект и синхронизируется с остальными.

Зависимые проекты можно группировать, можно делать ссылки на внешние проекты, к примеру в вашем проекте используется libfoo, который развивается Васей Пупкиным на каком-то гитхабе и когда в нём обновляется ветка master, то она должна автоматически выкачаться. Для этого в ваш манифест добавляется зависимость вида:

<remote name="vasya" fetch="git://github.com/vasyapupkin"/>
<project name="libfoo" remote="vasya" revision="master"/>

Зависимость на локальный проект описывается ещё проще, потому что они хостятся там же у вас на битбакете, рядом с самим проектом манифеста:

<project name="qtdriversim"/>
<project name="webdriversim"/>
Dendy ★★★★★ ()
Ответ на: комментарий от silart

Локально ты можешь никак не трогая основной репозиторий в директории сабмодуля делать что угодно - переключить его на другой апстрим, коммит, ветку, накоммитить своего, засрать незакоммиченными изменениями рабочую директорию - что хочешь. Поэтому ни для автора, ни для стороннего контрибутора работа с репозиторием содержащим сабмодули проблем вообще никаких не представляет. Pull Request'ов будет да, два - в сабмодуль и в родителя. Потому что это разные сущности. Их ничто не мешает отправить одновременно.

Получается что целостный проект как бы разделяется на модули

Разделяя проект на модули, ты, сюрприз, разделяешь его на модули, и не «как-бы», а на самом деле.

slovazap ★★★★★ ()

IMHO, submodule самый подходящий способ выделить из проекта общую часть, которую используют разные проекты. И как тут уже написали, разделяя проект на модули, ты выделяешь независимые части. Поэтому pull request будет несколько.

Далее, если в твоем проекте есть модуль, в котором собраны части кода, используемые в других проектах, то другому разработчику требуется возможность записи в этот репоизторий этого модуля. Поэтому, нужно дать ему возможность писать в репозиторий, но в отдельные ветки. Т.е. master и release ветки нужно защитить от записи, а в отдельные ветки разработчики пусть пишут сколько им потребуется. Соответственно другой разработчик будет вести разработку своего проекта и вносить правки в твой модуль. При окончании разработки требуемой функциональности, нужно будет сделать в том числе и слияние правок в общем модуле, а только потом вносить изменения в основной проект. И по другому никак, потому что модуль используется в нескольких проектах (при этом он самостоятельный проект). Например, у тебя есть общая библиотека, которая умеет складывать и вычитать, а твоему проекту от нее требуется новая функциональность - умножение и деление. Ты параллельно добавляешь функциональность в свой проект и общий модуль (в отдельную ветку). Когда все заработает - вливаешь правки в master (или release ветку) модуля, а затем правишь ссылку на submodule в своем проекте.

Если общий модуль - это какая-то стандартная библиотека (или просто ты не контролируешь его репозиторий), то обязательно в своем проекте нужно делать клон того репозитория, чтобы использовать его в качестве submodule. Иначе при удалении того репозитория, изменения его истории (так что все хеши изменятся и не будет нужного тебе хеша коммита) твой репозиторий не сможет выгрузить исходники в submodule. Короче, все submodule должны быть клонированы в подконтрольный тебе репозитории. Если надо, будешь копировать изменения из основного репозитория в свой клон.

Кажется все сложно и запутанно, на самом деле все довольно просто. Нужно лишь понимать, что submodule - это отдельный проект, хоть и выглядит как часть твоего проекта. И причина этого в том, что им пользуются другие репозитории, т.е. внося изменения в submodule, нужно оставить работоспособными другие проекты, использующие тот же модуль. Поэтому правки в проект и в submodule вносятся независимо (но основной проект отслеживает, какой коммит модуля используется в текущий момент).

Если все вкратце, то при работе с submodule нужно сделать так, чтобы модуль лежал в подконтрольном тебе репозитории, все разработчики должны иметь возможность создавать там отдельные ветки. При разработке сначала изменения вносятся в отдельную ветку модуля, затем в основной проект. Когда разработка новой функциональности закончена - сначала изменения принимаются в модуль, затем основной проект переходит на новый релиз модуля и принимаются изменения в основной проект. Так как все это происходит внутри одной команды, то сделать работу достаточно оперативной - вполне реально.

anonymous ()
Ответ на: комментарий от anonymous

Когда разработка новой функциональности закончена - сначала изменения принимаются в модуль, затем основной проект переходит на новый релиз модуля

зачем submodule если есть пиннинг к версии?

релизы распространяются артефактами а не git-индексами с историей

alpha ★★★★★ ()
Ответ на: комментарий от silart

а я потом применяю его патч пержу и пушу

Второй пункт необязателен. Вместо него лучше делать слияние.

andreyu ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.