Как управлять несколькими версиями проекта?

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

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

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

Ответ 1

И все же ветвление должно работать и позволит вам поддерживать две отдельные версии.

Если у вас есть ошибка, относящаяся к версии премиум-класса, исправьте ее на master и слейте ее на ветке premium.
Git будет только сливать то, что изменилось с тех пор, как вы разветвлялись между master и premium, т.е. исправлены ошибки.
Другим способом публикации исправления как в master, так и premium будет делать это от общего предка: см. "Git слияние исправлений с несколькими ветвями".

Обновление 2015: git 2.5 (июль 2015 г.) заменил git-new-workdir, представленный ниже новой командой git worktree add <path> [<branch>].

Подробнее см. " Несколько рабочих каталогов с Git?.

Оригинальный ответ 2012:

me-and упоминает в комментариях команду git -new-workdir.
См:

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

Здесь находится git-new-workdir.
Вместо того, чтобы делать полномасштабный клон вашего репозитория, он просто настраивает новый рабочий каталог (со своим индексом) для вас.
Фактический репозиторий разделяется между исходным и новым рабочим каталогом. Это означает:

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

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

Ответ 2

Для этой цели лучше использовать worktree.

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

Итак, я создаю два worktree, что означает, создайте две соответствующие длинные ветки рядом с мастером.

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Тогда я:

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

Существует один репозиторий, но у меня есть 3 отдельные папки рядом друг с другом для каждой ветки выше. И сделайте общие изменения в мастер. затем объединить его с двумя другими версиями.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

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

Надеюсь, что это поможет.