GIT Best Practice

[DefconDev]

Tipp: Ihr solltet nur einen master-Branch haben, mehrere Release-Branches oder der dev-Branch sind ein Anti-Pattern.

Hier steht auch unter dem Punkt "Using a complicated Git workflow like git-flow" mehr: https://www.codewithjason.com/git-workflow-anti-patterns/ mehr.

Ich kann ehrlich gesagt nicht ganz folgen. Git flow ist eigentlich ziemlich simpel. Man hat einen dev Branche auf dem aktiv gearbeitet wird. Auf Basis dieses Branch wird dann ein Feature-Branch erstellt. Wenn der Feature Branch fertig ist, wird der im optimal Fall vor dem Merge in den Dev, ordentlich getestet. Damit auch sichergestellt ist, dass der Dev immer aktuell und auch funktionsfähig ist. Wenn Beispielsweise der Sprint sich dem Ende neigt, dann wird das Release erstellt, das geht dann auf Stage und sofern alles OK ist, auf Live. Wenn es zwischenzeitlich keine Hotfixes gab, welche auch eigene Branches sein dürfen, dann wird das Release gefinished und in dev und master/Main automatisch gemerged.

Ob das Ding jetzt Master heißen darf oder Main, ist eine Frage die die Ethik-Polizei in den USA beantworten müssen.

Ob es ein Merge oder ein Rebase sein kann, gilt es im Team zu klären. Ein Sqaush-commit ist auch empfehlenswert.

Aber was daran ein Antipattern sein soll?

Schlimmer fände ich es, wenn alle auf dem Dev Branch arbeiten würden und es wahrscheinlich nicht selten vorkommen könnte, dass dieser nicht funktionsfähig ist, weil das Ding auf Maschine A läuft aber auf Maschine B nicht mehr, weil Entwickler A irgendwas direkt in den Dev gemerged hat.

 

[DefconDev]

Edit: ein Feature Branch hat auch den Vorteil, du kannst direkt commiten und pushen ohne den Dev Branch zu beeinflussen. Also du hast ein Backup auf dem Git-Server, wenn dein Rechner abraucht.

Am nächsten morgen wird dich keiner anschreiben, dass deine Änderungen am Vortag das ganze Projekt "zerstört" haben.

 

[salat-0]

das Release gefinished und in dev und master/Main automatisch gemerged

dann hast du zwei Spitzen, das ist zu vermeiden

Ein Sqaush-commit

damit machst du das git blame kaputt, auch zu vermeiden

aber was wissen Google und co. schon? 🤷‍♂️

 

[DefconDev]

dann hast du zwei Spitzen, das ist zu vermeiden


damit machst du das git blame kaputt, auch zu vermeiden

aber was wissen Google und co. schon? 🤷‍♂️

Deine Argumente sind leider inhaltslos. Was ist gegen zwei Spitzen so schlimm? Die hast du im übrigen nur zum Zeitpunkt des Finish. In der Regel wird dann auf dem Dev direkt wieder weiterentwickelt und der Master dient lediglich als Backup wenn wirklich was schlimmes schief geht auf dem Dev.

Google interessiert mich tatsächlich gar nicht. Ich kenne überhaupt nicht deren Entwickler Teams und die Hintergründe warum sie kein Squash benutzen. Und ich glaube kaum, dass du jedes Google Team kennst und mit Sicherheit sagen kannst, was die intern machen.

Hinzu kommt in Azure Devops ist das eine valide Option, so seinen Branch zu mergen. Aber was weiß schon MS von Git.

Und wenn ich sehe, was Google alles an die Wand gefahren hat, bis hin zum Thema Android Entwicklung, die einen permanent nötigen, seine App auf den aktuellsten Stand zu halten, weil gefühlt alles von denen nach einem Jahr depcrecated ist, dann kochen die bei Google auch nur mit heißem Wasser.

 

[KonradN]

