Git: Feature-Branches als fertig kennzeichnen

[Meillo]

Hoi,

ich wuerde gerne ein bisschen brainstormen zu Arbeitsweisen in Git.

Hier habe ich ein Projekt, das mit Git und einer lokalen Gitlab-Installation arbeitet. Es ist wichtig, dass die Programmierung von Features vom Release-Management entkoppelt ist. Features sollen folglich in Feature-Branches entwickelt werden. Zu einem spaeteren Zeitpunkt soll das Release-Management aus allen fertigen Features die passenden fuer das naechste Release auswaehlen. Diese Feature-Branches sollen dann in master gemergt und auf einander abgestimmt werden. Dann wird das Release gemacht. Anschliessend werden die nicht verwendeten Feature-Branches auf den neuen HEAD rebaset. So stelle ich mir das vor.

Meine Frage ist nun, wie ich bei den ganzen Feature-Branches den Ueberblick behalte, welche bereits fertig entwickelt sind (und somit fuer das naechste Release genutzt werden koennen) und welche noch in der Entwicklung sind (aber dennoch unter verschiedenen Entwicklern geshared werden sollten).


Eine derzeitige Idee ist das Umbennen der Branches von ``feature1'' zu ``feature1-done'', aber das scheint mir mehr Probleme und Unannehmlichkeiten zu erzeugen als tragbar ist.

Oder liegt die Loesung in einem Hauptrepo und separaten Entwicklerrepos und dann in Merge-Requests fuer alle fertigen Featuer-Branches?


Ueber Erfahrungen und Kommentare dazu wuerde ich mich freuen.

[Lord_Carlos]

Bei uns wird der Feature-Branch nach dem merge in Master geloescht. Aber bei uns wird es auch so schnell wie moeglich in Master gemerged. Hoert sich ein wenig so an als wenn die bei euch lange leben sollen, und zum schluss entscheidet Management ob es rein soll oder nicht?

Wir haben Version 2019.1 Beim Kunden, alle neue Entwicklung ist auf Master, beziehungsweise Featurebranches die so oft wie moeglich von Master mergen. Und dann wieder in Master reingeschoben werden + geloescht. Haben auch nur Zwei releases pro Jahr. Das ist heutzutage ja nicht mehr stand der dinge. Kann gut sein das mit continuous delivery da weit aus bessere strategien gibt.

[Meillo]

Bei uns wird der Feature-Branch nach dem merge in Master geloescht. Aber bei uns wird es auch so schnell wie moeglich in Master gemerged. Hoert sich ein wenig so an als wenn die bei euch lange leben sollen, und zum schluss entscheidet Management ob es rein soll oder nicht?

Wir haben Version 2019.1 Beim Kunden, alle neue Entwicklung ist auf Master, beziehungsweise Featurebranches die so oft wie moeglich von Master mergen. Und dann wieder in Master reingeschoben werden + geloescht. Haben auch nur Zwei releases pro Jahr. Das ist heutzutage ja nicht mehr stand der dinge. Kann gut sein das mit continuous delivery da weit aus bessere strategien gibt.

Ich glaube, du hast meine Situation verstanden.

Wir haben auch nur etwa zwei Releases im Jahr. Der Punkt ist, dass bei uns die Entscheidung, was ins naechste Release kommt, nicht vor der Programmierung gefaellt wird, sondern es wird an vielen Ecken parallel rumentwickelt, teilweise kleine Bugfixes, die natuerlich ins naechste Release kommen, teilweise aber auch Features die alles moegliche zwischen zwei Stunden und einem Jahr Entwicklungszeit haben. Die Entscheidung welches Feature in welches Release kommt wird erst zu einem spaeteren Zeitpunkt vom Release-Management getroffen. Dann sollen diese Feature-Branches in master gemergt und auch geloescht werden, wie bei euch, bloss halt erst nicht gleich, sondern spaeter.

Bugfixes kann ich immer gleich in master mergen. Bei Features geht das nicht, weil zu dem Zeitpunkt noch nicht bekannt ist, ob das naechste Release ein reines Bugfix-Release oder ein Feature-Release sein wird.

Vielleicht schaue ich aber auch nur von der falschen Seite auf das Problem ...


Merge-Requests scheinen wohl doch in die passende Richtung zu gehen. In der Github-Welt ist es doch so, dass allerlei Leute deinen Code clonen konnen, neue Features entwicklen koennen und dann einen Merge-Request aufmachen. Du kannst dann aus dieser Menge von fertigen Features (und Bugfixes) diejenigen aussuchen, die du in das Mainline-Projekt aufnehmen willst. Das entspricht schon ganz gut meiner Situation (mit Mainline=Release und Hauptprojekt=Release-Management). Ich muss wohl Erfahrungen damit sammeln.

[Lord_Carlos]

Ah ja, Merge-Requests. Ich glaube das koennte ganz gut funktionieren. Das machen wir bei uns auch mit Pull request, kann gut sein das es funktionel das gleiche ist. Dann gibt es auch eine nette uebersicht mit was gemerged werden kann. Wir benutzt bitbucket + jira. Sollte aber bei allen gaenglichen Systemen zu finden sein.

Man koennte auch in eurem Bug/Issue tracker ein Tag erstellen "ready for merge". Dann kann Release-Management sich ein filter erstellen mit allen issues die noch offen sind und "ready for merge" tag haben.

Beides ist weit aus besser als den branch umbenennen.

[Meillo]

Ah ja, Merge-Requests. Ich glaube das koennte ganz gut funktionieren. Das machen wir bei uns auch mit Pull request, kann gut sein das es funktionel das gleiche ist. Dann gibt es auch eine nette uebersicht mit was gemerged werden kann. Wir benutzt bitbucket + jira. Sollte aber bei allen gaenglichen Systemen zu finden sein.

Danke fuer's Gegenpruefen meiner Gedanken.

Man koennte auch in eurem Bug/Issue tracker ein Tag erstellen "ready for merge". Dann kann Release-Management sich ein filter erstellen mit allen issues die noch offen sind und "ready for merge" tag haben.

Auch eine gute Idee ... auf die ich bisher noch nicht gekommen bin!

[Lord_Carlos]

Ich weis nicht wie es bei github ist, aber bei Jira kann man eine Status-kette erstellen durch die ein Issue muss.
z.B. "Ready for development" -> "in progress" -> "testing" -> "ready for merge" -> "Done"
Hat den vorteil das man nicht ausversehen vergisst ein Tag zu setzten und das Issue in einer Sofaecke vergessen wird.

"Feature" und "Bug" issue koennen auch verschiedenen "Ketten" (Kein plan wie das heist) haben. So das Bugs direkt von testing zu done springen koennen, features aber nicht.

Das wird mit einem Sprint / Scrum / Kanban board kombiniert. Jeder Status bekommt seine eigene Spalte. So hat man dann einen schnellen ueberblik was heute zu testen ist, und was noch nicht gemerged wurde.

Bei uns nennt man die dicken Feature "Epics". Die Epics werden in kleinere Stories unterteilt. Die sollten gerne unter einer Woche Entwicklungszeit sein. Und separat testbar sein.

Bin mir unsicher ob dir das weiterhilft. Aber vielleicht bringt dich das auf gute Ideen fuer euren Workflow. Viel glueck.

[novalix]

Tagging ist mir bei dem Problemaufriss auch als erstes in den Sinn gekommen. So werden in git ja letzten Endes auch Releases benannt.
Man könnte natürlich auch die Feature Branches noch mal branchen in "devel" und "stable", und dann noch jemanden mit starken Nerven anheuern, der den Überblick behält.