Правильно ли это настройка git?

Question

У меня есть среда CMS, которую я использую для нескольких проектов, закодированных мной. Как я делаю свои проекты, CMS Gets улучшается, и я часто хочу использовать эти изменения в последующих проектах. Часто у меня есть несколько проектов на ходу одновременно.

После того, как я прочитал git, я знаю, что могу отбросить каждый проект и внести улучшения CMS обратно в мастера, а затем перераспределить их на другие ветви, но это кажется неправильным. Особенно через несколько лет, когда некоторые проекты завершены, но основная CMS выглядит очень по-разному, как это было, когда они ее использовали. Это также означает переключение между филиалами при переключении между проектами. Также будет ли каждый компьютер, который я использовал его, получить копию каждой ветки когда-нибудь, когда я создал репо на этой машине?

Другой вариант, похоже, клонирование. У меня есть основное репо, которое содержит «основную» CMS, каждый проект становится клоном этого и обрабатывается отдельно. Это кажется более интуитивным, но могу ли я объединить некоторые изменения в клоне в ядро, и могу ли я распространять основные изменения на другие клоны?

EDIT: Думая об этом больше, клонирование - это термин, который я считаю для копирования репо на машину (из которой я использую несколько, чтобы я хотел быть в курсе последней версии некоторых из проектов). Так что, может быть, я должен «разветвляться»? это что-то вроде github?

Имеет ли какой-либо вариант правильный метод? Все советы оценили

Answer 1

Другой вариант, похоже, клонирование. У меня есть основное репо, которое содержит «core» CMS, каждый проект становится клоном этого и обрабатывается по отдельно. Это кажется более интуитивным, но могу ли я объединить некоторые изменения в клоне к ядру, и могу ли я распространять основные изменения на других клонов?

Для кого-либо, кто сталкивается с этим, клонирование было способом пойти сюда. Это позволяет вам иметь все сайты как отдельные папки на вашем компьютере, поэтому вы можете легко переключаться без проверки филиалов и т. Д. Затем он позволяет вам нажимать изменения с каждого клона на производственный сервер и/или обратно в основной репозиторий (происхождение). Затем из источника вы можете выталкивать изменения в зависимости от того, что вам нравится. Nifty использование .gitignore, --assume-unchanged и настройка каждого проекта на «тематическую» папку означала, что вы можете подталкивать все изменения, не беспокоясь слишком много об одной индивидуальности, переписывающей другую.

Answer 2

Я действительно столкнулся с аналогичной проблемой. Итак, я создал 2 репозитория. Один с ядром приложения, который должен иметь каждый экземпляр для работы.

В дополнение к этому репозиторий для конкретных файлов и конфигураций каждого экземпляра.

Ядро-репо было помечено номерами версий, где каждый тег на главном ядре был рабочей версией.

Это позволяет проверить конкретный тег и сохранить отдельные данные в репозиториях экземпляра. То, что вы не можете сделать с этой настройкой, - это поддерживать определенный код в репозиториях экземпляра и сливаться с другими экземплярами. Вы могли бы сделать это, если у вас будет всего 1 экземпляр репо, и вы будете разворачивать каждый экземпляр там, или вы можете использовать что-то lile composer (www.getcomposer.org), чтобы поддерживать ваши зависимости в очереди.