Oprogramowanie 2-Version: Najlepsze podejście VCS?

Question

Przypuszczam, że lepiej wytłumaczyłbym moją sytuację:

Jestem w trakcie opracowywania oprogramowania i jestem na etapie, na którym chciałbym podzielić mój projekt na dwie gałęzie, które różnią się funkcjonalnością . Zdarza się, że ta aplikacja to aplikacja dla systemu Android, którą będę wdrażać na rynku, która ma ograniczenie, że każda aplikacja musi mieć unikalny identyfikator pakietu (rozsądny, nie?).

Moje obecne podejście polegało na sklonowaniu repozytorium git mojego oryginalnego projektu, ale powoduje to problemy z nazwami pakietów. Chcę, aby system był wystarczająco odporny, aby poprawka/nowa funkcja w jednym oddziale scalała się z inną gałęzią, ale tylko wtedy, gdy tego chcę.

Czy ktoś ma jakieś sugestie?

Answer 1

Sam zajmuję się tym przypadkiem w przypadku płatnej aplikacji i wersji próbnej, które mają tę samą bazę kodów. Używam SVN, ale może działać dowolne oprogramowanie do kontroli wersji obsługujące rozgałęzienia.

Stworzyłem oddział dla wersji próbnej z bagażnika.

Następnie zmodyfikowałem wersję AndroidaManifest.xml wersji testowej, aby zmienić nazwę pakietu, dodając końcówkę .trial na końcu. Musiałem również zaktualizować wszystkie pliki java działania, aby odnieść się do poprawnej klasy R.

My zapłacił aplikacja pakietu jest com.hewittsoft.baby
Moja trial aplikacji pakietu jest com.hewittsoft.baby.trial

W moich działaniach na gałęzi próbna i robię to

import com.hewittsoft.baby.trial.R; 

i powoduje to wszelkie odniesienia do R.id.textField (lub cokolwiek innego) do działania.

Po wykonaniu tych czynności mogę rozwijać się na głównej gałęzi, a następnie scalać wszelkie zmiany w wersji próbnej bez zbytniego bólu.

Answer 2

Jeśli jedynym problemem jest problem zarządzania opakowaniami i zwolnieniami, można wyizolować te kroki (zmienić nazwę pakietu i przetestować go w środowisku docelowym) z cyklu historiowania w ramach jednego repozytorium Git.

Możesz przejść dalej, oddzielić swój rozwój, jedną funkcję na gałąź, zachowując te same nazwy pakietów dla obu (aby łatwo scalać poprawki z jednej na drugą).
Jednak aby przetestować i wdrożyć jedną z tych dwóch wersji, można mieć skrypt odpowiedzialny za zmianę nazwy pakietów, rekompilację, pakowanie (jar) i wdrożenie wyniku w docelowym środowisku testowym.

Answer 3

Kilka bardzo dobrych artykułów na temat strategii rozgałęziających: http://codicesoftware.blogspot.com/2010/03/branching-strategies.html http://nvie.com/git-model