Программное обеспечение С 2 версиями: Лучший подход VCS?
Я предполагаю, что должен объяснить свою ситуацию:
Я нахожусь в процессе разработки некоторого программного обеспечения, и я на этапе, где я хотел бы разделить свой проект на два ответвления, которые отличаются по функциям. Это так происходит, что это приложение является приложением Android, которое я буду развертывать на Рынке, который имеет ограничение, что каждое приложение должно иметь уникальный идентификатор пакета (разумный, нет?).
Мой текущий подход должен был клонировать мерзавца repo моего исходного проекта, но это вызывает проблемы с именами пакета. Я хочу, чтобы система была достаточно устойчива так, чтобы bugfix/new функция на одном ответвлении объединилась в другое ответвление, но только когда я хочу это к.
У кого-либо есть какие-либо предложения?
3 ответа
Я сам разбираюсь с этим конкретным случаем для платного приложения и пробной версии с одной и той же кодовой базой. Я использую SVN, но подойдет любое программное обеспечение для контроля версий, поддерживающее ветвление.
Я создал ветку для пробной версии из транка.
Затем я изменил файл AndroidManifest.xml пробной версии, изменив имя пакета, добавив в конце .trial. Затем мне пришлось также обновить все java-файлы активности, чтобы они ссылались на правильный класс R.
Мой пакет платного приложения - com.hewittsoft.baby
Мой пакет пробного приложения - com.hewittsoft.baby.trial
В своей деятельности в ветке пробной версии I я делаю следующее
import com.hewittsoft.baby.trial.R;
и это заставляет работать любые ссылки на R.id.textField (или что-то еще).
После того, как я проделал эти шаги, я могу разработать основную ветку, а затем без особых проблем объединить любые изменения в пробную версию.
Если единственная проблема связана с управлением упаковкой и выпуском, вы можете изолировать эти шаги (переименовать пакет и протестировать его в целевой среде) от цикл историзации в рамках одного репозитория Git.
Таким образом, вы можете продолжать, разделяя вашу разработку, по одной функции на ветку, сохраняя одинаковые имена пакетов для обеих (чтобы легко объединять исправления из одного в другой).
Но затем, чтобы протестировать и развернуть одну из этих двух версий, у вас может быть сценарий, отвечающий за переименование пакетов, перекомпиляцию, упаковку (jar) и развертывание результата в целевой тестовой среде.
Пара очень хороших статей о стратегиях ветвления: http://codicesoftware.blogspot.com/2010/03/branching-strategies.html http://nvie.com/git-model