Как в Git вынести часть проекта в отдельное отвествелние?

Есть сайт, ядро которого можно использовать для создания еще одного сайта.
Различие будет только в стилях и верстке.
Возникает вопрос как все это в рамках одного проекта выделить чтобы в комитах не было пересечений?

Т.е. по верстке комиты идут своим ходом, а если надо поправит логику то она тут же где то то рядом идет.

Не копировать же проект в отдельный репозиторий, потом поддерживать код будет сложно сразу в двух местах.
  • Вопрос задан
  • 1673 просмотра
Пригласить эксперта
Ответы на вопрос 4
AlexXYZ
@AlexXYZ
O Keep Clear O
1. В git есть система подпроектов, но как-то она не работает интуитивно понятным способом и не автоматически. Про подпроекты надо не забывать. Они сами не коммитятся.
2. Можно использовать сборку (например, grunt). Мне этот вариант кажется более предпочтительным, хоть это и не git. Вы в одном проекте git сможете иметь несколько подпроектов, хранить все в одном репозитории, и для выпуска собирать тот, который вам нужен.
3. Выделит ваше ядро как проект для bower, положить его на ресурс (gitlab/github). Обновление версий ядра в проектах вести соответственно через bower. Тогда проекты для сайтов можно держать в двух раздельных репозиториях 1 и 2. (итого у вас будет три репозитория. 3-й - для ядра). И даже смена ядра не будет сильно отражаться на проектах независимо от изменений в ядре, как это было бы в первых двух вариантах, где бы вам приходилось согласовывать все подпроекты при изменении версии ядра и это было бы самой неприятной работой, что-то менять, когда 1-й проект уже сдан (т.е. если вы поменяли версию ядра, то и обновлять надо сразу все проекты, а с bower такого не будет). - Мне кажется этот вариант вообще идеальный! - я за этот вариант. Связь между репозиториями такая:
f70140d23e0b4c68bd24b01110873543.png
Ответ написан
nonlux
@nonlux
Красноглазил я как-то целую неделю для подобного )

1. В текущем проекте (проект А) уже имеющем приличное число коммитов решил выделить common ветку для аналогичных целей.
Делал rebase всей истории по таком принципу
все общие именения ( не факт что это отдельный коммит ) выкидывал в ветку common, и мержил эти изменения в new_master
все остальное кидал в new_master
потом просто перенес master на новую ветку
Адский труд, но так как проект был полностью покрыт тестами ничего не сломал
Теперь подход такой все общие фичи в common, а потом merge с master

2. Далее создал новый репозиторий (проект В) в нем только одна ветка common
в локальном (проекте A) добавил еще один remote проект В

Теперь все push только для ветки common шлю в два репозитория

3. Если понадобился новый проект (проект C)
клонирую проект В меняю origin на проект C
ну а c common веткой все тоже самое.
Ответ написан
Комментировать
dmitriylanets
@dmitriylanets
веб-разработчик
использовать composer для сборки проекта, ядро будет в виде отдельного git репозитория
Ответ написан
@Andy_U
Посмотрите на git subtree, например: сюда.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы