2010-02-18 5 views
15

Jedes git Tutorial Sie in schauen hat eine klare Meinung über tags: Man sollte immer kommentierten Tags verwenden, ist einer der Gründe ist, dass sie von git describe verwendet werden.git: Ist ein unkommentierten Tag schlimmer als ein Tag mit einer schlechten Anmerkung?

Allerdings sehe ich nichts Schlechtes in der Verwendung git describe --tags, die auch die unannotated Tags als Referenzpunkt nimmt. Gibt es noch etwas, das an unnotierten Tags als schlecht angesehen wird?

Ich frage, weil ich ein SVN-Projekt Umwandlung git gerade beendet haben. Ich habe tatsächlich darüber nachgedacht, die Tags mit einer Anmerkung zu versehen, aber was hätte ich da hin geben sollen, wenn nicht eine alarmierend redundante 'Tagging Release 1.5 für unser Projekt' Nachricht (die sowieso schon als SVN Kommentar verwendet wurde)?

Kommentierte Tags scheinen mir eine nette Sache zu sein (Sie können Sachen als einen anderen Autor markieren und eine kurze Beschreibung geben), aber sollten Sie sie wirklich in Fällen verwenden, in denen Sie nichts Bedeutungsvolles zu sagen haben von der ursprünglichen Commit-Nachricht?

oder

In welchen Situationen sind unkommentierten Tags auf nicht runzelte die Stirn?

Bearbeiten: Ich spreche nicht über signierte annotierte Tags (Ich verstehe den Vorteil der signierten Tags in einigen Situationen); Ich bin nur besorgt über den Unterschied zwischen unkommentierten und unsigned kommentiert.

Edit 2: eine andere Frage Anfügen den Umfang etwas zu erweitern und vielleicht ein paar interessante Antworten über die real-life erhalten Best-bractices

Wann Sie Verwendung unkommentierten Tags und fühlen Sie sich schlecht über es wenn du es tust?

+2

Siehe http://stackoverflow.com/questions/4971746/why-should-i-care-about-lightweight -vs-annotated-tags – dubek

+0

Mögliches Duplikat von [Was ist der Unterschied zwischen einem annotierten und einem unnotierten Tag?] (https://stackoverflow.com/questions/11514075/what-ist-the-difference-between-an-annotated- und du nannotated-tag) –

Antwort

4

Ein annotiertes Tag ist eigentlich ein Tag-Objekt. Es hat einen Autor, eine Beschreibung, einen Zeitstempel und zeigt auf einen Commit.

Ein Lightweight-Tag verweist auf ein Commit und enthält keine weiteren Informationen. Es hat mehr mit Branching als mit Tagging zu tun.

+0

Wahr. Aber meine Frage ist nicht, was annotierte Tags * sind *. Ich frage mich, ob ich sie verwenden sollte, obwohl sowohl die Beschreibung als auch der Autor redundant sind. – Debilski

+3

Ich glaube nicht, dass die Beschreibung und der Autor redundant sind. Die Person, die eine Veröffentlichung markiert, ist nicht unbedingt die Person, die den Code geschrieben hat (wer auch, ist nicht unbedingt die Person, die den Code begangen hat). Ich habe nie eine gute Verwendung für leichte Tags gefunden, ich selbst. – Dustin

3

man git-tag sagt:

Kommentierte Tags für Release gedacht sind, während leichte Tags für private oder temporäre Objekt Etiketten gemeint sind.

Also im Grunde nicht leichte Tags drücken.

Wenn Sie dies berücksichtigen, alle Verhalten Design-Entscheidungen machen Sinn:

  • kommentierten Tags eine Nachricht enthalten, der Schöpfer und das Datum anders als die sich verpflichten, sie zeigen. Sie können sie also verwenden, um eine Veröffentlichung zu beschreiben, ohne eine Freigabe zu schreiben.

    Leichte Tags haben diese zusätzlichen Informationen nicht und brauchen sie auch nicht, da Sie sie nur selbst zur Entwicklung verwenden werden.

  • git push --follow-tags werden nur annotierte Tags verschoben, um Ihre lokalen Tags nicht zu veröffentlichen.

  • git describe beantwortet die Frage: "Zu welchem ​​Release gehört dieses Commit?", Was ein häufiger Anwendungsfall ist.

Siehe auch: