Co oznaczają gałąź, znacznik i pień w repozytoriach Subversion?

Hmm, nie jestem pewien, czy zgadzam się z tym, że tag Nick re jest podobny do gałęzi. Tag to tylko znacznik

• Trunk stanowiłby główny element rozwoju, rozpoczynający się od początku projektu aż do chwili obecnej.

• Oddział będzie oddziałem kopia kodu pochodząca z określonego punktu łącza, używana do wprowadzania większych zmian w kodzie przy jednoczesnym zachowaniu integralności kodu w łączu. Jeśli główne zmiany działają zgodnie z planem, zwykle są one ponownie łączone w bagażniku.

• Tag będzie punkt w czasie na pniu lub gałęzi, który chcesz zachować. Dwa główne powody zachowania byłyby takie, że albo jest to główna wersja oprogramowania, czy to alfa, beta, RC czy RTM, albo jest to najbardziej stabilny punkt oprogramowania przed wprowadzeniem głównych poprawek w pniu.

W projektach open source główne gałęzie, które nie zostały zaakceptowane w pniu przez interesariuszy projektu, mogą stać się bazą dla forków — np. całkowicie odrębnych projektów, które mają wspólne pochodzenie z innym kodem źródłowym.

Poddrzewa gałęzi i znaczników odróżniają się od pnia w następujący sposób:

Subversion umożliwia administratorom tworzenia skryptów przechwytujących, które są uruchamiane w celu wykonania, gdy wystąpią określone zdarzenia; na przykład zatwierdzenie zmiany w repozytorium. Bardzo często w typowej implementacji repozytorium Subversion traktowana jest każda ścieżka zawierająca „/tag/” jako zabezpieczona przed zapisem po utworzeniu; ostateczny wynik jest taki, że raz utworzone tagi są niezmienne (przynajmniej dla „zwykłych” użytkowników). Odbywa się to poprzez skrypty przechwytujące, które wymuszają niezmienność, uniemożliwiając dalsze zmiany, jeśli tag jest węzłem nadrzędnym zmienionego obiektu.

Subversion ma także dodatkowe funkcje, począwszy od wersji 1.5, związane z „śledzeniem scalania gałęzi”, dzięki czemu zmiany wprowadzone do oddziału mogą zostać scalone z powrotem do magistrali z obsługą przyrostowego, „inteligentnego” łączenia.

Po pierwsze, jak zauważają @AndrewFinnell i @KenLiu, w SVN same nazwy katalogów nic nie znaczą - „pień, gałęzie i znaczniki” to po prostu powszechna konwencja używana w większości repozytoriów. Nie wszystkie projekty korzystają ze wszystkich katalogów (dość powszechne jest nieużywanie „tagów” ​​w ogóle) i tak naprawdę nic nie stoi na przeszkodzie, aby nazywać je jakkolwiek chcesz, choć łamanie konwencji jest często mylące.

Opiszę prawdopodobnie najczęstszy scenariusz użycia gałęzi i znaczników oraz podam przykładowy scenariusz ich użycia.

• Pień: główny obszar rozwoju. Tutaj znajduje się następna główna wersja kodu, która zawiera wszystkie najnowsze funkcje.

• Oddziały: za każdym razem, gdy wypuszczasz wersję główną, tworzona jest gałąź. Pozwala to na naprawianie błędów i tworzenie nowej wersji bez konieczności wydawania najnowszych – prawdopodobnie niedokończonych lub nieprzetestowanych – funkcji.

