Стратегия git ветвления для модульной основы проекта
Я веду разработку абстрактного проекта на фреймворке php. По сути я делаю заготовку для будущих проектов. Проекты могут быть разными и включать в себя применение БД или нет, аналогично с авторизацией пользователей. В моем видении авторизация пользователей и регистрация без БД не возможна. Получается в системе контроля версий авторизация — это отдельная ветка, причем ответвление идет от ветки БД. И вот итог: Большое, красивое дерево с кучей ответвлений. И вот появился проект и его надо реализовать используя это дерево. Вот тут и вопрос, как это лучше сделать. Один из вариантов, который пришел мне в голову: создать отдельную ветку у корня и cherry-pick перенести все нужные коммиты. Но мне кажется, что такое решение слишком топорно и не гибко, есть предложения лучше?
В данной ситуации использование субмодулей не поможет, так как подключение БД вносит изменения не только в дочерней директории. Кроме того даже если использовать систему подмодулей, то как это облегчит создание проекта на основе дерева…
Боюсь, что в этом случае надо начинать не со способов использования git, а с понимания, где в архитектуре запутка. Авторизация — это не ветка в git, а обособленная функциональность. Если ее нельзя включить в проект без изменения во многих остальных частях — у вас проблема со связанностью.
Предположим, в проекте A исправлена ошибка в функции авторизации. Как вы исправления собираетесь передавать в проект B?
Ну собственно вопрос был как создать проект B на основе проекта A (желательно, чтоб изменения в проекте A автоматически или максимально просто переносились в B). На счет авторизации вы правы — это обособленная функциональность, но включать ее в проект, особенно при использовании фреймворка можно и путем редактирования нескольких файлов в разных каталогах (Метод авторизации, миграция для БД, расширение класса пользователя). А веткой это изменение является, потому как не в каждом проекте нужна авторизация.
Вы безусловно можете придумать способ обмена разделяемой функциональностью путем черри-пиков между ветками. Ну или делать форки исходного репозитория и далее переносить изменения через патчи.
Но правильные способы — composer/субмодули. Поверьте, все остальные способы содержат в себе кучу грабель. Если эти способы вам не подходят — меняйте архитектуру, или упретесь в неразрешимые проблемы достаточно быстро.
А что мешает форкнуть ваш фреймворк и в нём мёрджить нужные вам блоки? По факту у вас будет независимый проект, который является потомком от фреймворка и использует некоторые его наработки.
Я так понял вы предлагаете создать клон репозитория и в нем смержить ветки. В принципе подходит. Есть только один минус — при внесении изменений в оригинальном репозитории — не понятно как их добавить в уже смерженные ветки…
Да `git clone`, слово забыл просто :) Но да, по-моему в таком случае не понятно как вносить изменения из оригинального.
Возможно можно таскать с собой origin/* ветки из удалённого репозитория, но только в режиме чтения.
гит здесь не при чём, у вас банальные зависимости, в мире php это решает через pear или composer, в других языках есть свои пакетные менеджеры. каждый пакет хранится в своём репозитории и имеет лишь файлик, прописывающий зависимости.
Я правильно понимаю что одно из предложенных вами решений позволит разделить написанный мной код на пакеты с зависимостями и свободно их применять и откатывать?
да, конечно. вот пример пакетов laravel для ACL github.com/Zizaco/entrust/blob/master/composer.json, прописана связь на сам фреймворк и либу для работы с базой данных.
«illuminate/support»: «4.0.x»,
«laravelbook/ardent»: "*"
а в require-dev, пакеты которые нужны при разработке, для прогонов тестов, но не нужны на продакшене.
нет, личные репозитории это очень легко. есть глобальный конфиг компосера, он находится
.composer/config.json
%appdata%\roaming\Composer\config.json
туда просто добавляешь путь к своему репозиторию, локальному, либо удалённому. В репозитории, естественно боллжен быть свой файл компосера с названием, описанием пакета и его зависимостями.
репозитории прописываются примерно так "repositories": [
{
"type": "vcs",
"url": "/git/frozennode/administrator"
}
]
я даже для чужих либ, делаю свою локальную ветку, чтобы собиралось быстрее и не зависеть от лагов гитхаба, только вот обновлять приходится ручками через скрипт. всё довольно легко, только документация довольно куцая, вроде и много, но чёрт ноги сломит, разбираясь.
