один и тот же проект, рабочий процесс git для нескольких клиентов

После моего первого вопроса хотелось бы получить подтверждение о лучшем рабочем процессе git в моем случае.

У меня есть один проект django, размещенный на github, и разные клоны с каждой его собственной веткой: customerA, customerB, demo... (думаю, веб-сайты)

Ветки используют одно и то же ядро, но имеют разные данные и настройки (они есть в gitignore)

Когда я работаю над веткой CustomerA, как мне реплицировать некоторые исправления ошибок в другие развертывания?

Когда я создаю новую общую функцию, я создаю специальную ветку, а затем объединяю ее с мастером. Затем, чтобы развернуть на «клиентах», я объединяю ветку master с веткой клиента. Это правильный путь? или я должен перебазировать?

# from customerA branch
git fetch origin master
git merge origin master

Кроме того, я создал удаленную ветку для каждого клиента, чтобы я мог создавать резервные копии веток клиентов на github.

Это выглядит очень классической проблемой, но я думаю, что неправильно использую git

Спасибо.

Ju.


person jujule    schedule 12.10.2009    source источник


Ответы (4)


У меня будет один репозиторий проекта в известном месте, содержащий основную ветку с общим кодом и ветки для конкретных развертываний (например, клиент/клиент/демонстрация B).

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

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

Задача будет состоять в том, чтобы поддерживать ветки, отклоняющиеся от мастера, и выполнять регулярные слияния, чтобы отклонение не увеличивалось со временем.

Где-то в Интернете я видел, как это решение описано более подробно, но не смог быстро найти его снова. Некоторая запись в блоге об использовании git для промежуточного и производственного веб-сервера, IIRC.

person ndim    schedule 13.10.2009
comment
Спасибо. Вот как я делаю на самом деле. Когда в развертывании customerA я делаю это, чтобы обновить код из главной ветки: git pull origin master git merge master правильно ли это? - person jujule; 14.10.2009
comment
Извините, на самом деле я делаю это из ветки customerA: git fetch origin; мастер происхождения git слияния; это правильно? - person jujule; 14.10.2009

Если три сайта имеют некоторый «основной» код (например, приложение Django), вам следует выделить это ядро ​​в собственное репо и использовать подмодули git, чтобы включить его в другие проекты, а не дублировать.

person Ben James    schedule 17.10.2009
comment
спасибо на самом деле мои клиенты используют одни и те же приложения, но некоторые из них настроены, поэтому я использую одно репо. Я добавлю подмодуль, когда у меня будет пользовательское клиентское приложение. - person jujule; 19.10.2009

У меня был бы репозиторий под названием project-master или что-то в этом роде и репо для каждого клиента. Затем, когда у вас есть код, который должен быть доступен для этих клиентских репозиториев, вы извлекаете из мастера проекта в это репозиторий.

person Adam Nelson    schedule 12.10.2009
comment
Вы говорите, что лучше разделить клиентов по репо, а не по филиалам? Почему это? - person Joshua Partogi; 13.10.2009
comment
Если клиент разделен репозиторием, вы можете перемещаться туда и обратно с помощью git, а не перемещать ветки туда и обратно. Похоже, вы хотите выборочно перемещать функции для определенных клиентов — и это, вероятно, самый эффективный способ. В качестве альтернативы вы можете просто иметь разные файлы настроек и включать/отключать различные функции приложения для каждого проекта. Это потребует от вас соответствующего написания приложений. - person Adam Nelson; 13.10.2009
comment
но что, если у меня есть исправление ошибки, затрагивающее все клиенты? Мне придется обновить все репозитории вручную, чтобы интегрировать исправление. - person dieter; 07.09.2016
comment
Вам нужно будет написать команду «объединить в несколько репозиториев» для этого сценария. - person Adam Nelson; 08.09.2016

Не разделяйте проекты по веткам, разделяйте их по разным репозиториям.

Сделайте «общий» код достаточно универсальным, чтобы копия общего кода для пользователя A была точно такой же, как копия общего кода для пользователя B.

Тогда вам не нужно ничего тянуть или объединять. Когда вы обновляете общий код, и костюмер А, и костюмер Б получат обновление автоматически (поскольку они используют один и тот же общий код).

Под «общим» кодом я подразумеваю пакет/серию приложений, на которых работают веб-сайты, которые вы разрабатываете.

Я предполагаю, что репозитории costumerA и costumerB будут включать только такие вещи, как настройки и шаблоны для конкретных сайтов.

Суть здесь в том, чтобы сделать «общий» код универсальным: не позволяйте customerA использовать «слегка измененную версию» «общего» кода.

Кроме того, я бы предложил использовать механизм развертывания, который не зависит от git. git — отличный инструмент для управления исходным кодом; но он не предназначен (AFAIK) для использования в качестве инструмента развертывания.

person hasen    schedule 19.10.2009