• Tagi: za każdym razem, gdy publikujesz wersję (wersję ostateczną, wersję kandydującą do wydania (RC) i wersję beta), tworzysz dla niej tag. Daje to kopię kodu w danym momencie w takiej postaci, w jakiej znajdował się w tym stanie, umożliwiając powrót i odtworzenie wszelkich błędów, jeśli to konieczne, w poprzedniej wersji lub ponowne wydanie poprzedniej wersji dokładnie w takiej postaci, w jakiej była. Gałęzie i znaczniki w SVN są lekkie - na serwerze nie tworzy pełnej kopii plików, a jedynie znacznik mówiący „te pliki zostały skopiowane w tej wersji”, który zajmuje tylko kilka bajtów. Mając to na uwadze, nigdy nie powinieneś martwić się tworzeniem tagu dla dowolnego wydanego kodu. Jak powiedziałem wcześniej, znaczniki są często pomijane i zamiast tego w dzienniku zmian lub innym dokumencie wyjaśnia się numer wersji w momencie wydania wydania.

Załóżmy na przykład, że rozpoczynasz nowy projekt. Rozpoczynasz pracę w „trunk”, nad tym, co ostatecznie zostanie wydane jako wersja 1.0.

• trunk/ - wersja rozwojowa, wkrótce 1.0
• gałęzie/ - puste

Po zakończeniu wersji 1.0.0 rozgałęziasz pień do nowej gałęzi „1.0” i tworzysz znacznik „1.0.0”. Teraz w bagażniku trwają prace nad wersją 1.1.

• trunk/ - wersja rozwojowa, wkrótce 1.1
• branże/1.0 – wersja 1.0.0
• tags/1.0.0 – wersja 1.0.0

Natrafiasz na błędy w kodzie i naprawiasz je w bagażniku, a następnie scalasz poprawki z gałęzią 1.0. Możesz także zrobić odwrotnie i naprawić błędy w gałęzi 1.0, a następnie połączyć je z powrotem do magistrali, ale często projekty trzymają się łączenia tylko w jedną stronę, aby zmniejszyć ryzyko przeoczenia czegoś. Czasami błąd można naprawić tylko w wersji 1.0, ponieważ w wersji 1.1 jest on przestarzały. To naprawdę nie ma znaczenia: chcesz się tylko upewnić, że nie wydasz wersji 1.1 z tymi samymi błędami, które zostały naprawione w wersji 1.0.

• trunk/ - wersja rozwojowa, wkrótce 1.1
• gałęzie/1.0 - nadchodząca wersja 1.0.1
• tags/1.0.0 – wersja wydania 1.0.0

Gdy znajdziesz wystarczającą liczbę błędów (lub być może jeden krytyczny), decydujesz się na wydanie wersji 1.0.1. Tworzysz więc tag „1.0.1” z gałęzi 1.0 i publikujesz kod. W tym momencie pień będzie zawierał wersję 1.1, a gałąź „1.0” będzie zawierała kod 1.0.1. Następnym razem, gdy wypuścisz aktualizację do wersji 1.0, będzie to wersja 1.0.2.

• trunk/ - wersja rozwojowa, wkrótce 1.1
• gałęzie/1.0 - nadchodząca wersja 1.0.2
• tags/1.0.0 – wersja wydania 1.0.0
• tags/1.0.1 – wersja 1.0.1

Ostatecznie jesteś prawie gotowy do wydania wersji 1.1, ale najpierw chcesz przeprowadzić wersję beta. W tym przypadku prawdopodobnie wykonasz gałąź „1.1” i tag „1.1beta1”. Teraz prace nad wersją 1.2 (lub może 2.0) są kontynuowane w bagażniku, ale prace nad wersją 1.1 są kontynuowane w gałęzi „1.1”.

• trunk/ - wersja rozwojowa, wkrótce 1.2
• gałęzie/1.0 - nadchodzące wydanie 1.0.2
• branże/1.1 – nadchodząca wersja 1.1.0
• tags/1.0.0 – wersja wydania 1.0.0
• tags/1.0.1 – wersja wydania 1.0.1
• tags/1.1beta1 – wersja 1.1 beta 1

Po wydaniu wersji finalnej 1.1 tworzysz tag „1.1” z gałęzi „1.1”.

Jeśli chcesz, możesz także nadal utrzymywać wersję 1.0, przenosząc poprawki błędów między wszystkimi trzema gałęziami (1.0, 1.1 i trunk). Ważnym wnioskiem jest to, że dla każdej głównej wersji oprogramowania, którą utrzymujesz, masz gałąź zawierającą najnowszą wersję kodu dla tej wersji.

