Gitflow workflow

Hallo zusammen,

ich habe mich ein wenig mit Branchingmodellen befasst. Derzeit sieht das Repository ziemlich linear aus.
Wie wäre es mit dem gitflow workflow, um Ordnung und Übersicht in die Branches zu bringen?

Sieht soweit ganz sympathisch aus, aber lohnt sich das schon? Wie du sagst, zur Zeit ist alles linear.

Naja, was heißt “lohnen”. Im Gegensatz zum Ansatz mit Master- und Featurebranches ändert sich ja eigentlich nicht viel. Die Rolle des master-Branches nimmt stattdessen ein development-Branch ein.
Mehr Aufwand bedeutet das eigentlich nicht - es sind nur andere Konventionen.

*** Edit ***

Jetzt hab ich den wichtigsten Punkt vergessen: jetzt am Anfang des Projektes kann man solche Konventionen ohne Aufwand festlegen und es ist alles stringent. Wenn man sich später umentscheidet, dann hat man irgendwo einen Bruch.

Ich würde das auch lieber von Anfang an “richtig” machen, schon allein deswegen, weil man sich dann später nicht an eine andere Arbeitsweise gewöhnen muss. Den optischen “Bruch” in der git-Historie halte ich dagegen für verschmerzbar…

bye
TT

OK, überzeugt…

Ist wahrscheinlich nur Gewohnheitssache, aber ich würde vorschlagen, unseren “master”-Branch als das zu verwenden, was dort “development” ist, und einen neuen Branch “release” anzulegen, der dem dortigen “master” entspricht.

Kann man natürlich auch machen. Aber ich denke, dass die Idee dahinter, einen development branch zu nehmen die ist, dass jemand, der den Master-Branch auscheckt immer die aktuellste, lauffähige Version der Anwendung erhält.
Im Endeffekt ist es, wie oben ja schon geschrieben, nur eine Konvention, die man festlegen muss.

[QUOTE=cmrudolph]Naja, was heißt “lohnen”. Im Gegensatz zum Ansatz mit Master- und Featurebranches ändert sich ja eigentlich nicht viel. Die Rolle des master-Branches nimmt stattdessen ein development-Branch ein.
Mehr Aufwand bedeutet das eigentlich nicht - es sind nur andere Konventionen.

*** Edit ***

Jetzt hab ich den wichtigsten Punkt vergessen: jetzt am Anfang des Projektes kann man solche Konventionen ohne Aufwand festlegen und es ist alles stringent. Wenn man sich später umentscheidet, dann hat man irgendwo einen Bruch.[/QUOTE]

Das wird dann aber relativ schnell rebase-lastig, v.a. wenn man sich mit dev aktuell halten möchte und eben nicht haufenweise merge-commits á la "merged dev into im dev-Zweig sehen möchte. Persönlich habe ich damit kein Problem, bei OSS-Projekten ist es auch oft üblich zu einem pull-Request die Antwort zu erhalten rebase dich mal auf den aktuellen dev-Stand.

Des Weiteren wenn mehrere Leute auf einem Branch arbeiten stellt Clientseitig defintiv etwas wie git config --global branch.autosetuprebase always ein sonst gibt es schöne Diamanten ;). Genauso gehört auch ein Serverskript dazu das force-push auf Branches wie dev untersagt. Und nicht zu vergessen das eine einheitliche EOL-Konvertierung (auch für Ausnahmen) eingestellt werden sollte, d.h. Git-Optionen und .gitattributes.

Ach ja und um dem ganzen noch einen draufzusetzen, die case-sensivitität/insensitivität der File-Systeme kann immer noch Probleme verursachen, dann gibt es Files doppelt auf einem System und auf dem anderen nicht usw.

Das selbe Problem hat man aber auch, wenn man mit feature-branches arbeitet.

Da wäre die Frage, ob man das bei github einstellen kann.

Da hatte ich auch schon häufiger mal Probleme mit… Wenn ich mal eine Klasse umbenannt habe (mittendrin ein Großbuchstaben statt Kleinbuchstaben) und die Datei schon im repository war, dann merkt Windows nicht, dass sich was geändert hat. Da konnte ich dann die Dateien nicht mehr committen und um auf einen einheitlichen Stand zu kommen blieb nichts anderes übrig, als die Datei in zwei Commits komplett umzubenennen und diese Commits dann zusammenzuführen.

