Czy tagi git również są wypychane?


190

Ponieważ utworzyłem moje repozytorium, wydaje się, że tagi, które tworzyłem, nie są wypychane do repozytorium. Kiedy robię to git tagw lokalnym katalogu, wszystkie tagi są obecne, ale kiedy loguję się do zdalnego repozytorium i robię to git tag, pojawia się tylko kilka pierwszych.

Jaki może być problem ?.


3
git push --follow-tagsmoże być teraz użyteczne, patrz moja odpowiedź poniżej
VonC


1
Zgadzam się z duplikatem: chociaż jest to starsze, drugie pytanie jest lepiej postawione.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Odpowiedzi:


247

Możesz to zrobić:

git push --tags

27
Jestem całkiem pewien, że oznacza to, że referencje HEAD nie zostaną popchnięte, co oznacza, że ​​TYLKO pchasz tagi.
Dan Rosenstark,

47
„Zalecam, aby nie używać ani nie szkolić innych do używania, git push --tagsponieważ bardzo trudno jest pozbyć się złych tagów, gdy twoi współpracownicy są szkoleni do wypychania wszystkich tagów, ponieważ ludzie nadal wypychają stare złe etykiety, które mają lokalnie za każdym razem, gdy chcę wcisnąć nowy tag. Z tego powodu doradzę git push origin <tag_name>teraz tylko komuś, kto będzie go używać ”. - skopiowane ze stackoverflow.com/a/5195913/4130619
ograniczenie aktywności

Myślę, że inna odpowiedź, stackoverflow.com/a/16164809/11635 powinna zostać zaakceptowana. Nawet jeśli nie, zdecydowanie należy go przeczytać - zapewnia zalety i wady, a ostatecznie bardziej praktyczną i poprawną odpowiedź na dziś
Ruben Bartelink,

140

W domyślnej konfiguracji zdalnej git musisz jawnie wypychać tagi (gdy są one pobierane automatycznie wraz z zatwierdzeniami, które wskazują). Musisz użyć

$ git push <remote> tag <tagname>

wcisnąć pojedynczy tag lub

$ git push <remote> --tags

wcisnąć wszystkie tagi (lub git push --tagswcisnąć domyślnie pilota origin).

Jest to bardzo zamierzone zachowanie, aby jawnie przesuwać tagi. Naciskanie tagów powinno być zwykle świadomym wyborem.


Podsumowanie tego, co napisał Junio ​​C. Hamano (link w komentarzach @Andre Miras)

Podczas pobierania masz do czynienia ze zdalnym repozytorium, które ktoś opublikował, co oznacza:

  1. zestaw tagów, które istnieją, to wszystko, co wydawca chciał, aby ludzie widzieli, i
  2. nie tylko ty, ale i inni ludzie zobaczą te same tagi.

Innymi słowy, tagi w repozytoriach, które pobierasz, są zaprojektowane jako publiczne i udostępnione. Ułatwi komunikację między programistami, jeśli wszyscy będą mogli pobrać te same tagi.

Dlatego git fetchautomatycznie „podąża” za tagami, tzn. Pobiera tagi podczas pobierania wersji, na które wskazują - innymi słowy, pobiera wszystkie odpowiednie opublikowane tagi.

Podczas wypychania wypychasz ze swojego działającego repozytorium, które przez większość czasu nie jest publiczne, a tagi w tym repozytorium nie są zaprojektowane jako publiczne. Możesz użyć własnych tagów lokalnych, aby zaznaczyć swoje postępy, więc nie ma sensu ślepo przesuwać wszystkich tagów w repozytorium do repozytorium, które wypychasz, aby opublikować zmiany, których tagi są z definicji publiczne.

Dlatego musisz wyraźnie nacisnąć tag, aby oznaczyć tag jako publiczny.


Alternatywnie możesz skonfigurować pilota, do którego naciskasz, aby zawsze wypychał wszystkie tagi, np. Wstawiał coś takiego .git/config:

[zdalne „publikowanie”] # lub jakkolwiek to się nazywa
    url = ...
    push = + refs / heads / *: refs / heads / *
    push = + refs / tags / *: refs / tags / *

Oznacza to wymuszone pchanie wszystkich głów (wszystkie gałęzie) i wszystkie tagi (jeśli nie chcesz wymuszonego pchania głów, usuń prefiks „+” z refspec).


Czy to nie zawsze powoduje „wymuszenie” wszystkich głów?
Stefan Näwe

@Stefan: Tak. Zaktualizowano
Jakub Narębski

19
„Jest to bardzo zamierzone zachowanie, polegające na wyraźnym popychaniu tagów. Pchanie tagów powinno być zwykle świadomym wyborem”. Nie rozumiem uzasadnienia. Czy możesz wyjaśnić, dlaczego Git miałby źle przesyłać tagi automatycznie?
Ryan Lundy,

