Jak poddać różne wersje biblioteki kontroli wersji? Czy używasz tagów? Czy oddziały? Lub inna metoda?

Niedawno zacząłem poddawać mój kod kontroli wersji (w laboratorium, nad którym pracuję, pod SVN, a moje własne kody w github (oczywiście z git)). Przed użyciem kontroli wersji robiłem coś takiego. Miałem folder z nazwą biblioteki, w wielu folderach z numerem wersji. Za każdym razem, gdy chciałem zacząć pracować nad nowszą wersją, robiłem kopię ostatniej wersji, zmieniałem nazwę na nową wersję i zaczynałem wdrażanie.

Wydaje się to jednak zbyteczne, gdy folder jest objęty kontrolą wersji. Oprócz redundancji, jeśli ktoś chce uzyskać najnowszą wersję, pobierałby wszystkie wersje, gdyby tylko imports / clones.

Teraz widzę wiele sposobów, aby to zrobić za pomocą kontroli wersji, ale ponieważ jestem nowy, nie wiem, który byłby łatwiejszy w utrzymaniu.

Metoda 1: Używanie tagów

Jeśli poprawnie zrozumiałem tagi, miałbyś swoją główną gałąź, zatwierdzasz każdą wprowadzoną zmianę i otagujesz je wersją. Następnie, gdy chcesz uzyskać jego roboczą kopię, otrzymujesz ten z pewnym znacznikiem. (Popraw mnie, jeśli się mylę)

Metoda 2: Wersje rozgałęziające

W tej metodzie główną gałęzią byłaby gałąź programistyczna. Co jakiś czas tworzona jest stabilna wersja (powiedzmy v1.2.0), tworzysz gałąź dla tej wersji i nigdy się do niej nie zobowiązujesz. W ten sposób, jeśli chcesz pobrać określoną wersję, otrzymasz kod z tej gałęzi. Chociaż powiedziałem, że nigdy się na to nie zgadzasz, być może możliwe będzie poprawianie błędów i zatwierdzanie w gałęzi starej wersji, aby utrzymać działanie starej wersji. Na przykład, jeśli aktualna wersja jest v2.0, ale są ludzie, którzy chcą z niej korzystać v1.2, możesz uzyskać inną gałąź v1.2, a mianowicie v1.2.1i zatwierdzić poprawki błędów, lub po prostu zachować tę samą wersję v1.2i po prostu zatwierdzić poprawki błędów.

Więc oddziały wyglądałyby tak:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

W ten sposób masz oddziały dla każdej drobnej aktualizacji wersji. (Należy zauważyć, że na powyższym wykresie v1.2.1 i v2.2.2 lub utworzone po wydaniu v2.0.0, więc nie były częścią rozwoju między v1.2.0 a v2.0.0. Pomyśl o tym jako o pomocy dla starszych wersji)

Metoda 3: Rozwój gałęzi

Ta metoda jest przeciwieństwem poprzedniej. Główną gałęzią byłaby najnowsza stabilna wersja. Ilekroć pracujesz nad nową wersją, tworzysz gałąź (dla programistów), pracujesz nad kodem, a gdy jest stabilny, łączysz go z gałęzią główną.

W takim przypadku gałęzie wyglądałyby tak:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

Prawdopodobnie trzeba to zrobić w połączeniu z tagami, prawda?

Pytanie!

Tak czy inaczej, moje pytanie jest oparte na twoim doświadczeniu, która z tych metod okazuje się bardziej praktyczna? Czy istnieje znana najlepsza metoda (której prawdopodobnie nie wymyśliłem sam)? Jak często się to robi?

Tagi i gałęzie nie są wzajemne, możesz (i IMO zwykle powinna) używać ich obu. Tagi służą do oznaczania kamieni milowych w rozwoju. Np otwarciu oddziału dla wersji 1.2 swojego produktu, a zaznaczyć v1.2 Beta, RC1, RC2, Final(a następnie, w razie potrzeby, SP1itd.) Ze znacznikami na tej samej gałęzi.

Osobiście wolę Metodę 2 jako podejście domyślne (chociaż staram się unikać wielu poziomów gałęzi, aby życie było jak najprostsze). Metoda 1 po prostu nie zadziała w prawdziwym życiu - tagi nie wystarczą, potrzebujesz gałęzi. Metoda 3 jest nieelastyczna, ponieważ ma zawsze tylko jedną stabilną wersję, więc (chyba że połączysz ją z Metodą 2), nie możesz utrzymywać wielu (najnowszych i starszych) wersji równolegle. Jest to wymagane w przypadku prawie wszystkich projektów w prawdziwym życiu - podczas pracy nad wersją 2 nadal powinno być możliwe publikowanie poprawek / aktualizacji do wersji 1.9, a często nawet wcześniejszych wersji. Oczywiście wiele zależy od rodzaju zastosowania. Tworzymy aplikację internetową, więc w danym momencie jest tylko jedna wersja produkcyjna, wciąż często żonglujemy 3 różnymi wersjami (jedna w wersji produkcyjnej, jeden jest w UAT i szykuje się do wdrożenia, jeden to najnowsza wersja na pniu). Może być znacznie bardziej skomplikowany w przypadku aplikacji komputerowej / klienckiej, w której wiele starszych wersji jest używanych - i utrzymywanych - równolegle.

Miałem folder z nazwą biblioteki, w wielu folderach z numerem wersji.

Jest to skuteczne, jak zauważysz, niewłaściwe podejście, ponieważ masz już kontrolę wersji, aby ... kontrolować wersje.

Teraz różne techniki, które wymieniasz, wydają się w równym stopniu prawidłowe. Możesz przeczytać bardzo szczegółowy artykuł, Kontrola źródła wykonano w prawo , który zawiera informacje o tagach i gałęziach.

Te trzy metody nie wykluczają się wzajemnie i należy je połączyć, aby jak najlepiej wykorzystać kontrolę wersji.

Ze swojej strony użyłbym domyślnie kombinacji metody 1 i 3, tj. Rozwijał się w elemencie lub gałęzi programistycznej, dopóki funkcja nie będzie gotowa do produkcji, a następnie wróci do linii głównej. W ten sposób pień zawsze reprezentuje bieżący stan stabilnego rozwoju, który ma być używany, i można go bezpiecznie połączyć za pomocą projektów svn: external. Po wydaniu wersji oznacz ją.

Rozgałęziałbym się tylko na żądanie, to znaczy, gdy starsze wersje biblioteki mają błąd, który należy naprawić. Możesz łatwo utworzyć tę gałąź z tagu uszkodzonej wersji. Nie rozgałęziając się niepotrzebnie, utrzymujesz niską liczbę gałęzi i masz szybki przegląd krawędzi krwawienia, które należy zachować (pień i wszystkie gałęzie).

Użyłbym metody 2 . Użyłem tego i uznałem, że jest to skuteczny sposób zarządzania i utrzymywania wielu wersji, jednocześnie umożliwiając dalszy rozwój. Możesz także użyć tagów w połączeniu z tą metodą, jeśli ich potrzebujesz.

Zobacz moją odpowiedź tutaj, aby uzyskać więcej informacji na temat korzystania z rozgałęziania w celu utrzymania wielu wersji.