Irgendwie wird es anstrengend, wenn man immer auf Tobias reagieren muss.

Natürlich kann man sich auch überlegen, commits zusammen zu fassen (squash). Und da wird nichts „zerstört“ aber natürlich gehen dann ggf. Informationen verloren. Aber die Frage ist immer: was sind die Anforderungen? Und wie wollt ihr die umsetzen?

Und nein, nur weil Google für seine Anforderungen etwas macht, ist es nicht für die Anforderungen von Anderen passend.

 

[mrBrown]

Ich kann ehrlich gesagt nicht ganz folgen. Git flow ist eigentlich ziemlich simpel. [...]

Aber was daran ein Antipattern sein soll?

Ist halt oftmals schon ein bisschen Cargo-Cult und gefühlt 99% aller Teams könnten auf die Hälfte verzichten und würden nichts verlieren außer Unübersichtlichkeit. (Sieht der "Erfinder" von Git flow auch gar nicht so anders...)

Viele wären mit Trunk-based- oder Github-flow-Workflows deutlich besser bedient.

Deine Argumente sind leider inhaltslos. Was ist gegen zwei Spitzen so schlimm? Die hast du im übrigen nur zum Zeitpunkt des Finish. In der Regel wird dann auf dem Dev direkt wieder weiterentwickelt und der Master dient lediglich als Backup wenn wirklich was schlimmes schief geht auf dem Dev.

Inhaltslos ist das aber dann auch Wenn das ganze Argument für zwei Spitzen ist, dass eine von beiden ja sowieso überflüssig ist, ist das irgendwie ein ziemlich schlechtes Argument...

 

[mrBrown]

Um noch mal auf die Ausgangsfrage einzugehen, das meiste wurde vermutlich schon gesagt, aber ich fass noch mal zusammen was sich zumindest in den Projekten, die ich gesehen hab, als Best Practice herausgestellt hat, ist angelehnt an Trunk-Based bzw github-flow:

• Es gibt erstmal einen Haupt-Branch, das ist immer der aktuellste Stand und sollte immer deploybar sein
• Pro Feature/Bug/Whatever wird ein Branch abgezweigt, auf dem wird das jeweilige umgesetzt
  • Als Branch-Namen hab ich bisher was in die Richtung aus <typ>/<Ticket-ID>-<Beschreibung> erlebt
    • Typ angelehnt an die Typen aus Conventional Commits
    • Ticket-ID die ID aus in diesem Fall Jira, je nach git-Server und Ticketsystem ist darüber dann auch direkt Verlinkung möglich
    • Beschreibung ist nur kurze Stichwörter damit man direkt am Namen erkennt worum es geht, erspart im Zweifelsfall das Nachgucken in Jira - kann man sich auch sparen, wenn es ohne übersichtlich genug ist
  • Branches werden regelmäßig auf den Haupt-Branch rebased
    • CI-Systeme und Bots können hier durchaus helfen, um regelmäßig eine "rebased" Version zu bauen, wenn es irgendwo Änderungen gibt und/oder direkt automatisch zu Rebasen wenn nötig/möglich
    • Wenn man ein Feature in mehrere kleinere Tasks teilt kann man den ganzen Workflow hier noch verzeigen: die Branches für Tasks zweigt man vom Feature-Brunch ab, die sind dann für den der Haupt-Branch und man folgt dabei "im kleinen" dem Workflow
    • Commits immer als Conventional Commits, mit zugehöriger Ticket-ID im Commit. Als Best Practice habe ich bisher als letzte Zeile im Commit erlebt: stört nicht beim Lesen des Rests, ist aber trotzdem durchsuchbar und wird automatisch erkannt
  • Wenns fertig ist wird gemerged
    • ob mit oder ohne expliziten Pull Request/Merge Request muss jedes Team selbst entscheiden, bei Pull-/Mob-Programming oder auch wenn man allein entwickelt kann man sicher drauf verzichten. Ich fand's bisher aber auch in den Fällen ganz gut, auch wenns dann nur zum Bestätigen des ganzen dient und Review unabhängig davon ist
    • Merges immer nur als Fast-Forward, sodass es auf dem Hauptbranch keine Verzweigungen gibt. Macht Suche im Log und bisect deutlich einfacher