13
@ Kyralessa, w tym poście git.661346.n2.nabble.com/... , Junio ​​C Hamano (obecny opiekun Git) wyjaśnia, dlaczego automatyczne przesuwanie tagów jest złe.
Andre Miras,

@AndreMiras Dziękujemy za ten niesamowity link. Byłoby miło, gdybyśmy mogli włączyć post Junio ​​do tej odpowiedzi.
Homer6

67

Zwróć uwagę, że od git 1.8.3 (22 kwietnia 2013 r.) Nie musisz już wykonywać 2 poleceń, aby wypychać gałęzie, a następnie wypychać tagi:

Nowa --follow-tagsopcja „ ” mówi „ git push”, aby wypychać odpowiednie tagi z adnotacjami podczas wypychania gałęzi .

Możesz teraz spróbować, wypychając nowe zatwierdzenia:

git push --follow-tags

Nie wypchnie to jednak wszystkich lokalnych znaczników, tylko te z adnotacjami, do których odwołują się commits, które są wypychane za pomocą git push.


Zostało to wprowadzone w zatwierdzeniu c2aba15 przez Junio ​​C. Hamano ( gitster) :

Nowa opcja „ --follow-tagsmówi”, git pushaby wypchnąć tagi z adnotacjami, których brakuje z drugiej strony i do których można dotrzeć poprzez wypchnięcie historii.

Na przykład, jeśli używasz przycisku „ simple”, „ current” lub „ upstream”, zwykle przesuwasz historię prowadzącą do zatwierdzenia na swoim obecnym poziomie HEADi nic więcej.
Dzięki tej opcji przesuniesz także wszystkie tagi z adnotacjami, do których można dotrzeć z tego zatwierdzenia na drugą stronę.


Konfiguracja push.followTagspozwala --follow-tagsdomyślnie uwzględnić (Git 2.4.1+, Q2 2015). Zobacz „ Wciśnij zatwierdzenia i tagi jednocześnie git


3
Spycha to tylko wszystkie tagi z adnotacjami . Większość osób / projektów używa lekkich tagów. Więc w większości przypadków git push --follow-tagsnie naciska więcej niżgit push
Jarl

3
@Jarl tak, w mojej odpowiedzi wspomniałem o „adnotacji”. Ale tak naprawdę użyłem tylko tagów z adnotacjami, rezerwując lekkie tagi do użytku wyłącznie wewnętrznego (tj. Nigdy nie zamierzałem ich popychać).
VonC

@VonC: Teraz jest też opcja konfiguracji, która sprawia, że ​​jest to domyślna, jak zauważyłeś tutaj: stackoverflow.com/a/3745250/946850
krlmlr 10.1015

19

Zwykle robię to:

[zdalne „publikowanie”] # lub jakkolwiek to się nazywa
    url = ...
    push =:
    push = + refs / tags / *: refs / tags / *

Oznacza to, że wypycha każdą gałąź, która już tam jest, plus tagi. Nie wymusza pushowania i nie wypycha gałęzi, których nie wypchnąłeś ręcznie.


Czy mogę to również umieścić w globalnej konfiguracji git mojego użytkownika? Jeśli tak to jak? Dzięki! :)
gucki

Wygląda na to, że wymuszasz tagi, ale nie gałęzie.
Adrian Ratnapala

Cóż, tak i nie, napisałem to, że będzie wypychał nowe tagi, nie będzie zmuszał ich do popychania i nie będzie pchał gałęzi, których sam nie popchnąłeś.
mat

Wypróbowałem sugestię Jakuba, ale pchałem gałęzie, których chciałem tylko lokalnie. Ta sugestia, mata, działa idealnie. Synchronizuje tagi, ale nie synchronizuje gałęzi, chyba że są to zdalne gałęzie śledzące (tj. Nie wypchnie nowych gałęzi do pilota, ale zaktualizuje je, jeśli są już w pilocie). UWAGA: jeśli masz tag i gałąź o tej samej nazwie, pojawi się błąd „pasuje więcej niż jeden”. Zapoznaj się z lostechies.com/jasonmeridth/2010/02/27/refspec-matches-more-than-one/ .
josephdpurcell

5

A jeśli chcesz wymusić pobranie wszystkich tagów, możesz ustawić to w konfiguracji przez:

git config remote.origin.tagopt --tags

Z dokumentów:

Ustawienie tej wartości na --no-tags wyłącza automatyczne śledzenie tagów podczas pobierania ze zdalnego. Ustawienie go na --tags spowoduje pobranie każdego tagu ze zdalnego, nawet jeśli nie są osiągalne ze zdalnych głów oddziałów. Przekazywanie tych flag bezpośrednio do git-fetch (1) może zastąpić to ustawienie. Zobacz opcje --tags i --no-tags git-fetch (1).


1
Pytanie było bardziej zorientowane na „push”, czy twoja odpowiedź dotyczy również wypychania na pilota?
a1an
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.