Vereinfachung des Branch- und Nighly-Build-Managements

[tolot27]

In #482 (comment) hatte ich folgendes vorgeschlagen, was jedoch besser in einem neuen Thread diskutiert werden sollte.

Für ein besseres Branch- und Nighly-Build-Management schlage ich folgende Punkte vor:

• Einführung einer neuen Branch-Nomenklatur
  • Einführung der Branches "next-major", "next-minor" und "next-hotfix", statt "feature-x.y.z"
  • zukünftige lokale Feature-Branches im eigenen Fork haben den Präfix "feature/"
  • zukünftige lokale Bugfix-Branches im eigenen Fork haben den Präfix "bugfix/"
  • (zukünftige lokale Patch-Branches im eigenen Fork haben den Präfix "patch/")
• intensive Nutzung von git rebase bei den jeweiligen Branches; das Konfliktmanagement ist identisch zu git merge
• automatisches mergen bzw. rebasen von Bugfix-Branches nach "next-hotfix", nachdem die jeweiligen PRs in master gemerged wurden.
  • Hier könnte man überlegen, ob man die Hotfixes nicht gleich automatisch erzeugt, da es ja nicht umsonst Hotfixes sind.
• automatisches rebasen von "next-minor" nach "next-major", wenn ein Feature-PR gemerged wurde. Damit braucht man keine PRs für merging von Features nach next-major.
• (automatisches) Erzeugen von Tags bei Releases (minor, major, hotfix)

Die Branch-Präfixe haben den Vorteil, dass man die Automatisierung mit den GitHub Actions leicht bewerkstelligen kann. Um momentan automatisiert ein nightly auf der aktuellen feature branch zu erstellen, muss man entweder die aktuelle Versionsnummer tracken (woher ohne auszuchecken?) oder hoffen, dass keine Tippfehler in den branch names sind und man mit git branch -a --sort=-committerdate --no-merged master --list "feature-*" | sort -V | head -n 1" die richtige nächste feature branch bestimmen kann.

[tolot27]

Die Kommentare von @lenilsas hatte ich bereits in #482 (reply in thread) beantwortet.