Innym zastosowaniem gałęzi są funkcje. W tym miejscu rozgałęziasz pień (lub jedną z gałęzi wydań) i pracujesz w izolacji nad nową funkcją. Po ukończeniu funkcji scalasz ją ponownie i usuwasz gałąź.

• trunk/ - wersja rozwojowa, wkrótce 1.2
• gałęzie/1.1 - nadchodzące wydanie 1.1.0
• gałęzie/przepisywanie interfejsu użytkownika — gałąź funkcji eksperymentalnych

Pomysł polega na tym, że pracujesz nad czymś destrukcyjnym (co utrudniałoby innym pracę lub przeszkadzało innym w ich pracy), czymś eksperymentalnym (co może nawet nie przetrwać) lub po prostu czymś, co zajmuje dużo czasu (i boisz się, że wstrzymuje wydanie 1.2, kiedy będziesz gotowy do rozgałęzienia 1.2 z magistrali), możesz to zrobić w izolacji w oddziale. Ogólnie rzecz biorąc, aktualizujesz go za pomocą trunku, łącząc w nim zmiany przez cały czas, co ułatwia ponowną integrację (scalenie z powrotem do trunku), gdy skończysz.

Pamiętaj też, że schemat wersjonowania, którego tutaj użyłem, jest tylko jednym z wielu. Niektóre zespoły wprowadziłyby poprawki błędów/wydania konserwacyjne jako 1.1, 1.2 itd., a główne zmiany jako 1.x, 2.x itd. Użycie tutaj jest takie samo, ale możesz nazwać gałąź „1” lub „1 .x” zamiast „1.0” lub „1.0.x”. (Poza tym wersjonowanie semantyczne to dobry przewodnik na temat numerowania wersji).

Oprócz tego, co powiedział Nick, możesz dowiedzieć się więcej na stronie Streamed Lines: Branching Patterns for Parallel Software Development

Na tym rysunku main to pień, rel1-maint to gałąź, a 1.0 to znacznik.

Ogólnie (widok niezależny od narzędzia) gałąź jest mechanizmem używanym do równoległego programowania. SCM może mieć od 0 do n gałęzi. Subwersja ma wartość 0.

• Trunk to główna gałąź zalecane przez Subversion, ale w żaden sposób nie jesteś zmuszony do jego utworzenia. Można to nazwać „głównym” lub „wydaniem” albo w ogóle go nie mieć!

• Oddział reprezentuje wysiłek rozwojowy. Nigdy nie należy go nazywać na cześć zasobu (np. „vonc_branch”), ale po:

  • a purpose 'myProject_dev' or 'myProject_Merge'
  • obwód wydania „myProjetc1.0_dev” lub myProject2.3_Merge” lub „myProject6..2_Patch1”...
• #P4#

  #P5#

Tag jest ostateczny. Jego treść nigdy nie powinna się zmieniać. NIGDY. Kiedykolwiek. Zapomniałeś wiersza w notatce o wydaniu? Utwórz nowy tag. Przestarzały lub usuń stary.

Teraz dużo czytałem o „ponownym łączeniu tego i tego w takich i takich gałęziach, a następnie w końcu w gałęzi głównej”. Nazywa się to przepływem scalania i tutaj nie ma nic obowiązkowego. To nie dlatego, że masz gałąź główną, musisz ponownie scalić cokolwiek.

Zgodnie z konwencją, gałąź trunk może reprezentować bieżący stan rozwoju, ale dotyczy to prostego projektu sekwencyjnego, czyli projektu, który ma:

• brak opracowywania „z góry” (w celu przygotowania kolejnej, kolejnej wersji, co oznacza takie zmiany, że nie są one kompatybilne z obecnym rozwojem „pniaka”)
• brak masowej refaktoryzacji (w celu przetestowania nowego wyboru technicznego)
• brak długoterminowej konserwacji poprzedniej wersji

