Po pierwsze, jak zauważają @AndrewFinnell i @KenLiu, w SVN same nazwy katalogów nic nie znaczą - „trunk, gałęzie i znaczniki” są po prostu powszechną konwencją stosowaną przez większość repozytoriów. Nie wszystkie projekty używają wszystkich katalogów (dość często nie używa się w ogóle „znaczników”) i w rzeczywistości nic nie powstrzymuje cię przed nazywaniem ich tak, jak chcesz, chociaż łamanie konwencji jest często mylące.
Opiszę prawdopodobnie najczęstszy scenariusz użycia gałęzi i tagów oraz podam przykładowy scenariusz ich użycia.
Bagażnik : Główny obszar rozwoju. To jest miejsce, w którym znajduje się Twoja kolejna ważna wersja kodu i na ogół ma wszystkie najnowsze funkcje.
Oddziały : Za każdym razem, gdy wydajesz wersję główną, tworzona jest gałąź. Pozwala to na naprawę błędów i wydanie nowej wersji bez konieczności wydawania najnowszych - prawdopodobnie niedokończonych lub nieprzetestowanych - funkcji.
Tagi : za każdym razem, gdy wydajecie wersję (wydanie końcowe, kandydaci do wydania (RC) i bety), tworzycie dla niej tag. To daje ci kopię kodu w momencie, w jakim była w tym stanie, pozwalając ci wrócić i odtworzyć wszelkie błędy w razie potrzeby w poprzedniej wersji lub ponownie wydać poprzednią wersję dokładnie tak, jak była. Gałęzie i znaczniki w SVN są lekkie - na serwerze nie tworzy pełnej kopii plików, tylko znacznik z napisem „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 tagów dla dowolnego wydanego kodu. Jak powiedziałem wcześniej, tagi są często pomijane, a zamiast tego dziennik zmian lub inny dokument wyjaśnia numer wersji po wydaniu.
Załóżmy na przykład, że zaczynasz nowy projekt. Zaczynasz pracować w „pniu”, nad czym ostatecznie zostanie wydana wersja 1.0.
- trunk / - wersja rozwojowa, wkrótce będzie 1.0
- oddziały / - puste
Po zakończeniu 1.0.0 rozgałęziasz pień do nowej gałęzi „1.0” i tworzysz znacznik „1.0.0”. Teraz trwają prace nad tym, co ostatecznie będzie 1.1.
- trunk / - wersja rozwojowa, wkrótce 1.1
- wersja wydania oddziałów / 1.0 - 1.0.0
- tags / 1.0.0 - 1.0.0 wersja wydania
Napotykasz kilka błędów w kodzie, naprawiasz je w bagażniku, a następnie łączysz poprawki z gałęzią 1.0. Możesz także zrobić coś przeciwnego i naprawić błędy w gałęzi 1.0, a następnie scalić je z powrotem do pnia, ale zwykle projekty trzymają się scalania tylko w jedną stronę, aby zmniejszyć szansę na coś pominięcia. Czasami błąd można naprawić tylko w wersji 1.0, ponieważ jest on przestarzały w wersji 1.1. To naprawdę nie ma znaczenia: chcesz się upewnić, że nie wydasz 1.1 z tymi samymi błędami, które zostały naprawione w 1.0.
- trunk / - wersja rozwojowa, wkrótce 1.1
- oddziały / 1.0 - nadchodzące wydanie 1.0.1
- tags / 1.0.0 - 1.0.0 wersja wydania
Gdy znajdziesz wystarczającą liczbę błędów (lub może jeden błąd krytyczny), decydujesz się na wydanie wersji 1.0.1. Stwórz więc tag „1.0.1” z gałęzi 1.0 i zwolnij kod. W tym momencie bagażnik będzie zawierał 1.1, a gałąź „1.0” zawiera kod 1.0.1. Następnym razem, gdy wydasz aktualizację do wersji 1.0, będzie to wersja 1.0.2.
- trunk / - wersja rozwojowa, wkrótce 1.1
- oddziały / 1.0 - nadchodzące wydanie 1.0.2
- tags / 1.0.0 - 1.0.0 wersja wydania
- tags / 1.0.1 - 1.0.1 wersja wydania
W końcu jesteś prawie gotowy do wydania 1.1, ale najpierw chcesz zrobić wersję beta. W takim przypadku prawdopodobnie utworzysz gałąź „1.1” i tag „1.1beta1”. Teraz praca nad tym, co będzie 1.2 (lub 2.0), jest kontynuowana w pniu, ale praca nad 1.1 trwa w gałęzi „1.1”.
- trunk / - wersja rozwojowa, wkrótce będzie 1.2
- oddziały / 1.0 - nadchodzące wydanie 1.0.2
- oddziały / 1.1 - nadchodzące wydanie 1.1.0
- tags / 1.0.0 - 1.0.0 wersja wydania
- tags / 1.0.1 - 1.0.1 wersja wydania
- tags / 1.1beta1 - 1.1 beta 1 wersja wydania
Po wydaniu wersji 1.1 finalnej wykonujesz tag „1.1” z gałęzi „1.1”.
Możesz także nadal utrzymywać 1.0, przenosząc poprawki błędów między wszystkimi trzema gałęziami (1.0, 1.1 i magistralą). Ważne jest to, że dla każdej głównej wersji oprogramowania, którą zarządzasz, masz gałąź, która zawiera najnowszą wersję kodu dla tej wersji.
Inne zastosowanie gałęzi dotyczy funkcji. To tutaj rozgałęziasz pień (lub jedną z gałęzi wydania) i pracujesz nad nową funkcją w izolacji. Po zakończeniu funkcji scalasz ją z powrotem i usuwasz gałąź.
- trunk / - wersja rozwojowa, wkrótce będzie 1.2
- oddziały / 1.1 - nadchodzące wydanie 1.1.0
- branch / ui-rewrite - gałąź eksperymentalna
Chodzi o to, gdy pracujesz nad czymś destrukcyjnym (co powstrzymałoby lub przeszkadzałoby innym w wykonywaniu ich pracy), czymś eksperymentalnym (który może nawet tego nie zrobić) lub po prostu czymś, co zajmuje dużo czasu (i obawiasz się, że jeśli utrzymasz wydanie 1.2, gdy będziesz gotowy do rozgałęzienia 1.2 z pnia), możesz to zrobić w oddziale. Zasadniczo aktualizujesz go za pomocą łącza, cały czas łącząc z nim zmiany, co ułatwia ponowną integrację (scalanie z powrotem do łącza) po zakończeniu.
Zauważ też, że schemat wersji, którego tu użyłem, jest tylko jednym z wielu. Niektóre zespoły wprowadzałyby poprawki błędów / wydania konserwacyjne w wersji 1.1, 1.2 itd., A główne zmiany w wersji 1.x, 2.x itd. Wykorzystanie tutaj jest takie samo, ale można nazwać gałąź „1” lub „1 .x ”zamiast„ 1.0 ”lub„ 1.0.x ”. (Poza tym wersja semantyczna jest dobrym przewodnikiem po tym, jak robić numery wersji).
