Gitflow: git-flow `tag` Commit-Speicherort bei Fertigstellung der Veröffentlichung

Erstellt am 30. Sept. 2015  ·  4Kommentare  ·  Quelle: nvie/gitflow

Es ist mein Verständnis von der Seite http://nvie.com/posts/a-successful-git-branching-model/ , wo ich vor etwa 2 Jahren zum ersten Mal das git-flow-Modell gelernt habe, dass ein tag wäre immer auf dem Commit, wo der release Zweig mit master .

Ich habe vor kurzem das git-flow-Plugin für Git-Erweiterungen installiert und das tag wird auf den letzten Commit im release Zweig angewendet und nicht auf den zusammengeführten Commit auf dem master Zweig.

Ist das ein Fehler? Ist es wirklich wichtig, auf welchem tag befindet? Meine Problemumgehung besteht darin, das tag manuell zu löschen und es dort neu zu erstellen, wo ich gelernt habe, es erstellen zu lassen.

picture RoLYroLLs
👍5 👎1

Hilfreichster Kommentar

Nach meinem Verständnis ist das Platzieren des Tags im Release-Zweig vor dem Zusammenführen (und nicht im Master-Zweig) tatsächlich die richtige Vorgehensweise, sodass es auch von git describe --tags aus dem Develop-Zweig gefunden werden kann. Siehe #374

picture knox am 16. März 2016
👍6

Alle 4 Kommentare

Ich bin gerade auf das gleiche Problem mit dem gleichen Verständnis gestoßen, das Sie @RoLYroLLs haben. Hier ein Zitat aus dem Artikel:

Wenn der Status des Release-Zweigs bereit ist, ein echtes Release zu werden, müssen einige Aktionen ausgeführt werden. Zuerst wird der Release-Zweig in master (da jeder Commit auf master per Definition ein neues Release ist, denken Sie daran). Als Nächstes muss dieser Commit für master mit einem Tag versehen werden, um in Zukunft leichter auf diese historische Version

Ich hoffe, das wird behoben, da ich den gleichen Tanz löschen und neu erstellen muss, den Sie erwähnt haben.

gligoran picture gligoran am 14. Okt. 2015

Ok, ich habe damit herumgespielt und herausgefunden, wie man es "repariert", wenn man so will, mit der Methodik, die unter http://nvie.com/posts/a-successful-git-branching-model/ geschrieben wurde.

Ich habe das Gefühl, dass dieses Projekt aufgegeben wurde, seit es das letzte Mal im Jahr 2012 berührt wurde, daher werde ich keine PR erstellen, aber ich werde dieses Thema aktiv lassen.

Für diejenigen unter Ihnen wie mich können Sie jedoch die folgenden Dateien bearbeiten:

https://github.com/nvie/gitflow/blob/15aab26490facf285acef56cb5d61025eacb3a69/git-flow-release#L253
und
https://github.com/nvie/gitflow/blob/15aab26490facf285acef56cb5d61025eacb3a69/git-flow-hotfix#L297

Ändere $BRANCH in $MASTER_BRANCH

RoLYroLLs picture RoLYroLLs am 28. Nov. 2015

Nach meinem Verständnis ist das Platzieren des Tags im Release-Zweig vor dem Zusammenführen (und nicht im Master-Zweig) tatsächlich die richtige Vorgehensweise, sodass es auch von git describe --tags aus dem Develop-Zweig gefunden werden kann. Siehe #374

knox picture knox am 16. März 2016
👍6

Nach meinem Verständnis ist das Platzieren des Tags im Release-Zweig vor dem Zusammenführen (und nicht im Master-Zweig) tatsächlich die richtige Vorgehensweise, sodass es auch von git describe --tags aus dem Develop-Zweig gefunden werden kann. Siehe #374

Das war ein seltsames Argument.
Die Quellen sind versioniert, sodass Sie bereitgestellte Anwendungen mit der Quelle korrelieren können, die sie erstellt hat.

pi3k14 picture pi3k14 am 2. Apr. 2020
👍1
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

primeminister picture primeminister  ·  4Kommentare
JoeSchr picture JoeSchr  ·  14Kommentare
devlins picture devlins  ·  21Kommentare
alexjeffburke picture alexjeffburke  ·  24Kommentare
boryn picture boryn  ·  6Kommentare