Git migration

[Jakub Bogusz]

On Fri, Jun 29, 2012 at 09:59:42PM +0200, Jacek Konieczny wrote:
> On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote:
> > no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego nurtu pld-th?
> > 
> > 1).
> > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak pokazalem wyzej)
> > i nie nadpisujemy/kasujemy devel.
> 
> Czemu się tak ograniczać? Można rozwijać pakiet w różnych kierunkach
> przecież. 'devel' nic nie mówi i nawet nie wiadomo co tam miałoby być.
> 
> > 2).
> > dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do jakiegos next-X.Y
> > (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi (kasacja?).
> 
> Wybieram tę opcję. Topic branch. W tym przypadku 'topikiem' jest jakieś
> developerskie wydanie softu. 
> 
> Bo mergowaniu takiego brancha do master, gdy wersja staje się aktualną
> lub przestarzałą, to IMHO można go skasować ??? znaczy usunąć nazwę z
> repo, bo w historii odgałęzienie zostanie.
> I nie będzie problemów jak z resetem 'uniwersalnego' brancha 'devel', że
> po jakimś czasie ktoś robi 'git pull' i bzdury wychodzą.
> 
> > chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych upodoban,
> > bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok dzialania.
> 
> Dla częstych przypadków, jak pakiet z developerską/testową wersją softu
> dobrze jest ustalić jakieś reguły. IMHO wystarczy numer wersji jako
> nazwa brancha.

IMO lepszy byłby schemat nazw pozwalający od razu odróżnić charakter
gałęzi (wersje rozwojowe, wersje stabilne starsze niż master itp.),
bez oglądania historii gałęzi/wersji przed i po odgałęzieniu.
O ile w danej chwili może być oczywiste, co jest wersją rozwojową, a co
starą stabilną - to po paru latach już nie.


-- 
Jakub Bogusz    http://qboosh.pl/