[QUOTE=cmrudolph]Das selbe Problem hat man aber auch, wenn man mit feature-branches arbeitet.

Da wäre die Frage, ob man das bei github einstellen kann.

Da hatte ich auch schon häufiger mal Probleme mit… Wenn ich mal eine Klasse umbenannt habe (mittendrin ein Großbuchstaben statt Kleinbuchstaben) und die Datei schon im repository war, dann merkt Windows nicht, dass sich was geändert hat. Da konnte ich dann die Dateien nicht mehr committen und um auf einen einheitlichen Stand zu kommen blieb nichts anderes übrig, als die Datei in zwei Commits komplett umzubenennen und diese Commits dann zusammenzuführen.[/QUOTE]
Das mit dem rebase war nur eine Anmerkung auf was man sich einlässt, es gibt durchaus Leute die regelrecht Angst vor derartigen Tools haben oder sogar verbreiten.
Mit der Groß-/Kleinschreibung bekommst du das unter Windows IMHO mit ignorecase = true in den Griff. Das ist aber, soweit ich weiß, keine Endlösung wenn Entwickler von verschiedenen Systemen das Repo bespielen. Das sollte ausprobiert werden, ob es mit den neueren Git-Versionen besser läuft oder ob Github das intern irgendwie harmonisiert und man sich nicht darum kümmern muss.
Dann fehlt noch das Thema Branchnamen, gewisse Namensräume sind durch “Gitflow” schon vorgegeben, aber auch für Branchnamen sollten Regeln gelten, wie alles klein, keine Umlaute, Sonderzeichen etc. sonst erlebt man unter Umständen auch wunderliche Dinge mit Git.

@ThreadPool : danke für die weiteren Ausführungen. Als (derzeit noch) Hobby-Entwickler versuche ich so viel wie möglich über den richtigen Umgang mit Versionsverwaltung und im Buildmanagement zu lernen. Mangels direktem Austausch mit professionellen Entwicklern dauern die Lernprozesse natürlich sehr viel länger. Beiträge von Erfahrungsträgern wie hier in diesem, aber noch mehr wie in dem Thread zum Continuous Deployment, helfen sehr weiter.

Ich habe gerade zum ersten Mal in den “originalen” Blogbeitrag zu gitflow gesehen und dort bestätigt sich meine in #7 aufgestellte Theorie:

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

[QUOTE=cmrudolph]
Ich habe gerade zum ersten Mal in den “originalen” Blogbeitrag zu gitflow gesehen und dort bestätigt sich meine in #7 aufgestellte Theorie:[/QUOTE]

Eine einfache Übersicht gibts auch unter https://www.atlassian.com/git/tutorials/comparing-workflows/ und ich bin mir sicher es gab mal ein Webinar von Atlassian in dem sie auch darüber sprachen wie das CI und der Branchingworkflow für das Produkt Atlassian-Stash (auch eine Webanwendung) ablaufen. Vll. findet es sich wieder an aber die hatten IMHO einen reduzierten Git-Flow.

Damit hast du jetzt den Link aus dem Eröffnungsbeitrag gepostet :wink:
Das Webinar wäre bestimmt interessant für mich - ich arbeite bei meinen privaten Projekten auch mit Stash (10 Euro pro Jahr ist mir die Lizenz allemal wert).

Der im originalen Blogbeitrag beschriebene Workflow eignet sich perfekt für CI / CD, aufgrund des einen Branches, der nur stabile Anwendungssnapshots enthält (hier der master-Branch) und des Branches, der den aktuellen Entwicklungsstand repräsentiert (hier der develop-Branch).

Bedenken macht mir nur die Aussage, dass Featurebranches hauptsächlich lokal sind. Das hat natürlich den Vorteil, dass man problemlos rebasen kann und die commit history nicht verschmutzt wird. Das bedeutet aber auch, dass ein Feature nur von einem einzigen Entwickler produziert wird und sehr klein ist.

[QUOTE=cmrudolph]Damit hast du jetzt den Link aus dem Eröffnungsbeitrag gepostet :wink:
Das Webinar wäre bestimmt interessant für mich - ich arbeite bei meinen privaten Projekten auch mit Stash (10 Euro pro Jahr ist mir die Lizenz allemal wert).

Der im originalen Blogbeitrag beschriebene Workflow eignet sich perfekt für CI / CD, aufgrund des einen Branches, der nur stabile Anwendungssnapshots enthält (hier der master-Branch) und des Branches, der den aktuellen Entwicklungsstand repräsentiert (hier der develop-Branch).

