Jak wypychasz tag Git do gałęzi za pomocą refspec?

216

Chcę wymusić wypychanie, na przykład, mojego tagu 1.0.0do mojej zdalnej mastergałęzi.

Teraz wykonuję następujące czynności:

git push production +1.0.0:master

Chcę wymusić wypychanie , ponieważ zależy mi tylko na tym, aby kod wewnątrz1.0.0znacznika został wypchnięty domastergałęzi w zdalnym repozytorium.

Co ja robię źle?

Aktualizacja nr 1

Kiedy włączam SSH do mojego serwera, na którym znajduje się moje repozytorium Git i git branch -lwykonuję je, nie widzę też mastergałęzi na liście.

Aktualizacja nr 2

Po uruchomieniu git tag -lz wnętrza zdalnego repozytorium Git widzę, że masterjest na liście, co oznacza, że po uruchomieniu:

git push production 1.0.0:master

W rzeczywistości wypchnął tag i utworzył tag o nazwie master zamiast nowej gałęzi .

Chcę w zasadzie wepchnąć zawartość znacznika 1.0.0do mastergałęzi zdalnego repozytorium Git.

git git-push git-tag

— Michael van Rooijen
źródło

Czy możesz wyjaśnić, co oznacza „nie działa”? Czy Git podaje konkretny błąd, czy ma efekt zerowy?

— vcsjones

Przykro mi. Tak, więc w zasadzie, kiedy włączam SSH do mojego serwera, do repozytorium git i uruchamiam git branch -l, aby wyświetlić listę gałęzi, widzę tylko moją drugą gałąź. Jednak produkcja git push +1.0.0: master wykonała push, a kiedy ponownie go wypisałem, napisano: Wszystko aktualne , ale nie widzę gałęzi master na zdalnym serwerze.

— Michael van Rooijen

5

Powinieneś zmienić przyjętą odpowiedź. Druga odpowiedź jest znacznie prostsza niż ta oznaczona jako zaakceptowana.

— Pedro Rolo

Przepraszam za późną odpowiedź. Zgadzam się i zmieniłem zaakceptowaną odpowiedź.

— Michael van Rooijen

1

@MichaelvanRooijen Nie rozumiem, w jaki sposób zaakceptowana odpowiedź, którą wybrałeś, faktycznie rozwiązuje ten problem. Nie zastępuje gałęzi tagiem, po prostu wypycha tagi do pilota.

61

Prawdopodobnie zawodzi, ponieważ 1.0.0jest to tag z adnotacjami. Być może zobaczyłeś następujący komunikat o błędzie:

błąd: Próba zapisania obiektu niezatwierdzonego w gałęzi refs / heads / master

Znaczniki z adnotacjami mają swój własny odrębny typ obiektu, który wskazuje na oznaczony obiekt zatwierdzenia. Gałęzie nie mogą użytecznie wskazywać na oznaczanie obiektów, tylko zatwierdzać obiekty. Musisz „odkleić” opisany tag z powrotem, aby zatwierdzić obiekt i zamiast tego go przesunąć.

git push production +1.0.0^{commit}:master
git push production +1.0.0~0:master          # shorthand

Jest jeszcze inna składnia, która również działałaby w tym przypadku, ale oznacza to coś nieco innego, jeśli obiekt znacznika wskazuje na coś innego niż zatwierdzenie (lub obiekt znacznika, który wskazuje (obiekt znacznika, który wskazuje na…) zatwierdzenie) .

git push production +1.0.0^{}:master

Te składnie obierania znaczników są opisane w git-rev-parse (1) w części Określanie poprawek .

— Chris Johnsen
źródło

1

To rozwiązało problem! Jednak gałąź master musi już istnieć. Nie jest to jednak mój problem. Bardzo dziękuję za Twoją pomoc!

— Michael van Rooijen

2

@Michael: Ahh. Tak, jeśli master nie istnieje (jako gałąź lub tag), wówczas git push rep +tag:masterutworzy tag o nazwie master zamiast gałęzi. git push rep +tag~0:master(ponownie, gdy master nie istnieje jako gałąź lub tag) zakończy się niepowodzeniem z komunikatem „error: niemożność wypchnięcia do niewykwalifikowanego miejsca docelowego”. Polecenie, które zrobiłoby to, co chciałeś (zanim istniała jakaś gałąź / znacznik główny ) to git push rep +tag~0:refs/heads/master( refs/heads/przestrzeń nazw, w której gałęzie są przechowywane).

— Chris Johnsen

ŚWIETNY! Pomoże mi to niesamowicie dobrze. Bardzo wygodne! Bardzo dziękuję za opublikowanie tych informacji.

— Michael van Rooijen

4

@brad: ~{commit}Składnia jest dosłowna (tzn. zawsze te dziewięć znaków); słowo commitnie jest tutaj symbolem zastępczym.

— Chris Johnsen,

1

ah ok! przepraszam, myślałem, że chciałeś wprowadzić konkretną zmianę, teraz ma to większy sens.

— Brad

469

git push --tags production

— bstpierre
źródło

4

Jeśli znacznik już istnieje na pilocie, najpierw musisz go usunąć git push production :1.0.0.

— szacunek TheCode

1

Jeśli przy dowolnej okazji będziesz miał oddział o tej samej nazwie: „1.0.0” to push nie powiedzie się, więc lepiej użyj: git push production :refs/tags/1.0.0aby usunąć tylko tag

— Vladimir

1

@Nerian: Myślę, że to po prostu popycha tagi

— bstpierre

5

Jak to faktycznie rozwiązuje problem oryginalnego plakatu dotyczący nadpisywania gałęzi znacznikiem poprzez wymuszenie go? To po prostu wypycha wszystkie twoje tagi do pilota, nie nadpisuje żadnych gałęzi.

1

Czy nie ma pytania, jak wcisnąć jeden tag? To polecenie robi o wiele więcej.

— Chris Martin

61

Tworzę taki tag, a następnie przekazuję go do GitHub:

git tag -a v1.1 -m "Version 1.1 is waiting for review"
git push --tags

Counting objects: 1, done.
Writing objects: 100% (1/1), 180 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:neoneye/triangle_draw.git
 * [new tag]         v1.1 -> v1.1

— neoneye
źródło

4

przesuwa wszystkie twoje tagi

— Dawid Drozd

2

Zauważ, że to nie rozwiąże problemu oryginalnego plakatu dotyczącego nadpisania gałęzi tagiem, po prostu popchnie twoje tagi do pilota, bez wpływu na gałęzie.

10

Aby przesłać pojedynczy tag: git push <reponame> <tagname>

Na przykład, git push production 1.0.0 . Tagi nie są powiązane z gałęziami, są powiązane z zatwierdzeniami.

Jeśli chcesz mieć zawartość znacznika w gałęzi master, zrób to lokalnie na swoim komputerze. Zakładam, że nadal rozwijasz się w lokalnym oddziale głównym. Więc git push origin masterwystarczy.

— koppor
źródło

5

Zauważ, że to nie rozwiąże problemu oryginalnego plakatu dotyczącego nadpisania gałęzi tagiem, po prostu popchnie twoje tagi do pilota, bez wpływu na gałęzie.