Управление версиями с несколькими версиями

Question

У меня есть общий вопрос управления версией. Недавно я написал приложение и планирую использовать мою текущую работу с новыми функциями.
Мое намерение состоит в том, чтобы закончить с двумя различными приложениями ("my application", and "my application plus"), оба основаны на одном и том же ключевом коде, но одна из версий имеет больше встроенных функций.
Мой вопрос в том, есть ли способ установки контроля версий два разных репозитория (я полагаю), но один из репозиториев ссылается на другой.
Так что, в основном, если я изменю один из основных элементов в одном приложении, он изменит его в обоих.

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

Любые идеи?

Answer 1

Обычно вы должны использовать систему, которая помогает с ветвлением (например, git) и сохранять отдельные ветви (например: мастер, мастер-плюс). В каждом выпуске git rebase (или git merge) изменится с вашего основного приложения на плюс.

PS: Вы можете АОТ сделать то же самое с каким-то способом плагиным и два РЕПО

Answer 2

Если базовое приложение написано уже и вы намерены реализовать расширенную версию этого я рекомендую вам подумать о подмодулях, которые является особенностью Git (см. здесь: http://git-scm.com/book/en/Git-Tools-Submodules). Это может быть хорошим решением для всего приложения или только для его ядра. Подумайте об использовании этого.

Answer 3

Да, вы можете.

Я использовал следующую стратегию в недавнем проекте, в котором на его пике было около 5 одновременных разработчиков, и оно хорошо работает. Код base в нашем случае является основным проприетарным продуктом, а plus - это клиентская настройка этого кода base.

У нас было место в проекте для base нравится:

repo/ 
- base/ 
+ trunk 
+ branches 
+ tags 

Мы создали проект пространство для plus вместе с базой в том же хранилище;

repo/ 
-base/ 
+ branches 
+ tags 
+ trunk 

-plus/ 
+ branches 
+ tags 
[new trunk will go here] 

Использование svn copy клонировать base/trunk в plus/trunk.

base и plus теперь имеют общую родословную. plus постоянно обновляется путем периодического объединения base/trunk в plus/trunk. И по соглашению мы никогда не сливались с плюсом на базу.

Самая трудная часть (я нашел) было обеспечение разработчики оставались дисциплинированными при совершении. Легко закончиться беспорядком, если вы начнете совершать то, что должно быть base код в plus с целью его последующего переноса. Сливы обычно были очень простыми.

Для записи я бы не стал делать это снова в svn, я бы использовал git. Я описал это в терминах svn просто потому, что сделал это раньше.

Кстати, branch может использоваться для различных целей - ветвей, горячих исправлений, интеграции релизов, ветвей поставщиков ... всех ветвей, но по договоренности они означают разные вещи. То, что я описал, по-прежнему является ветвью в некотором роде - только тот, который не реорганизуется конвенцией со своей исходной стволом. Ака-вилка.