Uwaga: Moje pytanie koncentruje się na moim konkretnym problemie (który dotyczy Liferay), ale mam nadzieję, że może być użyteczne dla każdego, kto musi utrzymywać różne wersje tego samego projektu na git.

Pracuję w firmie, która pisze wiele wtyczek do Liferay Portal . Wtyczki te (portlety, motywy itp.) Są zwykle wielokrotnego użytku i, oczywiście, powinny być aktualizowane w przypadku nowych wersji portalu.

Jednak zwykle trzeba przeprowadzić migrację, powiedzmy, portletu, do nowej wersji Liferay i zachować jej poprzednią wersję. Ponadto często musimy tworzyć bardzo szczegółowe dostosowania dla niektórych klientów, co nie ma sensu dodawać do „głównej wersji”.

Te wymagania komplikują naszą pracę, ale na szczęście możemy przyjąć pewne uproszczenia. Na przykład wtyczki są często aktualizowane tylko przez jednego programistę na raz. Bardzo rzadko zdarza się, że do wtyczki są dodawane dwie lub więcej funkcji jednocześnie.

Teraz migrujemy do Gitorious . Staramy się stworzyć model rozgałęzienia dla takiego scenariusza.

Mój model

Zaproponowałem:

1. Każda wtyczka miałaby własne repozytorium w Gitorious w ramach projektu. Na przykład portlet do wyświetlania kociąt miałby kittens-portletrepozytorium w liferay-portletsprojekcie.
2. Tworząc nową wtyczkę, utwórz ją w oddziale o nazwie zgodnej z wersją Liferay (na przykład lf5.2).
3. Za każdym razem zmiana dokonywana jest na wtyczce, aktualizacja jest zatwierdzony i wdrożony do produkcji, oznacz wtyczkę z wersji (na przykład lf5.2v1, lf5.2v2itp.) *
4. Za każdym razem, gdy wtyczka powinna zostać przeniesiona do nowej wersji Liferay, rozgałęziamy najnowszą wersję (tworząc na przykład gałąź lf6.0).
5. Po rozpoczęciu produkcji szef nowego oddziału otrzyma tag, taki jak lf6.0v1.
6. Za każdym razem, gdy musimy dostosować wtyczkę w sposób specyficzny dla klienta, tworzymy oddział z nazwą klienta (na przykład, tworzymy oddział lf5.2clientcorpdla naszego klienta „ClientCorp Inc.”)

Jest to niezwykły model: nie miałby masterwielu niepowiązanych gałęzi. Tak przypuszczam , że repozytorium z takim modelem wyglądałoby tak:

Znajomy uznał ten system za dość złożony i podatny na błędy. Zasugerował doskonały i popularny model Vincenta Driessena , który nadal uważałem za trudniejszy w zarządzaniu i wymagający dyscypliny. Oczywiście jest świetny (i przetestowany!), Ale wydaje się zbyt skomplikowany w naszej sytuacji.

Model mojego przyjaciela

Potem zasugerował inny model: będziemy mieli repozytorium dla każdej wtyczki w wersji Liferay (więc zaczniemy tworzyć a, kittens-lf5.2-portleta następnie a kittens-lf6.0-portlet), każda z mastergałęzią i developgałęzią. masterBędzie zawsze gotowy do wdrożenia. (Lub może być na odwrót masteri stable, jak sugeruje Steve Losh ).

To bardzo proste, ale nie podobał mi się ten system:

