Dlaczego do wersjonowania powinienem używać tagów, a nie gałęzi wydania / beta?

114

Używam git od około roku i chciałbym używać tagowania do, cóż, tagowania zatwierdzeń w różnych wersjach. Znalazłem wiele informacji na temat poleceń używanych do pracy z tagami, ale chciałbym wiedzieć, po co w ogóle używać tagowania, jeśli mogę po prostu utworzyć nową gałąź o nazwie 1.1.0i nie muszę zasłaniać mojego umysłu całością nowy zestaw poleceń git?

Musi być wiele dobrych powodów, dla których warto tagować zamiast rozgałęzienia, ale chciałbym wiedzieć, jakie to zalety.

git branch git-tag wufoo
źródło

Odpowiedzi:

96

Tagi są używane głównie do przyszłego odniesienia do konkretnej wersji projektu, poprzez oznaczenie zatwierdzenia. Oczywiście zawsze możesz użyć oddziałów, ale jeśli będziesz często zmieniać wersje, otrzymasz wiele nieużywanych lub rzadko używanych gałęzi.

W praktyce tagi i tak są gałęziami bez gałęzi, po prostu dodając sposób na odwołanie się do określonej wersji projektu, aby zmniejszyć złożoność.

Edycja: Oto dobry sposób na użycie gita, którego używam we wszystkich moich projektach.

Hakan Deryal
źródło
Heh (: To naprawdę świetny przepływ pracy, który obejmuje wszystkie możliwe rozwiązania.
Hakan Deryal
tak, widziałem już metodę nvie i byłem przez nią dość zdezorientowany. Niemniej jednak aspiruję do wdrożenia tego, gdy już to zrozumiem. Myślę, że z tagiem nie można przypadkowo zmienić kodu, zatwierdzić i nadal być w tej samej wersji. W przypadku gałęzi może się to zdarzyć nieumyślnie. Tagi wydają się być bezpieczniejszym sposobem oznaczania wydań.
wufoo
2
Piękno metody nvie polegało na tym, że początkowo nie musiałem jej rozumieć. Mogłem po prostu znaleźć sekcję dotyczącą tego, co chciałem zrobić, i wpisać polecenia. Po kilku chwilach stało się to naturalnie i po kilku dniach tańczyłem wokół gałęzi jak zawodowiec!
Killroy
Mając nadzieję, że zrozumiesz podejście gitflow, stosując je po prostu na ślepo, przegapisz wszystkie uproszczenia, które możesz zastosować w swojej sytuacji. A gitflow jest rzeczywiście nieodpowiedni dla większości zespołów: albo jest zbyt złożony, albo zbyt prosty.
toolforger
151

Znacznik jest niezmienny .

Podczas gdy możesz utworzyć gałąź o nazwie „1.0.0” - ty lub ktokolwiek z prawami do zatwierdzenia możesz również po prostu przesłać do tej gałęzi (celowo lub nie) i zmienić znaczenie 1.0.0.

Nie możesz tego zrobić z tagiem, kiedy już utworzysz tag - to wszystko; Tag 1.0.0 oznacza dokładnie to i nie można go zmienić * .

To główna praktyczna różnica między tagiem a gałęzią

* Możesz usunąć i odtworzyć tag, zmieniając w ten sposób tag, ale na pewno nie przez przypadek.

AD7six
źródło
18

Zwykle używam przepływu pracy, który obejmuje zarówno tagi, jak i gałęzie. Tagi są dobre do oznaczania wydanego kodu lub ważnych kompilacji programistycznych. Gałęzie są dobre do śledzenia wszystkich zmian istotnych dla określonej wersji.

Oto dobry opis tego typu przepływu pracy: http://nvie.com/posts/a-successful-git-branching-model/

Justin ᚅᚔᚈᚄᚒᚔ
źródło
18

Gałąź i znacznik to to samo (wskaźnik do zatwierdzenia, inaczej „ref” ), z wyjątkiem tego, że gałąź automatycznie przechodzi do następnego zatwierdzenia, podczas gdy znacznik pozostaje na zawsze 1 w tym samym zatwierdzeniu.

Tworząc wydanie, zazwyczaj chcesz zaznaczyć „migawkę” kodu, z którego to wydanie zostało zbudowane, i chcesz, aby było ono oznaczone w ten sposób, nawet jeśli nadal rozwijasz kod, więc użyjesz tagu.

Jeśli spróbujesz użyć do tego brancha, może on nieumyślnie przejść do innego zatwierdzenia, z którego wydanie nie zostało zbudowane.

1 O ile oczywiście nie usuniesz tagu.

UWAGA: Zdaję sobie sprawę, że to stare pytanie, ale czułem, że podobieństwo (i jedna kluczowa różnica) między gałęziami i tagami nie zostało rozwinięte w innych odpowiedziach tak wyraźnie, jak mogłoby być.

Branko Dimitrijevic
źródło
Szanowny @downvoter, czy jest jakiś konkretny powód negatywnego głosu?
Branko Dimitrijevic
Nie przegłosowałem Twojej odpowiedzi, ale co masz na myśli mówiąc „gałąź automatycznie przechodzi do następnego zatwierdzenia”? Gałęzie nie są automatycznie przenoszone do żadnego zatwierdzenia. Uruchomienie git commitaktualizuje nagłówek pobranej gałęzi, aby odnosić się do nowego zatwierdzenia, tak, ale żadna inna gałąź nie przechodzi „automatycznie” do następnego zatwierdzenia. Powinieneś wyjaśnić pierwszy akapit swojej odpowiedzi.
Szczoteczka do zębów
1
@Toothbrush Jasne, to właśnie miałem na myśli mówiąc „automatycznie się porusza”. Jednak gałąź tak naprawdę nie "posiada" żadnych zatwierdzeń, nawet nie wskazuje na zestaw zatwierdzeń, po prostu wskazuje na jedno zatwierdzenie (a resztę można założyć, czasami nieprecyzyjnie, przechodząc po wykresie zatwierdzeń). Pod git, branch to tylko jednowierszowy plik poniżej .git\refs\heads, zawierający hash zatwierdzenia. Commity same w sobie nie „pamiętają”, która gałąź je utworzyła. Różni się to na przykład od Mercurial, w przypadku którego informacje o gałęzi można zapisać w metadanych zatwierdzenia.
Branko Dimitrijevic,
Tak, ale wiele osób o tym nie wie - zwłaszcza nowicjusze, którzy są zdezorientowani niezliczonymi sposobami robienia rzeczy za pomocą Git w Internecie.
Szczoteczka do zębów
6

Używasz tagów do zapisywania ważnych zatwierdzeń w historii. „Dokładnie takiego zatwierdzenia użyliśmy w tej wersji w ten deszczowy czwartek, kiedy zepsuł się serwer kompilacji”. Jeśli użyjesz branch zamiast tagu, nigdy nie możesz wiedzieć, jakiego dokładnego zatwierdzenia użyłeś. Wiesz tylko, że "wypuściliśmy wersję 1.1.0 gdzieś w tej gałęzi", chyba że ręcznie zapiszesz dokładny hash dla tego zatwierdzenia, dlatego w pierwszej kolejności używasz tagów :)

