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.
Odpowiedzi:
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.
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.
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/
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ć.
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.
.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.
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 :)
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