Ponieważ w przypadku jednego (lub wszystkich) tych scenariuszy otrzymujesz cztery „pnie”, cztery „bieżące zmiany”, i nie wszystko, co robisz w ramach tych równoległych prac rozwojowych, będzie koniecznie musiało zostać ponownie połączone w „pień”.

W SVN znacznik i gałąź są naprawdę podobne.

Tag = określony wycinek czasu, zwykle używany w przypadku wydań

Oddział = także określony wycinek czasu, w którym można kontynuować rozwój, zwykle używany w przypadku wersji głównych, takich jak 1.0, 1.5, 2.0 itd., a następnie po wydaniu oznaczasz gałąź. Dzięki temu możesz nadal obsługiwać wersję produkcyjną, jednocześnie wprowadzając istotne zmiany w pniu

Trunk = przestrzeń robocza dla programistów, tutaj powinien odbywać się cały rozwój, a następnie zmiany ponownie scalone z wydań gałęzi.

Tak naprawdę nie mają one żadnego formalnego znaczenia. Folder jest folderem dla SVN. Są ogólnie przyjętym sposobem organizacji projektu.

• Pień to miejsce, w którym trzymasz główną linię rozwoju. Folder gałęzi to miejsce, w którym możesz tworzyć gałęzie, które trudno wyjaśnić w krótkim poście.

• Gałąź jest kopią podzbioru projektu, nad którą pracujesz niezależnie od pnia. Może dotyczy to eksperymentów, które mogą donikąd nie prowadzić, a może dotyczy następnej wersji, którą później włączysz z powrotem do bagażnika, gdy stanie się stabilna.

• Folder tags służy do tworzenia oznaczonych kopii repozytorium, zwykle w punktach kontrolnych wydań.

Ale jak powiedziałem, dla SVN folder to folder. branch, trunk i tag to tylko konwencja.

Używam słowa „kopiuj” swobodnie. SVN tak naprawdę nie tworzy pełnych kopii rzeczy w repozytorium.

Pień główny to linia rozwojowa zawierająca najnowszy kod źródłowy i funkcje. Powinien zawierać najnowsze poprawki błędów, a także najnowsze funkcje dodane do projektu.

Odgałęzienia są zwykle używane do zrobienia czegoś poza pniem (lub inną linią rozwojową), co w przeciwnym razie zepsułoby kompilację. Nowe funkcje są często budowane w gałęzi, a następnie łączone z powrotem w pień. Gałęzie często zawierają kod, który niekoniecznie jest zatwierdzony dla linii rozwojowej, z której się rozgałęziają. Na przykład programista może spróbować optymalizacji czegoś w gałęzi i powrócić do linii rozwojowej dopiero wtedy, gdy optymalizacja będzie zadowalająca.

Tagi to migawki repozytorium w określonym czasie. Nie powinien nastąpić na nich żaden rozwój. Najczęściej używa się ich do zrobienia kopii tego, co zostało udostępnione klientowi, dzięki czemu można łatwo uzyskać dostęp do tego, czego używa klient.

Oto link do bardzo dobrego przewodnika po repozytoriach:

• HOWTO dotyczące kontroli źródła

Warto przeczytać także artykuły w Wikipedii.

Tak właśnie jest z tworzeniem oprogramowania, nie ma spójnej wiedzy na żaden temat, wydaje się, że każdy ma to na swój sposób, ale dzieje się tak dlatego, że i tak jest to stosunkowo młoda dyscyplina.

Oto mój prosty, prosty sposób,

trunk — katalog trunk zawiera najbardziej aktualny, zatwierdzony i połączony zbiór prac. Wbrew temu, co wielu przyznało, mój kufer służy wyłącznie do czystej, schludnej i zatwierdzonej pracy, a nie do obszaru rozwoju, ale raczej do obszaru wydawania.

W pewnym momencie, gdy wydaje się, że cały pień jest gotowy do wydania, zostaje on oznaczony i zwolniony.