ralphtheninja
źródło
4
Myślę, że miał na myśli stworzenie gałęzi o nazwie 1.1.0 i nieużywanie jej już, więc będzie reprezentować projekt w wymienionej wersji.
Hakan Deryal
2

Oprócz innych odpowiedzi, oto moje 2 centy.

Krótka odpowiedź: Użyj tagów dla wersji wydania

Długa odpowiedź: Uważam, że używanie tagów do wersjonowania wydania jest lepsze niż używanie gałęzi. Jeśli potrzebujesz zaktualizować zwolnienie, po prostu rozgałęziaj się z oznaczonym zatwierdzeniem i po zakończeniu pracy nad tą gałęzią (najprawdopodobniej gałąź poprawek), utwórz nowy znacznik na początku tej nowej gałęzi z nową wersją. Następnie połącz tę gałąź z powrotem w master / develop, ponieważ naprawdę nie powinieneś zmieniać wersji wydania, chyba że jest to poprawka, która prawdopodobnie powinna zostać ponownie włączona do twojego kodu źródłowego. Następnie usuń tę gałąź, ponieważ nie jest już potrzebna. Jeśli musisz zastosować inną poprawkę do tej nowej wersji, powtórz te same kroki.

Zapoznaj się z sekcją poniższego artykułu, w której pokazano, jak scalić poprawkę z przepływem pracy Git autora - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

Region39
źródło