Ich kenne keine Möglichkeit, dies direkt in GitHub zu tun. Die "neueste Version" wird aus den Zeitstempeln Ihrer Tags bestimmt, nicht aus der Semantik ihrer Namen.

In der Vergangenheit habe ich dieses Problem bei meinen eigenen Projekten gelöst, indem ich das problematische ältere Tag gelöscht habe:

und es mit einem falschen Datum neu erstellen:

Dies ist in der Hilfeseite für git-tag dokumentiert:

  

Bei rückdatierenden Tags

     

Wenn Sie einige Änderungen von einem anderen VCS importiert haben und Tags für Hauptversionen Ihrer Arbeit hinzufügen möchten, ist es hilfreich, das einzubettende Datum innerhalb des Tag-Objekts angeben zu können. Solche Daten im Tag-Objekt beeinflussen zum Beispiel die Reihenfolge der Tags in der gitweb-Schnittstelle.

     

Um das in zukünftigen Tag-Objekten verwendete Datum festzulegen, setzen Sie die Umgebungsvariable GIT_COMMITTER_DATE (siehe die spätere Diskussion möglicher Werte; die gebräuchlichste Form ist "YYYY-MM-DD HH: MM").

     

Zum Beispiel:

%Vor%

Beachten Sie, dass dieselbe Manpage dringend empfiehlt, gegen denselben Tag-Namen wiederzuverwenden:

  

Beim erneuten Taggen

     

Was sollten Sie tun, wenn Sie ein falsches Commit markieren und Sie es erneut taggen möchten?

     

Wenn Sie nie etwas rausgeschoben haben, markieren Sie es einfach erneut. Verwenden Sie "-f", um das alte zu ersetzen. Und du bist fertig.

     

Aber wenn Sie Dinge verschoben haben (oder andere Ihr Repository direkt lesen könnten), dann haben andere das alte Tag bereits gesehen. In diesem Fall können Sie eines von zwei Dingen tun:

     

1. Das gesunde Ding. Gib einfach zu, dass du es vermasselt hast und benutze einen anderen Namen. Andere haben bereits einen Tag-Namen gesehen, und wenn Sie den gleichen Namen behalten, können Sie in der Situation sein, dass zwei Leute beide "Version X" haben, aber sie haben tatsächlich unterschiedliche "X". Also nenn es einfach "X.1" und sei damit fertig.

  

2. Das wahnsinnige Ding. Du willst die neue Version auch wirklich "X" nennen, obwohl andere schon die alte Version gesehen haben. Verwenden Sie einfach git tag -f again , als hätten Sie die alte Version noch nicht veröffentlicht.

  

Allerdings tut Git nicht (und sollte es auch nicht) Tags hinter Benutzern zurück zu ändern. Wenn also jemand das alte Tag schon hat, sollte ein git pull auf Ihrem Baum nicht nur dazu führen, dass sie den alten überschreiben.

     

Wenn jemand ein Release-Tag von Ihnen bekommen hat, können Sie nicht einfach das Tag für sie ändern, indem Sie Ihr eigenes aktualisieren. Dies ist ein großes Sicherheitsproblem, da die Leute ihren Tag-Namen vertrauen müssen. Wenn du wirklich das Wahnsinnige machen willst, musst du dich einfach daran halten und den Leuten erzählen, dass du versagt hast. Sie können dies tun, indem Sie eine sehr öffentliche Ankündigung sagen:

     

    

Ok, ich habe es vermasselt, und ich habe eine frühere Version, die als X gekennzeichnet ist, rausgeschmissen     dann etwas repariert und den fixierten Baum erneut als X gespeichert.

         

Wenn Sie das falsche Tag erhalten haben und das neue möchten, löschen Sie es bitte     das alte und hole das neue, indem du tust:

%Vor%          

um mein aktualisiertes Tag zu erhalten.

         

Sie können testen, welches Tag Sie haben, indem Sie

drücken %Vor%          

sollte 0123456789abcdef zurückgeben .. wenn Sie die neue Version haben.

         

Entschuldigung für die Unannehmlichkeiten.

  

     

Scheint das ein bisschen kompliziert? Es sollte sein sein. Es ist unmöglich, es automatisch zu "reparieren". Die Leute müssen wissen, dass ihre Tags möglicherweise geändert wurden.

Ich würde das gleiche Tag nur dann wiederverwenden, wenn Ihr Projekt relativ isoliert ist und Sie zuverlässig alle kontaktieren können, die den Code verwenden.

Weitere Einzelheiten zum Löschen von Remotetags finden Sie unter diese Frage .