oddziały – katalog oddziałów zawiera eksperymenty i bieżące prace. Praca pod gałęzią pozostaje tam do czasu zatwierdzenia połączenia z pniem. Dla mnie jest to obszar, w którym odbywa się cała praca.

Na przykład: mogę mieć gałąź iteracja-5 na piątą rundę rozwoju produktu, może gałąź prototyp-9 na dziewiątą rundę eksperymentów i tak NA.

tagi — katalog tagów zawiera migawki zatwierdzonych wydań gałęzi i łączy głównych. Za każdym razem, gdy oddział zostanie zatwierdzony do włączenia do pnia lub zostanie wydane zwolnienie pnia, pod znacznikami wykonywana jest migawka zatwierdzonego wydania oddziału lub pnia.

Przypuszczam, że dzięki tagom mogę dość łatwo przeskakiwać w czasie do interesujących mnie punktów.

Znalazłem ten świetny poradnik dotyczący SVN, gdy przeglądałem stronę internetową autora OpenCV 2 Książka kucharska dotycząca programowania aplikacji z zakresu widzenia komputerowego i pomyślałem, że powinienem się nią podzielić.

Zawiera tutorial, jak używać SVN i co oznaczają zwroty „trunk”, „tag” i „branch”.

Cytowane bezpośrednio z jego tutoriala:

Bieżąca wersja Twojego projektu oprogramowania, nad którą obecnie pracuje Twój zespół, zwykle znajduje się w katalogu o nazwie trunk. W miarę rozwoju projektu programista aktualizuje tę wersję, naprawia błędy, dodaje nowe funkcje) i przesyła swoje zmiany w tym katalogu.

W dowolnym momencie możesz chcieć zamrozić wersję i przechwycić migawkę oprogramowania w stanie, w jakim znajduje się na tym etapie rozwoju. Zwykle odpowiada to oficjalnym wersjom Twojego oprogramowania, na przykład tym, które będziesz dostarczać swoim klientom. Te migawki znajdują się w katalogu tags Twojego projektu.

Wreszcie, często przydatne jest utworzenie w pewnym momencie nowej linii rozwoju oprogramowania. Dzieje się tak np. wtedy, gdy chcesz przetestować alternatywną implementację, w której musisz zmodyfikować swoje oprogramowanie, ale nie chcesz przesyłać tych zmian do głównego projektu, dopóki nie podejmiesz decyzji, czy zaadoptujesz nowe rozwiązanie. Główny zespół może następnie kontynuować pracę nad projektem, podczas gdy inni programiści pracują nad prototypem. Umieściłbyś te nowe kierunki rozwoju projektu w katalogu o nazwie branże.

Katalog trunk jest katalogiem, który prawdopodobnie znasz najlepiej, ponieważ przechowuje się w nim najnowsze zmiany. Twoja główna baza kodu powinna znajdować się w bagażniku.

Katalog oddziałów służy do przechowywania oddziałów, czymkolwiek one są.

Katalog tags służy zasadniczo do oznaczania określonego zestawu plików. Robisz to w przypadku wydań, gdzie chcesz, aby „1.0” oznaczało pliki w tych wersjach, a „1.1” oznaczało pliki w tych wersjach. Zwykle nie modyfikuje się tagów po ich utworzeniu. Więcej informacji na temat tagów znajdziesz w Rozdziale 4. Rozgałęzianie i Łączenie (w Kontrola wersji z Subversion).

Jednym z powodów, dla których każdy ma nieco inną definicję, jest to, że Subversion implementuje zerową obsługę gałęzi i tagów. Subversion zasadniczo mówi: Przyjrzeliśmy w pełni funkcjonalnym odgałęzieniom i tagom w innych systemach i nie uznaliśmy ich za przydatne, więc niczego nie wdrożyliśmy. Po prostu wykonaj kopię do nowego katalogu z konwencją nazw zamiast. Wtedy oczywiście każdy może mieć nieco inne konwencje. Aby zrozumieć różnicę pomiędzy tagiem prawdziwym a zwykłą kopią + konwencją nazewnictwa, zobacz wpis w Wikipedii Tagi i gałęzie Subversion.

