Ich genieße jedes einzelnes Video von euch, aber bitte unbedingt mehr von diesen Hands-On Videos! Sie helfen ungemein die erlernte Theorie in die Praxis umzusetzen! Und bei dieser Gelegenheit: Danke für eure tolle Arbeit!
Vielen Dank für das tolle Video! Mir gefällt der Ansatz und auch das Tool, find ich Klasse! Vorallem cool find ich, dass das Tool wirklich sich nur auf eine Sache konzentriert. Ich mach das bisher nicht automatisiert, aber es reizt mich jetzt schon etwas, dass mal anzugehen.
@@thenativeweb hab mich jetzt einmal mit dem Tool auseinander gesetzt und konnte einen nutzen für mich finden 🙂. Was ich in der Dokumentation etwas vermisse, beispielhaft aus Sicht einer Person welche das Video nicht gsehen hat, den Quellcode sich nicht angeschaut hat oder mit dem Prinzip SemVers noch nicht so vertraut ist, ist die Erklärung der Nutzung. Das diese auf Tags basiert, welche im SemVer Format definiert wurden und welche Keywords in commits gesucht werden, wird meines Erachtens nicht erwähnt. Zumindest eine Verlinkung zu entsprechenden Seiten, wäre finde ich ganz gut. Das mag relativ offensichtlich sein, aber wie ich finde, nicht für jede Person.
Wie immer ein super Video und danke für die ganzen Mühe etc. Wir würden hier ein 2. Version dieser Reihe von Video wünschen. Quasi etwas mehr davon und Vertiefungen was GitHub Action in zusammen Arbeit von Semantic Version / get_next_version betrifft.
Vielen Dank! Sehr nützliches Video. Es hat geholfen, dieses Thema noch besser zu begreifen, die Automatisierung ist super.
2 года назад
Sehr cooles Video, vielen Dank. Gerade Conventional Commits hatte ich noch gar nicht so auf dem Schirm und jetzt wo ich es gesehen habe, frag ich mich warum ich das nicht schon immer eingesetzt habe 😬
Hallo tnw team, vielen dank für das video. Das am angang angesprochene "macht zu viel und mehr als Versionining kenne ich zugut." Kenne Semver Schon seit längerem und habe es mir in Python mal in ein docker Container gepackt der im Prinzip genau das macht was euer Go Tool macht. Hatte nämlich das selbe Problem das ich "nur" anhand der Git History die Versionen taggen wollte. :)
Eine Frage zu den Commits und den Commit Texten. Ich hab jetzt in unserem Team mit einem kleinen bestehenden Projekt angefangen. Ich hatte mir einen Feature Branch erstellt, wo ich nach und nach verschiedene Änderungen gemacht habe, die ich zu einem guten stabilen Zustand gebracht habe und dann in den Feature Branch commited habe. Bei den Änderungen, die nach und nach in den Feature Branch gekommen sind, habe ich in den commit-Texten dann auch Korrekturhinweise zu vorigen Änderungen beschrieben. Die Commits sind dann auch so in den Standard Branch gekommen. Meine Frage ist nun, war das sinnvoll die fixes oder auch Änderungen innerhalb des Feature Branch zu beschreiben. Denn so könnte man das von Ihnen beschriebene Verfahren nicht sinnvoll anwenden.
[gr] Ja, das stimmt wohl … wir machen es so, dass wir beim Mergen eines Feature-Branches in den main-Branch immer squashen, und deshalb gibt es pro Feature bei uns am Ende nur genau einen Commit - und der bekommt eben das passende Präfix. Wenn man das nicht macht, dann ergibt sich die neue Versionsnummer auf main natürlich aus der Folge der Präfixe im Feature-Branch, das heißt, dort muss man dann ein bisschen vorsichtiger sein.
Ein wirklich sehr gutes Video und ein toller Ausgangspunkt, das Thema zu vertiefen. Vielen Dank! Gibt es eventuell eine Übersicht, welche Präfixe "Ihr" in get-next-version verwendet? Vielleicht könnt Ihr das in die Doku einbauen? Oder ich habe es übersehen. 🙂
Ich mag dein Beispiel, das Tool und deine Erklärung, gute Arbeit 👍 Würde mir aber nochmal ein Update dazu wünschen, weil wenn ich das richtig verstehe und ein PR gemerged wird wo dann drei feat commits drin sind sollte er nicht 3 minor Versionen hoch. D.h. man muss einstellen das alle Änderungen beim mergen zu einem zusammengeführt werden. Außerdem wäre es noch cool mal einen Constraint einzubauen, wenn die PR keinen gültigen Präfix mitbringt, dann abzulehnen, dann kann das Tool auch nicht falsch arbeiten ...so als Idee :)
[gr] Vielen Dank für Deinen Kommentar 😊 Wenn ein PR gemerged wird, wo drei Commits mit feat drin sind, dann zählt das Tool nicht um drei Versionen hoch, sondern nur um eine. Also wenn Du zB auf 5.1.0 stehst, und dann drei Commits mit "feat" hast, dann ergibt das die 5.2.0. Es geht nicht darum, wie viele Commits das jeweils sind, sondern nur, welche Typen von Commits auftauchen. Und Präfixe, die nicht gültig sind, werden von uns als chore behandelt, sprich ignoriert. Insofern wird dann auch keine falsche Version ermittelt, sondern es passiert einfach gar nichts.
Sehr cooles tool! Ich habe allerdings eine Frage bezüglich der Version 0. Meines Wissens gibt es bei der Version 0.x.y keine Garantien bei SemVer. D.h. man kann tun und lassen was man möchte. Ist euer Ansatz da einfach nur "feat!" zu nutzen, wenn ihr 1.0.0 releasen wollt, oder gibt es hierfür ein spezielles Handling, sodass man "feat!" auch nutzen kann ohne gleich auf 1.0.0 zu gehen? Danke! Natürlich könnte man das Tool einfach erst ab 1.0.0 einsetzten :)
[gr] Ja, das stimmt … für die 0.x.y-Reihe gelten Sonderregeln, wobei ich ehrlicherweise sagen muss, dass ich das nie besonders intuitiv fand. Meine persönliche Faustregel (und das ist auch das, wie wir es in get-next-version umgesetzt haben) ist, wenn Du nicht möchtest, dass schon eine 1.x daraus wird, dann flagge es halt nicht mit einem Ausrufezeichen 😉 Also im prinzip folgen wir hier den "ganz normalen" Regeln, und der Schritt zur 1.0.0 ist dann halt der erste Breaking-Change (auch wenn das dann technisch nicht ganz korrekt sein mag).
Schließe mich meinem Halben-Namensvetter an: Conventional Commits hatte Ich so noch nicht gehört. Habe aber in verschiedenen Repositories schon seit einigen Monaten Pull Requests gesehen, die mit '[chore]' beginnen. Bisher hauptsächlich GitHub Actions die 3rd Party Libraries aktualisieren etc. Habe mir mal ein Lesezeichen zu get-next-version gesetzt. Super Ergänzung für Semantic Versioning. Muss mir mal anschauen ob man die Action so konfigurieren kann, das diese ausschließlich manuell ausgeführt wird: Als Hobby Programmierer brauche Ich keine (ständige) automatische Ausführung für meine kleinen Projekte. Wie immer super Video! Weiter so! P.S.: Ist es normal das Ihr am Sonntag Videos aufnehmt (wie man den Git Log Zeitstempeln entnehmen kann)? Ich hoffe für euer Privatleben und eure Gesundheit, das sowas eine Ausnahme ist. #StaySafeStayHealthyEveryone :)
[gr] Vielen Dank für das Lob 😊 Eine klitzekleine Kleinigkeit: Der Name ist "Conventional Commits", nicht "General Commits". Wollte Dich da jetzt nicht unbedingt korrigieren, aber sonst wird's schwierig, dazu mehr Details zu finden. Die Beschreibung zu Conventional Commits findest Du übrigens unter www.conventionalcommits.org/en/v1.0.0/ Was die Aufnahme am Sonntag angeht … mal so, mal so. Hängt immer davon ab, wie es zeitlich unter der Woche ausschaut. Also es ist nicht die Regel, aber auch nicht die Ausnahme 😉
@@thenativeweb Hallo. Keine Ahnung warum Ich "General Commits" geschrieben habe - in meinem Hirn schwebte definitv "Conventional Commits" beim schreiben. Hebephrene Schizophrenie und andere Mental Issues sind eine blöde Kombi immer wieder. Egal, habe meinen Kommentar korrigiert. Danke für den Link. Werde Ich mir mal genauer anschauen. Ein schönes und erholsames Wochenende Dir, de[ine]m Team und allen anderen zufällig lesenden :) #StaySafeStayHealthyEveryone
Sag mal OT: Was machst eigentlich für Musik? Das eine Viech im Hintergrund schaut aus wie nen kleines Masterkeyboard. Und was größeres (über mehr Oktaven) habe ich noch nicht gesehen. Also bist kein Pianist / Keyboarder / "klassischer Musiker" - sondern benutzt es eher für kleinere Melodie- oder Basslines. Dann vor dir sone Art 808 Nachbaute? Deswegen meine Vermutung: Techno / House / Elektro?
Ich muss mal ne blöde Zwischenfrage stellen: Ist Copilot wirklich in der Lage aus den conventional commit prefixes die korrekte Versionsnummer herzuleiten?
Hey Golo. Du sagst im Video bei euch darf niemand auf main pushen sondern nur aus Feature branches mergen. Passiert das dann über Pullrequests oder seid ihr wirklich so konsequent da immer manuelles Codereview zu machen?
[gr] Ja genau, ein direkter Push auf main ist nicht erlaubt. Das heißt, für jede Änderung musst Du den Weg über einen gesonderten Branch + Pull-Request gehen, der seinerseits wiederum gereviewed und freigegeben werden muss. Es ist also garantiert, dass immer mindestens zwei Personen Code gesehen haben, der in main landet.
Tolles video danke dafür. Das Tool gefällt mir auch gerade wege dem Pragmatismus. Ich vermute mal, dass einfach die gesamte Commit-Historie durchgegangen wird. Daher ist es wohl für Monorepos leider nur bedingt geeignet. Könnt ihr das bestätigen?
[gr] Vielen Dank für das Lob 😊 Was Deine Frage nach den Monorepos angeht - wir arbeiten nicht mit Monorepos, daher weiß ich gerade aus dem Stegreif nicht genau, worauf Du hinauswillst. Kannst Du die Frage ein bisschen näher umreißen?
@@thenativeweb Danke für die Rückmeldung. Ein Monorepo besteht normalerweise aus einem root-Verzeichnis (mit package.json) und einer irgendwie gearteten Unterordnerstruktur von Modulen. Zum Beispiel /packages/moduleA/package.json. Alle module sind dann im selben Git-Repo organisiert. Wenn ich nun die nächste Version für eines der Module ermitteln will, dürfen in der Commit-Historie nur die Commits berücksichtig werden, welche Dateien in dem Unterordner geändert haben. In dem Beispiel dann alles unter /packages/moduleA. "Babel" organisiert zum Beispiel sein Repo so.
2 года назад
Gibt es auch schon was für GitLab? Die Idee gefällt mir, aber GitHub ist nicht immer möglich.
[gr] Nicht direkt, weil wir kein GitLab nutzen (und daher auch nichts speziell für GitLab entwickelt haben) - aber es spricht natürlich nichts dagegen, dass Du Dir einfach das Binary für Deine Plattform von github.com/thenativeweb/get-next-version/releases herunterlädst, und es zB im Rahmen eines Bash-Scripts von Hand ausführst. Damit hast Du letztlich denselben Effekt. Hope that helps 😊
Kleines Feedback: Mir ist aufgefallen, dass deine Bildschirmaufnahmen etwas unscharf und mit Artefakten belastet sind. Könntest du da evtl. eine bessere Qualität einstellen?
[gr] Danke für Dein Feedback 😊 Uns ist das Problem bewusst, allerdings finden wir die Ursache nicht (obwohl wir schon sehr viel ausprobiert haben) … insofern gucken wir da zwar immer wieder, ob wir nicht doch noch etwas finden, aber einfach ist es leider nicht, weil's nicht die offensichtlichen Sachen (Internetverbindung, Netzwerk, Streaming-Software, …) sind.
Ich habe ein Verständnisproblem mit den Bezug der konventional Commits. Angenommen ich bin auf einem feature Branch auf welchem ich eine neue API hinzufüge. Dann sähe meine Branch bisher vielleicht so aus: feat => doc. Jetzt stellt ich bei doc fest, dass meine neue öffentliche Funktion, einen Typo hat. Ich ändere dies, aber wie wird mein nächster Commit benannt? feat!, weil ich zum letzten Commit eine Funktion hinzufügt und eine ändere? Oder chore, weil ich nur Kleinigkeiten geändert habe und vor allem in Bezug auf mein letztes Release nur eine Funktion hinzugefügt habe? Ich fände Zweiteres deutlich sinnvoller, aber ich finde auch in der offiziellen Doku immer nur Beispiele welche sich von Commit zu Commit hangeln. PS. Ich weiß das ich mit Git auch die Historie ändern könnte, aber für diese Beispiel möchte ich kurz annehmen dass ich das nicht kann/will/darf.
golo macht seine action nur auf main aktiv. Wenn du also innerhalb einer feature branch (ohne releases) bist hast du auch keinen breaking change. Wenn du aber einmal mit typo releast hast musst du auch den major hoch zählen wenn deine API sich "breaking" changet - und sei es nur ein typo :D
[gr] Solange Du noch in Deinem Feature-Branch bist und nicht gemerged hast, würde ich das als chore, bestenfalls als fix ansehen. Innerhalb des Branches wird auch keine neue Version gebaut und released, das passiert immer nur ausschließlich auf main. Wir bei the native web squashen ohnehin jeden PR vor dem Mergen, insofern zählt für main am Ende nur, als was der PR getaggt wird. Aber auch, wenn man nicht squasht: Solange der Typo noch nicht released war, ist es kein Breaking Change, weil es eh noch keine öffentlich verfügbare Version gab, in der der Typo enthalten gewesen wäre. Hope this helps 😊