Bedenken macht mir nur die Aussage, dass Featurebranches hauptsächlich lokal sind. Das hat natürlich den Vorteil, dass man problemlos rebasen kann und die commit history nicht verschmutzt wird. Das bedeutet aber auch, dass ein Feature nur von einem einzigen Entwickler produziert wird und sehr klein ist.[/QUOTE]

Oh, das mit dem Link hab ich gar nicht bemerkt. :wink: Mit den feature-branches das ist Definitionssache, es hält dich niemand davon ab mit mehreren Leuten auf einem Feature-Branch zu arbeiten, wie schon erwähnt sollte dann branch.autosetuprebase bei jedem eingestellt sein. Es bleibt nur noch die Frage wie aktualisiert man sich mit “dev”, ich bevorzuge da ein rebase des Feature-Branches, das hat jedoch zur Folge das alle Mitentwickler des Features lokal ihre Branches wegwerfen und neu auschecken müssen (der einfachste Weg), bzw. ihre privaten Commits dann auf den nun aktuellen Feature-Branch kopieren müssen (etwas komplizierter). Das ist jedoch alles nur eine Frage der Koordination und den Git-Skills der Beteiligten.

Der interne Stash-Team-Worfklow ist hier erläutert Inside Atlassian: feature branching on the Stash team - Atlassian Blogs. Der ist wirklich simpel und vergibt dem Thema “sehr ordentlich Historie” eine nicht ganz so hohe Priorität, setzt aber verschiedene Dinge voraus wie das Branches automatisch gemerged werden usw.
Ein ganz gute Webinaraufzeichnung zu den Workflows Git workflows webinar recording now available. Diese Aufzeichnung beinhaltet so ziemlich auch die Informationen aus vorhergegangenen Atlassian-Webinars zu Git.

Naja, du kannst einen Feature Branch ja noch weiter in einzelne Branches aufteilen, Sub-Features sozusagen ^^

@ThreadPool : ich habe mir deine Links mal durchgelesen bzw. das Video angesehen. Es ist immer ganz gut, verschiedene Beschreibungen und Vorgehensweisen vorgestellt zu bekommen.

Ich habe gestern auch nochmal in meine Stash-Einstellungen gesehen, insbesondere in die Workflow-Abschnitte, weil in dem Blogbeitrag steht, dass die upward-merges weitestgehend automatisch ablaufen. Das klingt echt vielversprechend und will getestet werden :wink:

Ich werde das WE versuchen, auf Spring zu gehen - was im Prinzip auf “alles löschen und später stückweise übernehmen” hinausläuft.

Das habe ich mir gitmäßig so vorgestellt:

  • neuen Branch “last_ninja” vom master machen, um den Ninja-Stand zu sichern
  • alle Datein in master löschen
  • Spring-Boot-Projekt mit http://start.spring.io/ erzeugen lassen
  • alles wieder in master einchecken

Ist das so okay, oder gibt es einen besseren Weg?

Hört sich für mich nicht verkehrt an.
An Projektabhängigkeiten hattest du welche vorgesehen? Security, Web, Freemarker, JPA, PostgreSQL und Mail? AOP?

Ob es einen besseren Weg gibt, weiß ich nicht :wink:

Möchtest du noch irgendwo den Umgang mit Branches festlegen, bevor es “richtig” losgeht?

[QUOTE=cmrudolph]Hört sich für mich nicht verkehrt an.
An Projektabhängigkeiten hattest du welche vorgesehen? Security, Web, Freemarker, JPA, PostgreSQL und Mail? AOP?[/quote]

So ungefähr hatte ich mir das gedacht. AOP lasse ich erst mal weg.

Ob es einen besseren Weg gibt, weiß ich nicht :wink:

Möchtest du noch irgendwo den Umgang mit Branches festlegen, bevor es “richtig” losgeht?

Ich werde auf dem Master entwickeln, und noch einen Release-Branch anlegen. Feature-Branches nur vom/zum Master, Hotfixes sollte noch kein Thema sein.

Besser vll. nicht aber anders, du könntest den alten master umbenennen und einen neuen als orphan branch anlegen. Der sollte dann komplett separat sein, so hast du einen neuen master und behältst den alten aber im Repo. So zumindest in der Theorie, praktisch habe ich das auch noch nie probiert, da kein Bedürfnis bisher.