• released wird über Tags, also Tag=Release
  • ob man die selbst per Hand setzt oder automatisiert oder wie auch immer ist eigentlich egal. Im Extremfall wird jeder Merge automatisch released, im anderem Extrem setzte man selbst alle paar Monate mal nen Tag
  • nur Tags landen in irgendwelchen QS/Prod-Systemen
  • Branches dafür gibts nicht "einfach so"
• Wenn man mehrere Versionen parallel unterstützen muss wird ein "Haupt-Branch" für die jeweilige Version erstellt, indem vom jeweiligen Tag abgezweigt wird
  • Die Entwicklung läuft dann wie für den normalen Haupt-Branch, nur eben auf den jeweiligen Branch bezogen. Im Branch-Namen wird dann einfach noch die Versionsnummer aufgenommen: <typ>/<version>/<Ticket-ID>-<Beschreibung>
  • "Hotfixes" Cherrypickt man in die Versionen, in denen man sie braucht. Führt dann zu mehreren Branches, jeweils einen pro Version, in der man den Fix braucht, ist aber mMn einfacher als einen Branch in mehrere andere zu mergen
  • sollte nur so lange leben wie nötig (kann man im Notfall auch immer über den jeweiligen Tag neu erstelllen
  • Als sinnvoll hab ich es erlebt, ein festes Namensschema für den Haupt-Branch und die "Versions-Haupt-Branches" zu nutzen, also zB main & main-1.2.x & main-1.x. Macht Automatisierung einfacher, zB Branch-Protection-Rules, die dann einfach für den Prefix gelten können

Als Beispiel grob:

1. main ist der einzige Branch und aktuelle Stand, der letzte Commit ist auch getaggt als v1.0.0
2. Für Feature X1 wird ein neuer Branch aufgemacht, abgezweigt von main: feature/X1-super-feature
3. Wird wenns fertig ist auf main gemerged und auch direkt released; main ist dann wieder einziger Branch, neuster Commit ist getaggt als v1.1.0
4. Für Feature X2 wird wieder ein neuer Branch aufgemacht, abgezweigt von main: feature/X2-noch-besseres-feature
5. Bug X3 in v1.0.0 fällt auf und soll dafür auch gefixt werden: Branch main-v1.0.x wird vom Tag v1.0.0 erstellt, davon abgezweigt wird fix/v1.0.0/X3 und dort wird's gefixt direkt zurückgemerged und released, gibt dann Tag v1.0.1 aber keinen Branch main-v1.0.x oder fix/v1.0.0/X3 mehr! Parallel wird von main auch ein entsprechender Branch fix/X3 abgezweigt, der Commit cherrypicked und auch direkt gemerged und relesed
6. der noch aktuelle Feature-Branch feature/X2-noch-besseres-feature wird dann so früh wie möglich rebased auf main und wenns fertig ist gemerged - wenns nicht released werden soll wird's nicht getaggt, ist in main aber trotzdem enthalten und sollte daher auch deploybar sein

Führt in Summe zu sehr wenigen und meist sehr kurzlebigen Branches, so zeimlich jeder Branch und Commit ist auf den ersten Blick zuzuordnen, die History ist gradlinig, zu beachtende Formalitäten gibts nicht viele.

 

[LimDul]

Ich würde da @mrBrown da zustimmen.

Grundsätzlich ist git extrem mächtig. Es gibt um von A nach B zu kommen in der Regel mehr als einen, meist sogar 3 oder 4 Möglichkeiten. Keine dieser Möglichkeiten ist dabei "Die gesetzte Möglichkeit und alle anderen sind scheiße". Sie haben alle Vor- und Nachteile. Am Ende müssen die "Business/Entwickler"-Anforderungen den Workflow definieren und nicht der Workflow die Anforderungen Deswegen halte ich sämtliche pauschale Aussagen wie "Es darf nur eine Spitze geben" für Bullshit von Leuten ohne Ahnung. Weil das genau die falsche Sichtweise ist.

Man kann sich die verschiedene Workflows und Möglichkeiten ansehen und muss dann für seine Anforderungen entscheiden, welcher Workflow (oder auch nur Teile davon) helfen mir meine Arbeit sauberer und effizienter zu machen.

Klar ist - jeder Branch bringt Overhead und je länger er lebt um so höher ist die Wahrscheinlichkeit für Merge-Konflikte. Aber am Ende sind es paar Fragen, die man beantworten muss:

• Wie viele Versionen muss ich unterstützen im Support?
• Wie viele Versionen werden parallel entwickelt?
• Wie groß sind meine typischen Features?
• Wie viele Entwickler arbeiten parallel wo ran?
• Wie ist mein Test-Prozess?
• Wie ist mein Release-Prozess?

Eine Umstellung auf GIT bietet immer die Möglichkeit da Dinge zu hinterfragen ob man sie besser machen kann. Aber wenn man z.B. aufgrund von Komplexität und Firmen-Anforderungen lange Test-Phasen vor Major-Releases hat braucht man vermutlich einen Release/Stabilisierungs-Branch. Ist die Test-Phase kurz und läuft gegen den main, braucht man es nicht. Etc.

GIT ist ein Schweizer Taschenmesser - ich kann mich damit selber verletzen und behindern oder effizienter werden.

 

[DefconDev]

Inhaltslos ist das aber dann auch Wenn das ganze Argument für zwei Spitzen ist, dass eine von beiden ja sowieso überflüssig ist, ist das irgendwie ein ziemlich schlechtes Argument...

Wieso inhaltslos? Ich benenne doch den Backup Branch, ob das jetzt sinnig ist oder nicht, muss jedes Team für sich entscheiden.

Und um den Master muss man sich nahezu nie kümmern. Also ein Mehraufwand ist das nicht. Evtl. Nimmt der zusätzliche Branch etwas die Übersicht ist aber auch wieder subjektiv.

Ich will hier auch kein Git-Flow-Plädoyer halten sondern darauf aufmerksam machen, am Ende ist es nur ein Tool was dir das Leben vereinfachen sollte. Viel mehr möchte ich über Git nicht nachdenken. Es muss funktionieren.

 

[DaBe1812]

Also erstmal für mich nehme ich da raus, dass ich es sehr einfach habe, weil ich nur eine Version unterstützen muss, die gerade im Einsatz ist. Aber jetzt strauchel ich ein wenig mit commit, push, merge und pull.
Also ich habe ganz am Anfang den einzig wahren MAIN ausgechecket vom GitHub Server. Da wir nicht auf Main arbeiten dürfen, habe ich einen Branch davon gemacht für ein neues Feature. Das habe ich fertig gemacht und dann habei ich es committed und gepusht. Damit war es dann im GitHub auf dem Server auch findbar. Dann habe ich einen Pull-Request erstellt, der Code wurde von jemandem abgenommen und dann wurde der Branch auf den Main gemerged.
Hier schon die erste Frage: kann ich diesen Branch irgendwie schließen, damit man nichts mehr darin machen kann, oder ist der durch den Pull-Request automatisch geschlossen? Was ist, wenn ich und der Reviewer schlampig waren und an dem Feature nochmal etwas gemacht werden muss? Dann wieder in dem Branch weiter arbeiten oder neuer Branch?

Als nächstes habe ich aus dem, was ich hier im Thread verstanden habe einen Branch erstellt mit "Features, die alle in die selbe Richtung gehen", an dem arbeite ich jetzt schon seit letzter Woche. Mittlerweile sind da ca. 5 JIRAs drin abgearbeitet. Hier habe ich lokal entwicklet, bis ich das Feature gut fand, dann habe ich ein Commit mit dem JIRA als Text gemacht und direkt gepusht (Datensicherung). So habe ich entweder mehrmals am Tag, oder alle zwei Tage ein Commit und einen Push gehabt. Nur als ich die Branches wechseln musste, weil ich ein Feature erstellt habe, das nicht in den Branch gepasst hat, habe ich einen neuen Branch vom Main erstellt und das andere Feature fertig gemacht und Committed, gepusht und einen Pull-Request auf Main gemacht. Danach kam ja der Punkt, wo ich meinen anderen Branch an den Main angleichen musste, weil ich an einer Klasse etwas machen musste, die sich seit dem auschecken verändert hatte.

Nächste Fragen: Laut dem, was ich hier mittlerweile gelesen habe, hätte ich am besten für jeden JIRA einen Branch erstellt, weil ein Jira = ein Feature und direkt gepusht und einen Pull-Request gemacht?

 

[KonradN]

Das Problem ist jetzt, dass Du eine casual Sprache hast und wir nicht wissen, wie Ihr arbeitet.

jeden JIRA einen Branch erstellt,

Habt Ihr so viele JIRA Instanzen? Aber nur ein Branch für eine ganze JIRA Instanz? Ich weiss ja nicht

Vermutlich meinst Du genau das Richtige. Für jedes Feature ein Feature Branch. Aber wie Features abgebildet werden in JIRA ist eure Definition. Was habt Ihr alles in JIRA? Wir haben da Epics, Stories, Tasks, Bugs, ...
Aber was Sinn macht, ist eure Entscheidung. Bei uns ist das (in der Regel - keine Regel ohne Ausnahme)
Bug -> Feature Release
Story -> Feature Release

Aber manchmal wird auch ein Feature Release für mehrere Stories genommen. Diese hängen dann aber auch zusammen, dass heisst: Ein Epic und damit wäre hier dann ein Feature Release für dieses Epic.


Es ist also kein reines Git Thema sondern auch ein Jira Thema.


Und ein Branch kann nicht geschlossen werden. Du kannst da also auch weiter arbeiten.
Was man teilweise hat ist: Alte Feature Branches werden komplett gelöscht um die Übersicht nicht zu verlieren. Das kann halt Sinn machen, wenn die einzelnen Entwicklungsschritte uninteressant sind und nur noch der generelle Change wichtig ist.

 

[mrBrown]

Wieso inhaltslos? Ich benenne doch den Backup Branch, ob das jetzt sinnig ist oder nicht, muss jedes Team für sich entscheiden.

In welchen Fällen könnte der denn als Backup sinnvoll sein?

Ich will hier auch kein Git-Flow-Plädoyer halten sondern darauf aufmerksam machen, am Ende ist es nur ein Tool was dir das Leben vereinfachen sollte. Viel mehr möchte ich über Git nicht nachdenken. Es muss funktionieren.

Ich kenne keinen Git-Workflow über den man mehr nachdenken muss als git-flow 😬

 

[mrBrown]

Und ein Branch kann nicht geschlossen werden. Du kannst da also auch weiter arbeiten.
Was man teilweise hat ist: Alte Feature Branches werden komplett gelöscht um die Übersicht nicht zu verlieren. Das kann halt Sinn machen, wenn die einzelnen Entwicklungsschritte uninteressant sind und nur noch der generelle Change wichtig ist.

Ist doch eher Standard, dass Feature-Branches gelöscht werden. Warum sollte man die zum Nachvollziehen der Entwicklungsschritte brauchen?

 

[KonradN]

Ist doch eher Standard, dass Feature-Branches gelöscht werden. Warum sollte man die zum Nachvollziehen der Entwicklungsschritte brauchen?

Ich habe keine solche Anforderungen, aber ich bin in keiner Position, dass ich ausschließen möchte, dass dies irgend wo aus irgend einem Grund benötigt wird.

Es war mehrfach die Aussage, dass dies Sinn machen kann. Und dass sich jedes Team überlegen soll, was sie wie machen. Ich werde den Teufel tun, und irgend wem irgend etwas vorzugeben noch werde ich meine Erfahrungen verallgemeinern als eine Regel. Alles sind reine Vorschläge / Ideen.

Auch die Diskussion sehe ich nicht als so zielführend an. Wieso muss das festgelegt werden? Nehmen wir dies als Beispiel: Warum muss das jetzt festgelegt werden? Wenn man die Feature Branches nicht löscht, dann ist das auch egal. Git stört es nicht. Das Team wird irgendwann merken: Ups, wir haben keine Übersicht mehr. Und dann kann man das Problem diskutieren und schon werden Feature Branches gelöscht (so das die Lösung ist).

Ich sehe es halt als wichtig an, dass regelmäßig über die Workflows / Arbeitsweise reflektiert wird. Und da ist dann relativ egal, wie ihr arbeitet. Da ist es egal, ob ihr für jedes Release ein Tag setzt oder einen Branch erstellt. Entweder macht ihr es schon gut oder ihr stellt fest: "Wir erstellen immer Branches aber in 99% der Fälle haben wir da nie etwas zu machen" oder "Wir erstellen immer Tags aber in 90% der Fälle haben wir dann doch noch einen Branch zu erstellen" oder was weiss ich. Darüber muss man aber doch nicht spekulieren. Oder zumindest ich muss es nicht.

Daher ist und bleibt meine Aussage: Startet einfach. Egal wie! Schaut, wie das Team klar kommt. Wo gibt es Probleme? Wo hakt es? Und dann überlegt nach Lösungen. Und das macht das Team! Da muss kein Manager von oben herab entscheiden! Kein Micromanagement! (Die Entwickler wissen, wo Dein Auto steht! )

 

[KonradN]

Warum sollte man die zum Nachvollziehen der Entwicklungsschritte brauchen?

Ha, ich habe einen UseCase:

Ich habe ja diese Java(FX)MavenApp Repositories. Da habe ich dann Feature Branches als ich z.B. dann Logging Abhängigkeiten versucht habe zu lösen.
Auf diese Feature Branches verweise ich in meinen Antworten hier im Forum, daher werde ich diesen "Feature Branch" nicht löschen.

Und der wird nicht gemerged, da diese Logging Abhängigkeit nicht in das eigentliche Projekt gehört. Zumal der damalige Lösungsansatz mit moditect Plugin längst nicht mehr verwendet wird.

 

[mrBrown]

Ha, ich habe einen UseCase:

Ich habe ja diese Java(FX)MavenApp Repositories. Da habe ich dann Feature Branches als ich z.B. dann Logging Abhängigkeiten versucht habe zu lösen.
Auf diese Feature Branches verweise ich in meinen Antworten hier im Forum, daher werde ich diesen "Feature Branch" nicht löschen.

Und der wird nicht gemerged, da diese Logging Abhängigkeit nicht in das eigentliche Projekt gehört. Zumal der damalige Lösungsansatz mit moditect Plugin längst nicht mehr verwendet wird.

'weiterhin relevante und nicht gemergte Branches' nicht löschen ist doch ein völlig anderer Usecase als Branches nach dem Merge löschen?

Ich habe keine solche Anforderungen, aber ich bin in keiner Position, dass ich ausschließen möchte, dass dies irgend wo aus irgend einem Grund benötigt wird.

Naja, ging ja um Best Practice, nicht um irgendwelche obskuren Randfälle 🙃

 

[KonradN]

'weiterhin relevante und nicht gemergte Branches' nicht löschen ist doch ein völlig anderer Usecase als Branches nach dem Merge löschen?

Stimmt, da hast Du natürlich 100% Recht.

 

[DaBe1812]

Das mit dem löschen von Feature Branches war eigentlich auch meine Idee.
Alle Feature Branches von z.B. 3.6 behalten.
Wenn die Version Released wird, Tag setzen, evtl neuen Dev Branche 3.7 ziehen und darauf die neuen Features aufsetzen.
Wenn 3.7 Released wird, können die Feature Branches von der 3.6 weg.
Die würde ich halt nur aufheben, falls ein Fix zur 3.6 gebaut werden muss, dann könnte man nochmal in die Commits gucken, warum damals der Fehler eingecheckt worden ist.

 

[DaBe1812]

Das Problem ist jetzt, dass Du eine casual Sprache hast und wir nicht wissen, wie Ihr arbeitet.

Jupp, ich hab damals den SCRUM-Lehrgang verweigert, weil dieses halbherzige "rum gescrumme" in manchen Firmen hat mich dermaßen angekotzt, dass ich es nicht eingesehen habe darin Gehirnkapazität zu investiren.

Also um mal zu Relationen her zu stellen:
Epics - haben wir in JIRA in der Form von Überpunkten, diese sind Versionslos und beinhalten Unterpunkte
Features - sind JIRA-Artikel, meistens Unterpunkte zu einem "Epic". Hier muss ich mich noh mehr selbst erziehen, wenn ich festelle, dass ein JIRA nicht in eine einzelne Version passt, dann muss daraus ein Epic werden und ich muss di Arbeit in mehrere Unterpunkte gliedern.
User Storys haben wir in JIRA eigentlich gar nicht, dazu müsste der User viel mehr in den Prozess integriert werden. Und wir sind mit unserem Projekt eigentlich schon immer sehr nahe am User.
Wobei teilweise nehme ich auch Anforderungen vom User auf und mache daraus einen JIRA-Artikel, also verwenden wir Feature und User Story in JIRA äquivalent.

 

[mrBrown]

Die würde ich halt nur aufheben, falls ein Fix zur 3.6 gebaut werden muss, dann könnte man nochmal in die Commits gucken, warum damals der Fehler eingecheckt worden ist.

Dafür brauchst du die alten Feature-Branches nicht, die würden nur exakt die selben Commits erhalten wie der Tag für die jeweilige Version.

Der einzige Mehrwert wäre der Branch-Name, aber falls der später mal relevant wird ist irgendwas sehr schief gelaufen.

Also um mal zu Relationen her zu stellen:
Epics - haben wir in JIRA in der Form von Überpunkten, diese sind Versionslos und beinhalten Unterpunkte
Features - sind JIRA-Artikel, meistens Unterpunkte zu einem "Epic". Hier muss ich mich noh mehr selbst erziehen, wenn ich festelle, dass ein JIRA nicht in eine einzelne Version passt, dann muss daraus ein Epic werden und ich muss di Arbeit in mehrere Unterpunkte gliedern.
User Storys haben wir in JIRA eigentlich gar nicht, dazu müsste der User viel mehr in den Prozess integriert werden. Und wir sind mit unserem Projekt eigentlich schon immer sehr nahe am User.
Wobei teilweise nehme ich auch Anforderungen vom User auf und mache daraus einen JIRA-Artikel, also verwenden wir Feature und User Story in JIRA äquivalent.

Das zeigt das Problem der "casual Sprache" eigentlich sehr gut:

Jira kennt weder Artikel noch Überpunkten noch Unterpunkte; aus dem Kontext wird dann zwar irgendwie klar, was du meinst, aber wenn man in deinem Text "Jira" durch "Wikipedia" ersetzen würde, würde das wahrscheinlich niemand merken.

 

[DaBe1812]

Dafür brauchst du die alten Feature-Branches nicht, die würden nur exakt die selben Commits erhalten wie der Tag für die jeweilige Version.

Also sammelt ein Tag die Commits die zu ihm gehören. Und wenn man einen Branch löscht, dann bleiben die Commits erhalten?

Jira kennt weder Artikel noch Überpunkten noch Unterpunkte;

Jupp, mea culpa, Artikel heißen in JIRA "Vorgänge" und Unterpunkte heißen Unteraufgaben und Überpunkte haben scheinbar garkeinen Namen, bzw. sind einfach normale Vorgänge mit Unteraufgaben, aber wo Unter ist, muss ja folglich auch Über sein.

 

[Gelöschtes Mitglied 91877]

Also sammelt ein Tag die Commits die zu ihm gehören.

Nein. Ein Tag ist lediglich ein mit einem (typischerweise menschenlesbaren) Namen versehener Zeiger auf einen spezifischen Commit/Punkt in der Git-History. Er stellt selbst keine Gruppierung/Sammlung von Commits dar. Es steht dir natürlich frei das für dich so zu interpretieren.

Und wenn man einen Branch löscht, dann bleiben die Commits erhalten?

Wenn dieser und damit die Commits vorher in einen anderen existierenden Branch gemergt (bzw. anderweitig überführt) wurden, ja.
Wenn nein, sind sie typischerweise weg (stark vereinfacht gesprochen).

Jupp, mea culpa, Artikel heißen in JIRA "Vorgänge" und Unterpunkte heißen Unteraufgaben und Überpunkte haben scheinbar garkeinen Namen, bzw. sind einfach normale Vorgänge mit Unteraufgaben, aber wo Unter ist, muss ja folglich auch Über sein.

Es ist wie immer hiflreich, sich bei vorhandenen Tools mit den grundlegenden Konzepten und Begrifflichkeiten vertraut zu machen, und hauptsächlich diese zu verwenden, statt für alles eigene Begrifflichkeiten zu erfinden bzw. bestehende Konzepte irgendwie umzuinterpretieren.
Das erleichtert die Arbeit mit und vorallem auch den Austausch über solche Tools (z.B. hier) ungemein.

 

[LimDul]

Also sammelt ein Tag die Commits die zu ihm gehören. Und wenn man einen Branch löscht, dann bleiben die Commits erhalten?

Commits bleiben grundsätzlich enthalten. Git ist eine Sammlung von Commits mit Vorgängern und Zeigern auf diese Commits. Das war es. Branch und Tag ist im Prinzip das gleiche, außer das bei einem Branch sich der Zeiger bewegt bei einem neuen Commit und bei einem Tag nicht.

 

[DaBe1812]

Ich hab da nachdem wir jetzt fröhlich mit der Sache arbeiten nochmal eine Frage zu Branches und Pushes und Merges:
Ich hab in der Version angefangen alles, was Persistence betrifft in ein eigenes Modul zu packen, wegen der Übersichtlichkeit.
Das sind natürlich ein riesiger Haufen an Klassen, die da angepasst werden müssen.
Zum einen verschiebe ich ja hunderte Klassen, und zum anderen ändern sich ja bei allen nutzen Klassen die Import-Pfade.
Deswegen wollte ich die Umstellung im Moment Stück für Stück machen, damit nicht zu viele Klassen auf einmal angefasst sind und später kein Merge gemacht werden muss und der Reviewer mich nicht total hasst.
Kann ich das alles in einem Branch machen?
Also ich habe einen Branch, bau da meine Klassen um, dann committe ich das ganze und pushe ins git und mache einen Merge, damit der Dev-Branch nicht zu weit von der aktuellen realität abweicht und alle anderen ihre Branches rebasen können.
Kann ich also nach dem Merge einfach den Branch irgendwann neu Rebasen und dann in dem Branch weiter arbeiten, weil geistig gehört ja alles zu dieser Änderung?