Tag = zdefiniowany wycinek czasu, zwykle używany w przypadku wydań

Myślę, że to właśnie zwykle rozumie się przez „tag”. Ale w Subversion:

Tak naprawdę nie mają one żadnego formalnego znaczenia. Folder jest folderem dla SVN.

co wydaje mi się dość mylące: system kontroli wersji, który nie wie nic o gałęziach ani znacznikach. Z punktu widzenia implementacji uważam, że sposób tworzenia „kopii” w Subversion jest bardzo sprytny, ale konieczność posiadania wiedzy na ten temat nazwałbym nieszczelna abstrakcja.

A może po prostu zbyt długo korzystałem z CVS.

Myślę, że część zamieszania wynika z różnicy między koncepcją tagu a implementacją w SVN. Dla SVN tag jest gałęzią będącą kopią. Modyfikowanie znaczników jest uważane za niewłaściwe i w rzeczywistości narzędzia takie jak TortoiseSVN ostrzeżeją cię, jeśli spróbujesz zmodyfikować cokolwiek za pomocą ../tags/.. na ścieżce.

Nie jestem do końca pewien, co to jest „znacznik”, ale gałąź jest dość powszechną koncepcją kontroli źródła.

Zasadniczo gałąź jest sposobem na pracę nad zmianami w kodzie bez wpływu na pień. Załóżmy, że chcesz dodać nową funkcję, która jest dość skomplikowana. Chcesz mieć możliwość sprawdzania wprowadzanych zmian, ale nie chcesz, aby wpływały one na łącze trunkingowe, dopóki nie skończysz z tą funkcją.

Najpierw utworzyłbyś oddział. Jest to w zasadzie kopia pnia z chwili utworzenia gałęzi. Następnie wykonywałbyś całą swoją pracę w oddziale. Wszelkie zmiany dokonane w gałęzi nie mają wpływu na pień, więc z pnia można nadal korzystać, umożliwiając innym dalszą pracę w nim (np. poprawianie błędów lub drobne ulepszenia). Po zakończeniu funkcji zintegrujesz gałąź z powrotem z pniem. Spowoduje to przeniesienie wszystkich zmian z gałęzi do pnia.

Istnieje wiele wzorów, których ludzie używają do tworzenia gałęzi. Jeśli masz produkt z wieloma wersjami głównymi obsługiwanymi jednocześnie, zazwyczaj każda wersja będzie gałęzią. Tam, gdzie pracuję, mamy oddział kontroli jakości i oddział produkcji. Przed udostępnieniem naszego kodu do kontroli jakości integrujemy zmiany w gałęzi kontroli jakości, a następnie wdrażamy stamtąd. Podczas wypuszczania na produkcję integrujemy gałąź QA z gałęzią Production, dzięki czemu wiemy, że kod działający na produkcji jest identyczny z tym, który przetestował QA.

Oto wpis Wikipedii na temat gałęzi, ponieważ prawdopodobnie wyjaśniają one wszystko lepiej niż ja . :)

Trunk: po ukończeniu każdego sprintu w Agile wychodzimy z produktem, który można częściowo wysłać. Te wydania są przechowywane w bagażniku.

Oddziały: wszystkie równoległe kody rozwojowe dla każdego trwającego sprintu są przechowywane w oddziałach.

Tagi: za każdym razem, gdy wypuszczamy wersję beta produktu, która jest częściowo możliwa do dostarczenia, tworzymy dla niej tag. Daje nam to kod, który był dostępny w tamtym momencie, co pozwala nam wrócić do tego stanu, jeśli będzie to wymagane w pewnym momencie programowania.

Dla osób zaznajomionych z GIT, master w GIT jest równoznaczny z trunkiem w SVN.

Branch i tag mają tę samą terminologię zarówno w GIT, jak i SVN.