OSTRZEŻENIE: to nie zachowa wiadomości z tagami dla tagów z adnotacjami.
Podsumowanie
Dla każdego tagu, który należy zmienić:
- Cofnij się w czasie do zatwierdzenia reprezentującego tag
- Usuń tag (lokalnie i zdalnie)
- Spowoduje to zmianę „Wydania” na GitHub w wersję roboczą, którą możesz później usunąć.
- Ponownie dodaj tag o tej samej nazwie, używając magicznego wywołania, które ustawia jego datę na datę zatwierdzenia.
- Przenieś nowe tagi z ustalonymi datami z powrotem do GitHub.
- Przejdź do GitHub, usuń wszystkie wersje w wersji roboczej i ponownie utwórz nowe wersje z nowych tagów
W kodzie:
git checkout 1.0.1
git tag -d 1.0.1
git push origin :refs/tags/1.0.1
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag -a 1.0.1 -m"v1.0.1"
git push --tags
Detale
Zgodnie z How to Tag in Git :
Jeśli zapomnisz otagować wersję lub wersję, zawsze możesz oznaczyć je wstecz, w ten sposób:
git checkout SHA1_OF_PAST_COMMIT
git tag -m"Retroactively tagging version 1.5" v1.5
I chociaż jest to całkowicie użyteczne, powoduje to, że tagi są poza porządkiem chronologicznym, co może zaszkodzić systemom kompilacji, które szukają „najnowszego” tagu. Ale nie bój się. Linus pomyślał o wszystkim:
git checkout SHA1_OF_PAST_COMMIT
git show --format=%aD | head -1
GIT_COMMITTER_DATE="Thu Nov 11 12:21:57 2010 -0800" git tag -a 0.9.33 -m"Retroactively tagging version 0.9.33"
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag -a 0.9.33 -m"Retroactively tagging version 0.9.33"
Jeśli jednak dodałeś już tag, nie możesz użyć powyższego z, w git tag -f existingtag
przeciwnym razie git będzie narzekał podczas próby scalenia:
Rammy:docubot phrogz$ git push --tags
To [email protected]:Phrogz/docubot.git
! [rejected] 1.0.1 -> 1.0.1 (already exists)
error: failed to push some refs to '[email protected]:Phrogz/docubot.git'
hint: Updates were rejected because the tag already exists in the remote.
Zamiast tego musisz usunąć tag lokalnie:
git tag -d 1.0.1
Zdalnie wypchnij to usunięcie :
git push origin :refs/tags/1.0.1
W serwisie GitHub załaduj ponownie wersje - wydanie zostało oznaczone jako „wersja robocza” - i usuń wersję roboczą.
Teraz dodaj tag z datą wsteczną zgodnie z powyższymi instrukcjami, a na koniec prześlij wynikowy tag do GitHub:
git push --tags
a następnie przejdź i ponownie dodaj informacje o wersji GitHub.
git tag -l | while read -r tag; do `git checkout $tag && git tag -d $tag && git push origin :refs/tags/$tag && GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag -a $tag -m"$tag"`; done; git push --tags
git tag -af
czyni-d
niepotrzebnymi i pozostajesz lokalnie, więc możesz sprawdzić, czy wszystko jest w porządku - wtedy możeszgit push --tags -f
git tag -l | while read -r tag ; do COMMIT_HASH=$(git rev-list -1 $tag) && GIT_COMMITTER_DATE="$(git show $COMMIT_HASH --format=%aD | head -1)" git tag -a -f $tag -m"$tag" $COMMIT_HASH ; done && git push --tags --force
$env:GIT_COMMITTER_DATE="Thu Nov 11 12:21:57 2010 -0800"
igit tag -a 0.9.33 -m"Retroactively tagging version 0.9.33"
Oto jedna linijka oparta na niektórych komentarzach w drugiej odpowiedzi:
Aby to rozbić ...
Podziękowania dla @Mr_and_Mrs_D za sugestię użycia pojedynczego naciśnięcia.
źródło
Opierając się na innych odpowiedziach, oto sposób, który pozwoli zachować pierwszą linię wiadomości z tagiem
Bit odpowiedzialny za zachowanie wiadomości to:
head -n1
weźmie pierwszą linię starego komunikatu o zatwierdzeniu. Możesz go zmienić na-n2
lub-n3
etc, aby zamiast tego uzyskać dwie lub trzy linie.Jeśli chcesz zmienić datę / godzinę tylko dla jednego tagu, możesz rozbić jeden wiersz, aby zrobić to w powłoce bash:
Bibliografia:
źródło
-s
flaga, której nie ma w jednowierszowym , więc otrzymywałem,error: gpg failed to sign the data
ponieważ nie mam skonfigurowanego podpisu dla git. Ten błąd trochę mnie wytrącił.