2-версия программного обеспечения: лучший подход VCS?

Question

Полагаю, мне лучше объяснить мою ситуацию:

Я нахожусь в процессе разработки некоторого программного обеспечения, и я нахожусь на стадии, когда я хотел бы разделить свой проект на две ветви, которые отличаются по функциям. Случилось так, что это приложение для Android, которое я буду развертывать на Маркете, и оно имеет ограничение, согласно которому каждое приложение должно иметь уникальный идентификатор пакета (разумно, нет?).

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

У кого-нибудь есть предложения?

Answer 1

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

Я создал ветку для пробной версии из транка.

Затем я изменил AndroidManifest.xml пробной версии для изменения имени пакета, добавив .trial в конце. Затем мне пришлось обновить все Java-файлы активности, чтобы они ссылались на правильный класс R.

Мой платный пакет приложений com.hewittsoft.baby
Мой пробный пакет приложений com.hewittsoft.baby.trial

В своей деятельности на пробной ветке я делаю это

import com.hewittsoft.baby.trial.R;

и это приводит к тому, что любые ссылки на R.id.textField (или что-либо еще) работают.

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

Answer 2

Если единственной проблемой является проблема управления упаковкой и выпуском, вы можете изолировать эти шаги (переименовать пакет и протестировать его в целевой среде) из цикла историзации в одном репозитории Git.

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

Answer 3

Пара очень хороших статей о стратегиях ветвления: http://codicesoftware.blogspot.com/2010/03/branching-strategies.html http://nvie.com/git-model