1. może zaowocować ogromną ilością repozytoriów w projekcie, co utrudni przeglądanie Gitorious.
2. Nazwa katalogu projektu jest istotna. Jeśli ktoś sklonuje repozytorium do katalogu kittens-lf6.0-portleti wygeneruje WAR za pomocą mrówki (jak zwykle), nazwa WAR również będzie kittens-lf6.0-portlet. Stare wersje tego portletu (nazwane kittens-portletna przykład) byłyby traktowane jako różne (i prawdopodobnie brakujące) portlety w zaktualizowanym portalu. Trochę ostrożności można tego uniknąć, ale wolałbym tego uniknąć.
3. Różne wersje tej samej wtyczki zostałyby rozdzielone. Złamię mi serce :(
4. kittens-lf6.0-portlet to chyba brzydka nazwa repozytorium.

Podejrzewam, że dwa ostatnie punkty - które są również dwoma bardziej subiektywnymi - są głównym powodem mojej niechęci. Niemniej jednak wszystkie cztery zarzuty pozostają w mocy.

OTOH, moja własna propozycja wydaje mi się dziwna i zastanawiam się, czy są w niej ukryte błędy. Git OT3rdH jest tak potężny i elastyczny, że myślę, że nie powinienem się wstydzić odkrywania jego możliwości.

Więc pytam:

1. Jaki byłby najlepszy model? Moja propozycja? Model mojego przyjaciela? Teraz tradycyjny system Vincenta Driessena?
2. Jaki inny model rozgałęziania sugerowałbyś?
3. Jeśli uważasz, że mój model jest zły, dlaczego tak uważasz? Chciałbym dowiedzieć się, jakie są wady i martwe punkty.

* Właściwie wolałbym otagować zatwierdzenie wersją taką jak, v1ale najwyraźniej znacznik w git nie ma zasięgu w gałęzi - to znaczy, nie mogłem mieć 1 v1znacznika lf5.2i drugiego w lf6.0- więc muszę nazwać Oddział. Czy to prawda BTW?

Jeśli dobrze to przeczytam, odgałęzienia są w zasadzie jednorazowym odchyleniem od głównej linii rozwoju, nigdy nie zamierzałem zostać z powrotem połączony z główną linią, a postępy w głównej linii nigdy nie zostaną zastosowane do tych gałęzi. Jedynym odchyleniem byłoby to, że poprawki błędów odpowiednie dla wersji, na której opierała się gałąź, wymagają zastosowania do gałęzi.

Odpowiedź zależy teraz od codziennego przepływu pracy, liczba programistów pracujących nad jednym oddziałem lub liczba zmian to czerwone znaki. Widzę twoją podstawową potrzebę, aby wiedzieć, które gałęzie otrzymują aktualizację błędu od zmiany głównej gałęzi i myślę, że połączone repozytorium z gałęziami będzie bardziej wydajne, ponieważ wszystko jest w jednym miejscu. Gdyby nigdy nie było potrzeby zapylania krzyżowego, egzekwowałyby to osobne repozytoria, ale ten scenariusz nie pasuje do rzeczywistości twojego projektu, tak jak rozumiem.

Model Driessen sprawdziłby się dobrze, gdyby Twój projekt musiał połączyć gałęzie z powrotem w główny kierunek rozwoju, ale nie potrzebujesz tego. Mimo to uważam, że warto pracować nad koncepcją InDevelopment i StableRelease, jeśli pracujesz nad produktem, który jest dostępny.

Podsumowując, myślę, że twój projekt będzie działał dobrze z twoim modelem rozgałęzienia plus odrobiną Driessen dla twojej głównej linii. Twój przebieg może się różnić; Zawsze pracowałem z gałęzią „w oczekiwaniu na wydanie”, która zamienia się w gałąź „na żywo” i osobną „kolejną wersją”, które wymagają zapylenia krzyżowego poprawek i zmian w różnych punktach, więc moje postrzeganie może być stronnicze.

Uderza mnie to, że każdy portlet ma własne repozytorium (ale twoja historia może nie być kompletna). Osobiście stworzyłbym repozytorium dla każdego projektu. Projekty często mają wiele portletów i wszystkie są budowane w tej samej serii z tą samą wersją Liferay. Każdy projekt może być duplikatem istniejącego projektu opartego na innej wersji Liferay, ale podzieliłbym produkt tylko wtedy, gdy różnice są zbyt duże. Jeśli kompilacja działa przeciwko Liferay 5.1 i 5.2, nie podzieliłbym projektu. Użyłbym skryptów lub Maven (lub obu), aby wszystko działało. Korzystałbym z Wiki (lub Trello) do zarządzania każdym produktem i z jaką wersją Liferay można go zbudować.

Nawiasem mówiąc: jestem programistą Java, specjalistą Maven, specjalistą ds. Kompilacji i mam doświadczenie z Liferay i innymi serwerami portalu (IBM WebSphere i Glassfish).

Ale to tylko moje 0,02 €.