Как вести два одинаковых проекта, имя возможность дорабатывать их вместе и по отдельности?
Здравствуйте!
Есть ситуация: есть текущий проект в git. Он работает и всё отлично. В репозитории git есть только одна ветка - она же релизная, без dev веток.
Сейчас появилась необходимость создать копию этого проекта для другой компании. Проект будет немного дописан под эту компанию, но в целом, кодовая база на 99% останется изначальная. Но в будущем, планируется улучшение как только изначального проекта, так и улучшения копии, а также общие улучшения их вместе.
Каким образом можно удобно вести работу над двумя проектами параллельно, имея возможность удобно дорабатывать оба проекта и каждый из них по отдельности?
Мои варианты:
1) Использовать два независимых друг от друга репозитория. Но здесь стоит вопрос в том, что неудобно будет вносить правки в оба проекта.
2) Использовать разные ветки внутри одного репозитория или подмодули.
3) Доработать текущий проект так, чтобы было 1 общее ядро, которое будет дорабатываться отдельно, а для каждой компании создать свой репозитории, где будут хранится "плагины" к этому ядру. Но в этом случае придётся значительно переписать текущий код.
Звучит лучше всего третий вариант, но на его реализацию потребуется достаточно много времени, чтобы чётко определить "границу" между плагином и ядром. Ну и переписывать так же нужно будет очень много.
Два репозитория. В обоих добавляете еще один origin - на другой проект.
Если нужно внести изменения в оба проекта, то сначала делаете это в одном, потом в другом проекте мерджите изменения с другого origin'а.
Писать код нужно максимально независимым. Используйте модульность, для модулей внешнее API и event/listeners для общения наружу. В местах где логика различается - по максимуму полиморфизм, и.е. избегайте мерджов всеми силами.
Второй вариант говно. Третий вариант слишком сложный.
1) вы себя проклянете, если правок будет хоть немного больше парочки.
2) это тот же 1) только сбоку. С точки зрения гита - мало разницы между втрой веткой в том же репо или такой-же веткой в другом репо. команды на мерж кода будут разные, все остальное - одно и то же.
оба норм если количество разных правок небольшое и работу над одним из проектов вы точно и стопроцентно завершите в ближайшем будущем.
Ну или если вы полностью разделите эти проекты, и работа над ними будет независима, тогда вариант 1)
3) правильный вариант. Стоит ли он потраченных усилий - это уж только вы сами можете оценить.
Robur, нет, плагины это совсем другое. Плагины требуют какой-то АПИшки в ядре, не зависят друг от друга и могут свободно отключатся и подключатся.
Модули вполне могут зависеть друг от друга (и зависимостей этих обычно достаточно), не требуют никакого АПИ и далеко не всегда свободно отключатся и подключаются.
Это разные концепты, не стоит называть одно другим именем. Неправильно реализованные модули, неправильные зависимости между ними или неправильная архитектура внутри все равно приведет к куче мерджей, в то время как с плагинами дела обстоят совсем иначе.
Alex Wells, ни вы, ни я не знаем что именно автор подразумевал под "плагинами". А учитывая что он их поставил в кавычки - он и сам не особо.
Главное - что это требует перестройки кода во что-то нормальное и модульное, что можно дорабатывать отдельными частями и деплоить разный код для разных клиентов
Alex Wells, Robur, спасибо за дисскуссию.
Если интересно, остановился на решении с плагинами. Моя система на PHP, внедрить в неё базовый функционал хуков оказалось достаточно просто (взял практически 1 в 1 из WordPress). Это позволит проще настраивать систему под другие компании, а так же развивать ядро отдельно от надстроек, которые будут уникальными в каждом случае.
Alex Wells, по факту - хуки, это тоже самое, что эевенты и лисенеры.
Создаётся куча слушателей, потом вызывается хук, который является евентом. Если нужно вызвать ещё раз этот же хук - он вызывается.
Не очень понимаю разницу, только в термионалогии. Сейчас нашёл стандартный модуль PHP Event, который как раз реализует евенты, но он более сложный в понимании и использовании, чем то, что используется в WordPress. По крайней мере, на первый взгляд.