Die Kommentare bzw. Fragen von @JohannMaierhofer (#482 (reply in thread)) beantworte ich hier:

Branches die "feature/feature-3.1.0" heißen, sollte es nicht geben. Vielmehr sollte man seine Branches z. B. "feature/Sollbuchung_Nr" oder von mir aus auch "feature/JohannMaierhofer/Sollbuchung_Nr" nennen, nicht jedoch Versionsnummern da rein codieren, wie es momentan bei JohannMaierhofer:3.1_Sollbuchung_Nr der Fall ist.

Warum nicht. Ich mache Bug fixes die müssen in den Main Branch und Features, die müssen dann in den feature-3.1.0 Branch. Damit ich da nicht durcheinander komme für was ein Branch ist habe ich die Nummer davor gemacht. Das sollte doch kein Problem sein. Und den PR stelle ich ja auch selbst.

Das ich deinen obigen Branch-Namen gewählt habe, war nicht gegen dich gerichtet, sondern nur ein Beispiel. Natürlich kannst du das bei dir lokal weiter so machen, wie du es für praktisch hältst. Ich gebe jedoch zu bedenken, dass ein Feature nicht zwangsweise mit der nächsten minor/major Version released werden muss, sondern vielleicht auch erst in der übernächsten oder noch später. Dann passt der branch name nicht. Daher war mein Vorschlag, dass man sowohl bei den feature branch names als auch bei den lokalen branch names auf Versionsnummern verzichtet. Durch die geänderte Nomenklatur werden die lokalen branches nach meiner Ansicht übersichtlicher.

Wenn da etwas automatisch per Script oder Action gemacht werden soll was am Namen abgeleitet wird, dann ok, aber das sehe ich momentan hier nicht. Wenn es einen Grund gibt das anders zu machen schließe ich mich dann natürlich an.

Mit #700 fangen wir ja mit der Automatisierung an. Dort ist

Ich verstehe auch noch nicht ganz wie die Bugfixes automatisch in den Feature Branch kommen sollen. Beim letzten Mal hatte ich den Kommentar auch die Version im plugin.xml auf 3.0.2 zu setzen. Das darf aber doch so nicht in den 3.1.0 Branch.

Die Version in der plugin.xml sollte eigentlich nur geändert werden, wenn die Branch angelegt oder bevor ein Build erzeugt wird. Zwischendrin könnte man sie bei merges/rebases ignorieren.

Das mit dem Rebase verstehe ich auch nicht. Wenn ein PR akzeptiert ist bietet mir Git im Browser an den PR zu mergen. Was müsste ich da machen dass er ein Rebase macht? Und warum eigentlich Rebase, ich dachte, da wird dann meine ganze Kommit Historie mit übertragen. Aber im Main oder dem Feature Branch braucht man die doch garnicht. Da reicht es doch wenn das fertige Feature so wie es ist rein kommt.

Es geht nicht um das mergen eines PRs in den Master, sondern dann darum, wie dieser commit (ist ja nur einer, da squash-merge) in den/die anderen branches kommt. Das soll per rebase passieren. Und nein, da wird nicht deine ganze Commit-Historie übertragen, da sie ja squashed wird. Und wenn kein squashing gemacht wird, dann würde ja auch nur die commit history des PRs nach master gemerged. Ich bin nicht wirklich ein Fan von squashing, da man da nicht mehr nachvollziehen kann, welcher commit genau ein Problem verursacht hat und kann dann auch nicht diesen einen Commit rückgängig machen. Daher räume ich meine Commits immer so auf (z. B. auch mit commit --amend bzw. cherry-picks), dass die History auch mit übertragen werden kann.

[mbmueller]

• Wenn nötig merge ich diese Branches dann lokal auch in meine Feature Branches um sie auf den aktuellen Stand zu bringen oder Merge Konflikte zu beheben

Hier, statt dem Merge einen Rebase verwenden, da dieser die Git Historie nicht verändert (insbesondere keinen Merge Commit erzeugt)

Ich habe aber tatsächlich mit Rebase auch Probleme. Wenn ich einmal einen Rebase ausführe, der Konflikte produziert und dann später nochmal rebase, dann muss ich diese Konflikte ein zweites mal manuell lösen. Das habe ich bei einem Merge nicht.

[lenilsas]

Ich habe auch im Fork und Lokal zwei Branches master und feature-x.y.z, je nachdem ob es ein Feature oder ein Bugfix ist erstelle ich einen Branch auf dem entsprechenden Branch an dem ich arbeit um schlussendlich einen PR zu erstellen. Da ist normalerweise kein Merge oder Rebase notwendig. Wenn ein anderer PR gemergt wurde synchronisiere ich es und merge meinen PR da rein. Von dem Merge bekommt man schlussendlich aber nicht wirklich etwas mit, da es ja gesquashd wird. Was wäre dabei der Vorteil von Rebase? Ich denke das kann jeder so machen wie es ihm besser passt, da es in die Arbeit der anderen nicht eingreift.

Zu den Nigthlies denke ich, dass diese auf dem FeatureBranch erstellt werden sollten. Es geht ja darum neue, noch nicht freigegebene Features, vorab zu verwenden. Denn Sinn sehe ich auch darin, dass wir von erfahrenen Nutzern die die Nigthlies verwenden Rückmeldungen und eventuelle Fehler gemeldet bekommen können die dann beim Release nicht mehr auftreten und somit nicht alle User treffen.
Auch verwende ich bei mir immer den Feature Branch für meine JVerein Installation damit ich auch bei der normalen Arbeit Fehler bemerke. Das fände ich auch sinnvoll, wenn andere das auch so machen, denn nur so können wir Fehler oder ungünstige Änderungen bemerken die man beim gezielten Testen nicht bedacht hat.

[JohannMaierhofer]

• Wenn nötig merge ich diese Branches dann lokal auch in meine Feature Branches um sie auf den aktuellen Stand zu bringen oder Merge Konflikte zu beheben

Hier, statt dem Merge einen Rebase verwenden, da dieser die Git Historie nicht verändert (insbesondere keinen Merge Commit erzeugt)

Ich habe mal nachgelesen, was rebase macht. Es schiebt meinen Branch an das Ende von Main/feature-3.1.0. Dabei werden alle meine Commits in dem Branch angepasst so dass sie jetzt auf dem letzten Stand von Main/feature-3.1.0 basieren. Also nichts von Historie nicht anpassen, es ist genau das Gegenteil. Und es kann anscheinend riskant sein bei Konflikten. Beim Merge kann ich genau sehen wenn es Konflikte gibt und ich kann sie an dieser Stelle lösen.
Mir macht der zusätzliche Merge commit nichts aus und später wird der Branch sowieso gelöscht wenn der PR gemerged wurde.

[tolot27]

Ich habe mal nachgelesen, was rebase macht. Es schiebt meinen Branch an das Ende von Main/feature-3.1.0. Dabei werden alle meine Commits in dem Branch angepasst so dass sie jetzt auf dem letzten Stand von Main/feature-3.1.0 basieren. Also nichts von Historie nicht anpassen, es ist genau das Gegenteil. Und es kann anscheinend riskant sein bei Konflikten. Beim Merge kann ich genau sehen wenn es Konflikte gibt und ich kann sie an dieser Stelle lösen.

Natürlich verändert rebase die Historie, indem alle upstream gemergten/rebasten Commits in die Historie deines PRs eingebaut werden. Dabei werden jedoch nicht deine Commits verändert. Sollte es zu Konflikten kommen, sind es genau die gleichen Konflikte, die auch bei einem merge auftreten würden, allerdings feingranularer genau bei dem upstream commit, wo der Konflikt auftritt. Und es sind auch genau die gleichen Konflikte, die dir online auf GitHub bei deinem PR angezeigt würden.

[tolot27]

Ich habe aber tatsächlich mit Rebase auch Probleme. Wenn ich einmal einen Rebase ausführe, der Konflikte produziert und dann später nochmal rebase, dann muss ich diese Konflikte ein zweites mal manuell lösen. Das habe ich bei einem Merge nicht.

Das sollte eigentlich nicht passieren, außer die gleiche Stelle einer Datei wird sowohl upstream als auch von dir geändert oder deine Datei basiert noch auf einer viel früheren Version. Dann ist es logisch, dass es immer wieder zu Konflikten kommt.

Sich wiederholende merge conflict resolutions kann man übrigens auch automatisieren, indem man

git config --global rerere.enabled true
git config --global rerere.autoupdate true

ausführt. Das --global ist dabei jeden selbst überlassen.

[dippeal]

1. Ich würde das rebase bei der Überführung vom feature branch in den master machen. In diesem Artikel finde ich das Verhalten gut verdeutlicht: https://www.atlassian.com/git/tutorials/merging-vs-rebasing
2. Das nightly build auf den feature branch zeigen zu lassen finde ich notwendig. Hier der PR: Build nightly feature branch instead of main #704. Die bugfixe im master sind, meiner Meinung nach, nicht groß "testwürdig" nach den erfolgreichen reviews
3. Ob jetzt eine commit message mehr oder weniger in der Historie ist, so what. Mir wäre es wichtiger aussagekräftige messages zu haben.
4. Ich verstehe den Willen ein ganz aufgeräumtes repo zu haben, aber wir sind hier auch keine große Softwareschmiede...

[tolot27]

• Ob jetzt eine commit message mehr oder weniger in der Historie ist, so what. Mir wäre es wichtiger aussagekräftige messages zu haben.

Genau das ist mir auch wichtig. Daher bin ich kein Fan von Squashing.

• Ich verstehe den Willen ein ganz aufgeräumtes repo zu haben, aber wir sind hier auch keine große Softwareschmiede...

Das will ich gar nicht. Ich möchte lieber 3. erreichen und dann nicht zig commit messages mit "Merging ..." sehen. Mein Vorschlag ist also eher als eine Vorbereitung für eine Zeit mit weniger Squashing und nachvollziehbaren kleinen commits mit aussagekräftigem Titel und ggf. Beschreibung zu sehen.

[mbmueller]

Daher bin ich kein Fan von Squashing.

Ich finde squashing eigentlich schon ganz gut, so muss ich mir beim arbeiten keine Sorgen um meine Git-Historie machen bzw. diese hinterher wieder aufzuräumen.
Teilweise (auch wenn das Bad Practice ist) habe ich bspw. Commits die nicht builden, das liegt daran, dass ich teilweise meinen Desktop mit meinem Laptop synchronisieren möchte aber aktuell keinen Stand habe in dem die Software buildet.

Ich weiß aber auch, dass das eben Bad Practice ist und wäre bereit mich anzupassen, falls das die Mehrheitsmeinung hier ist.

[JohannMaierhofer]

1. Ich würde das rebase bei der Überführung vom feature branch in den master machen. In diesem Artikel finde ich das Verhalten gut verdeutlicht: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Genau den Artikel hatte ich mir auch angeschaut.
Aber ich überführe ja nie einen Feature Branch in den master. Ich pushe den feature branch in meinen fork und mache dann den PR. Der wird in den Master gemerged, den synchronisiere ich in meinen Fork und mache dann den Pull um ihn in mein lokales Repository zu holen. Dann habe ich den upstream/original Master bei mir.
Also wird bei mir nie ein Feature/Bugfix Branch in den main/feature-3.1.0 Branch gemerged oder ein rebase gemacht.
Bei mir passiert nur der umgekehrte Weg und das ist den main/feature-3.1.0 nach einer Synchronisation in den Feature Branch zu mergen um Merge Konflikte aufzulösen.

Wenn ich lokal meinen Feature Branch in den Main rebasen würde, dann würde mein lokaler Main ja ganz anders ausschauen als der Main im JVerein Repository. Das will ich aber nicht.

Oder ich verstehe das nicht ganz. Jedenfalls hat das bisher sehr gut funktioniert.

[tobidope]

Ich habe @tolot27 Beschreibung und die aktuellen Branches noch nicht in Einklang bringen können

In #482 (comment) hatte ich folgendes vorgeschlagen, was jedoch besser in einem neuen Thread diskutiert werden sollte.

Für ein besseres Branch- und Nighly-Build-Management schlage ich folgende Punkte vor:

* [ ]  Einführung einer neuen Branch-Nomenklatur
  
  * [ ]  Einführung der Branches "next-major", "next-minor" und "next-hotfix", statt "feature-x.y.z"
  * [ ]  zukünftige **lokale** Feature-Branches im eigenen Fork haben den Präfix "feature/"
  * [ ]  zukünftige **lokale** Bugfix-Branches im eigenen Fork haben den Präfix "bugfix/"
  * [ ]  (zukünftige **lokale** Patch-Branches im eigenen Fork haben den Präfix "patch/")

Wir haben aktuell

• master
• feature-3.1.0
• bugfix-3.0.1
• mbmueller-formatierung
• zukunft_beitragsgruppen_button
• buildCheck
• openjverein-2.8.24
• dippeal-release-2-8-23
• dippeal-v2.8.22

Davon scheint mir noch keiner der neuen Nomenklatur anzugehören. Korrekt?

Von welchem Branch werde ich in Zukunft aus starten? Kann ich noch master benutzen?

Das Konzept erscheint mir auf dem erstem Blick recht schwergewichtig. Was ist die Intention dahinter? Wie viele Versionen sollen parallel unterstützt werden? Eine neue Major und kontinuierlich minor und bugfixes für die zuletzt herausgegebene?

[tolot27]

Active branches:

• master
• feature-3.1.0

Erzeugt durch direktes Pushen zu upstream anstelle von origin (vermutlich unbeabsichtigt, zumindest in meinem Fall [ersten beiden Branches])

• bugfix-3.0.1
• buildCheck
• mbmueller-formatierung
• zukunft_beitragsgruppen_button

Stale branches:

• openjverein-2.8.24
• dippeal-release-2-8-23
• dippeal-v2.8.22

Davon scheint mir noch keiner der neuen Nomenklatur anzugehören. Korrekt?

Ja, dass ist korrekt, da der Nomenklatur-Vorschlag ja viel neuer ist, als die branches und die branches auch nicht gelöscht bzw. umbenannt werden können (zumindest von den meisten Contributors), da sie protected sind. Sonst hätte ich meine beiden schon längst wieder gelöscht. Ich glaube, jemand mit entsprechenden Berechtigungen kann alle bis auf master und feature-3.1.0 löschen

Von welchem Branch werde ich in Zukunft aus starten? Kann ich noch master benutzen?

Ja, master kann als upstream für neue PRs dienen. Besser ist jedoch, feature-3.1.0 zu verwenden. Master wird da eh mit #700 bzw. #705 automatisch reinsynchronisiert. Ich lege meine Branches wie folgt an: git checkout -b feature/mynewfeature remotes/upstream/master. Du hattest ja auch schon mal feature/mavenBuild angelegt.

Jeden Tag mache ich bevor ich anfange, zu entwickeln, ein git checkout master && git fetch --tags -f --prune upstream && git merge upstream/master && git push um meinen lokales repository zu aktualisieren und in meinen Fork zu pushen. Danach mache ich min meiner PR-branch ein git rebase um mich mit master bzw. feature-3.1.0 neu zu basen.

[JohannMaierhofer]

Von welchem Branch werde ich in Zukunft aus starten? Kann ich noch master benutzen?

Ja, master kann als upstream für neue PRs dienen. Besser ist jedoch, feature-3.1.0 zu verwenden. Master wird da eh mit #700 bzw. #705 automatisch reinsynchronisiert. Ich lege meine Branches wie folgt an: git checkout -b feature/mynewfeature remotes/upstream/master. Du hattest ja auch schon mal feature/mavenBuild angelegt.

Ich dachte, im Master machen wir nur Bug Fixes die in einer 3.0.x münden. Und im feature-3.1.0 machen wir die reguläre Weiterentwicklung mit neuen Features.
Also sollte man bei Bug fixes doch bei main starten und bei neuen Features bei feature-3.1.0. Oder nicht.

[JohannMaierhofer]

Ich hätte noch eine Frage zu unserem Docu Repository.
Ich bin hier genauso vorgegangen wie beim Code Repostory. Also mit Fork und dann PR. Wenn ich aber den PR committe werden immer zwei Commits erzeugt. Ich habe bei anderen gesehen, dass es da nur einer ist.
Was mache ich falsch bzw. wie sollte ich hier vorgehen?