Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Moin zusammen,
wir haben jetzt in der Firma nach SVN endlich GitHub bekommen. Und mittlerweile ist mein Projekt auch migriert.
In SVN haben wir nicht ganz so schön gearbeitet (meine Meinung) und in GIT möchte ich das jetzt besser machen.
Meine Idee war für jeden JIRA einen Branch zu erstellen und wenn der umgesetzt ist, dann einen Pull-Request in den Main Branch mit Code Review und was dazu gehört.
Jetzt hatten wir in SVN immer direkt im Trunk gearbeitet und für jede neue Version einen Branch gezogen, sobald diese in Prod gegangen ist.
In GIT hätte ich auch gerne eine Möglichkeit zu sagen "Das war der Stand 4.2.1", aber wenn ich dafür auch wieder einen Branch ziehe, dann wird die Übersicht bald unübersichtlich.
Also meine Frage, wie macht man das im best practise?
Oder ist sogar mein kompletter Ansatz unzweckmäßig?
In GIT hätte ich auch gerne eine Möglichkeit zu sagen "Das war der Stand 4.2.1", aber wenn ich dafür auch wieder einen Branch ziehe, dann wird die Übersicht bald unübersichtlich.
Je nachdem was in dem Ticket steht kann das komplexer werden. Ticket 1234 haengt von 1123 ab welches Korrekturen aus 1021 braucht, das koennte ein Entwickler in einem Aufwasch/Zweig machen.
Grundsaetzlich wuerde ich nicht versuchen in Absoluten zu handeln, sondern mal sagen "fuer jedes JIRA-Ticket oder Themenbereich ein Branch" zum Beispiel.
Also wie Robert schon schrieb: Tags für Versionen. Da kannst Du dann später, wenn notwendig, immer noch einen Branch erstellen. Aber so lange der nicht benötigt wird, macht es keinen Sinn, den Branch zu erstellen.
Bezüglich Abhängigkeiten zwischen Stories: Das kann man natürlich auch mit den Branches abbilden. Jeder Branch basiert ja auf einem anderen Branch und das kann natürlich auch ein anderer Feature Branch sein. Aber das erfordert dann ggf. regelmäßige rebase Aufrufe und da ist dann tatsächlich die Frage, in wie weit das für euch Sinn macht oder ob ihr da nicht wie von Robert vorgeschlagen einen Branch für Themenbereiche macht, in denen dann mehrere Jira Tickets / Stories bearbeitet werden. (Ggf. hängen die ja auch in einem Epic zusammen, so dass man dann einfach das Epic nimmt in solchen Fällen?)
Aber die generelle Vorgehensweise entspricht schon durchaus den Best Practices. Ihr solltet da halt nur schauen, was für Grundlegende Branches ihr so braucht / wollt. Das hängt aber davon ab, wie ihr generell arbeitet. Reicht euch der eine Haupt-Branch (main oder master) oder braucht ihr mehrere für Produktion, QA und Development? Das hängt aber schlicht an eurer Arbeitsweise in der Firma. Wenn ihr eine Haupt-Version in Produktion habt, dann kann man diese separat halten. Wenn ihr eine QA Abteilung habt, dann kann es auch Sinn machen, da einen Branch für zu haben. Und dann würdet ihr den Development Branch mergen in den QA Branch, wenn eine Version an die QA Abteilung geht. Nach der Abnahme wäre dann der Merge in den Produktion Branch ....
Das mit den Tags hatte ich mir gedacht, Parallel-Versionen gibt es zum Glück nicht. Sinn und Zweck soll ja nur sein, dass wenn die 4.1 z.B. ausgerollt ist und trotz testen und pilotieren in der Prod nach einer Woche ein Fehler auffällt, der direkt gefixt werden muss, der Trunk aber schon wieder viel weiter ist, dass man zu der Version zurück kann, um das Problem schnell zu beheben und auch schnell eine Fix-Version raus zu bringen. Ich denke mal der Tag ist dann so etwas, wie ein Snapshot, der einen Punkt in der Entwicklung markiert.
Der Vorschlag mit den Branches nach Themengebieten oder "Sinnhaft" zusammen zu legen, gefällt mir auch, da müssen wir uns nur am Riemen reißen, dass der Branch dann nachher nicht überladen ist und dann 5 Jiras nicht produktiv gehen können, weil Nr.6 den Branch blockiert.
Hauptsächlich will ich die Vorgehensweise, weil ein paar Entwickler kleinere Punkte umsetzen sollen und nicht regelmäßig/planbar dem Projekt zugeordnet sind, also kann es sein, dass sie zu Sprint-Beginn mal drei Tage da sind und fangen einen Punkt an und dann wieder 8 Wochen in anderen Projekten sind und wir wollen aber jetzt Produktiv gehen. Dann könnten die einfach in ihrem Branch arbeiten und zu jeder Version rebasen und dann eben, wenn sie fertig sind mergen.
Dazu auch von mir die Frage: welche Alternativen schlägst du denn vor? Was macht JIRA für unser Projekt/für die Firma so unbrauchbar, dass wir es absetzen sollten?
Was ich bis jetzt gesehen habe hat JIRA eine Tendenz "wegzueskalieren", insbesondere wenn es eine eigene "Management-Ebene" gibt welche nichts anderes tut als den ganzen Tag mit dem JIRA zu spielen. Da kommt es dann schonmal vor das Tickets einen verzweigten, teilweise zirkulaeren Lebenszyklus von 20+ Zustaenden haben koennen.
Das und es hat viele Features welche vielleicht gar nicht notwendig sind (aber dann verwendet werden sollen weil sie ja da sind, siehe oben). Es ist eine relativ komplexe Software welche meistens (Aussage stammt aus meinem Hintern) in der Komplexitaet nicht mal annaehernd notwendig ist. Fuer viele Projekte und Firmen wuerde das GitLab Ticket System ausreichen.
Dennoch ist es auch nur ein Werkzeug, und man kann es auch einfach richtig und fuer sich passend verwenden, und den verallgemeinerten Aussagen stimme ich auch nicht zu (man sollte ja schlieszlich auch kein Java verwenden wegen der langsamen Startzeit und hohen Speicherverbauch).
Der Vorschlag mit den Branches nach Themengebieten oder "Sinnhaft" zusammen zu legen, gefällt mir auch, da müssen wir uns nur am Riemen reißen, dass der Branch dann nachher nicht überladen ist und dann 5 Jiras nicht produktiv gehen können, weil Nr.6 den Branch blockiert.
Hauptsächlich will ich die Vorgehensweise, weil ein paar Entwickler kleinere Punkte umsetzen sollen und nicht regelmäßig/planbar dem Projekt zugeordnet sind, also kann es sein, dass sie zu Sprint-Beginn mal drei Tage da sind und fangen einen Punkt an und dann wieder 8 Wochen in anderen Projekten sind und wir wollen aber jetzt Produktiv gehen.
Ich glaube das hat aber weniger mit "ein Ticket ein Branch" zu tun sondern mehr damit dass ihr entsprechende Arbetispakete finden muesst welche in diese Zeit passen. Wie diese Pakete dann aussehen, ist egal.
Ich glaube das hat aber weniger mit "ein Ticket ein Branch" zu tun sondern mehr damit dass ihr entsprechende Arbetispakete finden muesst welche in diese Zeit passen. Wie diese Pakete dann aussehen, ist egal.
Jain, also wir hatten mal die simple Aufgabe ein Interface für Exportierbare Klassen zu erstellen, damit man einfach nach CSV oder XLSX exportieren kann. Das wurde mittlerweile mehrfach angefangen, weil immer "Keine Zeit" war um es fertig zu machen. Sowas wäre für mich eben ein Beispiel für einen Branch, der irgendwann mal fertig ist und dann wird er gepusht.
Was ich bis jetzt gesehen habe hat JIRA eine Tendenz "wegzueskalieren", insbesondere wenn es eine eigene "Management-Ebene" gibt welche nichts anderes tut als den ganzen Tag mit dem JIRA zu spielen.
Oh ja, das haben wir hier auch, glücklicherweise und zugleich blöder Weise sind die "Pfade" die ein Ticket nimmt bei uns Projektsache, d.h. ich bestimme welche Schritte ich in den Tickets zu meinem Projekt haben möchte. Leider bedeutet das, dass ich am Anfang sehr oft diesen Pfad anpassen lassen musste, weil dann so Dinge vergessen wurden wie "Was passiert, wenn der Test nicht erfolgreich ist".
Ich fand für 4 Jahren den Schritt ins JIRA nach Excel schon gewaltig, weil man endlich seine Tickets kommentieren konnte und Zeiten eintragen und Leute konnten Tickets zu meiner Anwendung eingeben und man konnte über JIRA mit denen Kommunizieren und die haben sofort gesehen, wann das Ticket umgesetzt werden soll.
Außerdem habe ich eine Confluence Seite zum Projekt, wo ich die einzelnen Seiten beschreibe und da drin ist das Changelog und das hängt einfach direkt am JIRA, damit muss ich nichts mehr selber schreiben. Und Arbeit, die ich nicht machen muss ist meine liebste Arbeit
Wichtig sind sonst Namenskonventionen. Bei uns ist die Nummerierung der Version Jahr.Monat.Hotfix, also zb. 24.7.0
Dann gibt es, wenn die Version 24.7.0 releaset wird einen Branch hotfix/24.7 und ein Tag 24.7.0
In diesem Branch landen dann Hotfixe und werden - jeweils mit neuem Tag - veröffentlicht (Dafür gibt es aber keine eigenen Branches). Wir releases alle 6 Monate neue "Major" Versionen, so dass 2 Hotfix Branche pro Jahr existieren.
Bei den Branches für Features ist wichtig, dass die nach dem Merge gelöscht wird - sonst wird es extrem unübersichtlich. Aber auch da sind Namenkonventionen wichtig. Wir hatten in einem Projekt die Konvention feature/TICKET. Dadurch bleibt eine Übersichtlichkeit bestehen. Bei uns in der Firma verwenden wir gerrit, dadurch entstehen selten Branches.
Ich bin erst einmal irritiert, dass dies eine Rolle spielen soll bezüglich der Verwaltung von Sourcen in Git. Denn da hat es keinen Einfluss.
Und bei den Argumentationen dagegen: Ja, JIRA bietet sehr viel. Wie immer muss man es sinnvoll einsetzen. Dazu gehört eine klare Überlegung, was Sinn macht und was nicht. Und gerade in agilen Bereichen ist es sinnvoll. Und so Probleme sollten eigentlich nicht stattfinden - das ist kein Tool Problem sondern ein Problem, wie Prozesse gelebt werden. In den agilen Prozessen ist immer ein Feedback vorgesehen, das auch gelebt werden muss. Da wird geschaut, ob die Prozesse stimmen oder nicht und da würde sowas angesprochen, wenn da plötzlich 20 Schritte durchlaufen werden müssen oder so ... Und or allem klingt das so, als ob da jemand an einem produktiven Tool einfach so herum spielt?
Und wir haben das Umfeld noch nicht betrachtet: Wie sieht den das Umfeld aus?
Klar, ich brauche für mein eigenes Projekt kein Jira. Da tut es jedes Tool anmgefangen von einem Notepad. Da kann ich auch mit GitHub Issues arbeiten.
Sobald mehrere Leute betroffen sind, wird es direkt komplexer - da mag GitHub Issues noch ausreichen.
Aber wenn da jetzt jemand involviert ist, der auf das Geld und die Zeit achtet (Was in Firmen üblich ist), dann braucht man saubere Lösungen. Klar, man kann den Entwickler fragen: Wann bist du fertig? Der sagt dann x Wochen. Wenn man den Entwickler kennt, dann hat man seinen Faktor und weiss: in 3*x Wochen wird es vermutlich fertig sein. Und dann hat man von Zeit zu Zeit die Frage an den Entwickler; Wie weit bist du?
Kommt einem das bekannt vor? Hat der Manager da jemals eine sinnvolle Antwort bekommen?
Und da kommen die agilen Prozesse ins Spiel. Und damit direkt Tools wie halt Jira. Da wird dann ein BackLog verwaltet, es werden Stories, die in einem Sprint vorgesehen verwaltet. Es gibt für die Manager gute Übersichten wie ein Sprint Burndown Chart, so dass er die Frage an den Entwickler nicht mehr stellen muss ... Auch die falsche Einschätzung der Entwickler nimmt ab, denn von Sprint zu Spring bekommt man ein besseres Gefühl, wie viel man schaffen kann...
Aber hier sind wir noch in einem kleinen Bereich! Sobald man in SAFe und co anfängt, dann hat man deutlich mehr. Dann hat man einen Hub von 100+ Leuten, die in mehreren Teams aufgeilt entwickeln. Und von den Hubs evtl. gleich mehrere. Da werden so Tools gleich deutlich bedeutender und diese unterstützen massiv und spielen eine sehr wichtige Rolle für das Management. Und natürlich wollen da Manager sehen, wo die Millionen hin gehen und was für einen "Business Value" sie bekommen haben.
Also unter dem Strich ist es nur ein Tool von vielen. Ob es für einen passt oder nicht muss man an den eigenen Anforderungen schauen. Und dann muss man schauen, ob man am Einsatz etwas verändern sollte. Aber dazu dienen ja Sprint Retrospektive, Inspect & Adapt, ...
Und wenn dann so Tools missbraucht werden und das nicht abgestellt wird, dann ist es aus meiner Sicht kein Tool Problem sondern schlicht ein Problem des Prozesses bzw. der Leute, die sich eben auf den agilen Prozess nicht einlassen.
Aber egal, das ist alles nicht das Thema und das muss man nicht weiter vertiefen. In dem SAFe Umfeld, in dem ich tätig bin, nutzen wir auch JIRA und es hat natürlich Stärken und Schwächen aber eine Pauschale Aussage, dass man darauf verzichten soll, ist einfach nicht haltbar und zeugt von einer sehr eingeschränkten Sicht (die wir aber von Tobias kennen...)
Ich fand für 4 Jahren den Schritt ins JIRA nach Excel schon gewaltig, weil man endlich seine Tickets kommentieren konnte und Zeiten eintragen und Leute konnten Tickets zu meiner Anwendung eingeben und man konnte über JIRA mit denen Kommunizieren und die haben sofort gesehen, wann das Ticket umgesetzt werden soll.
Von Excel zu Jira ist durchaus heftig. Würde mich schon interessieren, wie ihr da so organisiert seid. Seid Ihr mehrere Teams, die alle über JIRA arbeiten? Und habt ihr eine agile Arbeitsweise bzw. setzt ihr die konsequent um? Ich fand es extrem gut, wenn man als Entwickler konzentriert an seinen Tätigkeiten arbeiten konnte. Also am Beispiel SCRUM:
Man plant einen Sprint und zieht diesen dann wirklich durch. Sprich: Du hast die geplanten Stories / Tasks und die arbeitet man wie geplant ab. Der Product Owner kann Backlog Einträge sammeln aber die interessieren das Entwicklerteam noch nicht. Wenn es zum nächsten Sprint kommt, dann wird halt wieder nach Priorität entschieden, was in den Sprint kommt und das wird dann als nächstes Bearbeitet.
Klar, es kann zu Bugs kommen oder so, aber das sind doch eher die Ausnahmen.
Im Worst case - falls wirklich alles auf "Zuruf" erfolgt, dann wäre zumindest ein Kanban Board oder so das Minimum, wo dann Morgens der Tag geplant wird. Tätigkeiten kommen dann rein und werden in der Regel am nächsten Tag dann eingeplant. Ständig Prio 1 Bugs / Tickets hat man ja (hoffentlich) nicht. Aber da wäre man dann ja auch außerhalb des aktuellen Fokus einer geregelten Entwicklungstätigkeit.
Es gibt zu JIRA eigentlich keine ernstzunehmende Alternative... aber diese Software ist eben hochkomplex und das könnte möglicherweise ein Crunch sein.
Also wir sind ein Unternehmen mit weit über 3000 Mitarbeitern und einem Haufen Externen. Wir stellen Server und Software für andere bereit und haben intern dann nochmal Abteilungen, die unser eigenes Leben, ich sag mal, beeinflussen.
Ich bin Softwareentwickler, aber unsere Abteilung macht eigentlich die "Buchführung" von Hardware.
Meiner Meinung nach sind wir mit dem Projekt, an dem ich arbeite noch in der Findungsphase, wie wir JIRA richtig benutzen sollten, aber irgendwie ist nie die Zeit, da mal richtig drüber zu sprechen, weil sowieso zu 90% die Punkte bei mir liegen.
Das SVN2GIT Projekt z.B. war da richtig gut aufgestellt, die haben dafür JIRA wirklich gelebt. Es gab einen Hauptpunkt für die Migration einer Abteilung. Darunter Unterpunkte für jedes Projekt der Abteilung, welches in SVN ein Repository hat. Dann wurde für die Abteilung ein Ansprechpartner benannt und dieser wiederum musste die Namen für jedes Projekt liefern.
Ich musste dann in JIRA für mein Projekt einen Fragenkatalog beantworten (welche Branches sollen noch migriert werden, Dateitypen, welche ausgeschlossen werden sollen, etc.). Die Kommunikation lief komplett über JIRA, war ich fertig mit einer Aufgabe an mich, dann hab ich das oben über den Knopf so kommuniziert und der Prozess lag wieder bei wem anders. Nach der Test-Migration musste ich das Projekt in der Abnahmeumgebung prüfen und dann habe ich es entweder direkt in JIRA frei gegeben, oder wieder in die Migrationsplanung zurück gegeben.
Nach der produktiven Migration hatte ich sogar nochmal den Job diese zu prüfen und erst, als ich diese abgenommen hatte (in JIRA) wurde unser SVN Repository auf nur lesen geschaltet.
Das hat mir wirklich sehr gut gefallen.
Und wie schon beschrieben, ich habe in dem Projekt als Vergleich nur Excel, d.h. damals lief die komplette Kommunikation in Outlook und man hat sich zur Organisation für jeden Incident einen Ordner angelegt.
Diese Woche musste ich mal etwas aus einem alten JIRA raussuchen, das war ein wenig nervig, wenn der Punkt schon zwei Jahre zurück liegt und man nicht mehr wusste, wie der Titel genau wahr, aber ich habe es gefunden und alle Dateien, die damit verbunden waren hingen direkt am Artikel, das finde ich halt unglaublich toll.
Aber eigentlich ging es ja um Git. Hier nochmal eine Frage zu Absicherung, weil ich mein, dass ich weiß, dass es geht:
Kann man Branches auf Branches machen? Also in meinem Kopf ist so ein Konstrukt, dass ich einen Branch erstelle 3.6.0. Da dran hängen dann Branches, wie "Überarbeitung UI" und wenn der fertig ist, dann merge ich den in den Branch 3.6.0 zurück. und wenn dann die 3.6.0 released ist, dann merge ich diesen Branch in den Main und das ist dann die Version, die Produktiv eingesetzt ist. Das würde dann bedeuten, wenn es Fehler an der Version gibt, die direkt gefixt werden müssen, dann kann ich einfach einen Fix-Branch aus dem Main ziehen und den Fix machen und einsetzen, das ganze wieder nach main mergen und der 3.6.0 Branch und alle darunter müssten dann nur ein Update ziehen und hätten den Fix direkt verbaut.
Du musst dich bei GIT von dem Konzept lösen, dass du aus SVN bezüglich Branches kennst.
GIT ist eigentlich eine Art Baumstruktur von Commits.
Jeder Commit kennen seinen Vorgänger (ggf. auch zwei Vorgänger). Es gibt in dem Sinne keine Branches. Ein Branch in Git ist eigentlich nur ein benannter Zeiger auf einen Commit, der keinen Nachfolger hat. Also "quasi" das Blatt des Baums. Und davon kann es beliebig viele geben.
Kann man Branches auf Branches machen? Also in meinem Kopf ist so ein Konstrukt, dass ich einen Branch erstelle 3.6.0. Da dran hängen dann Branches, wie "Überarbeitung UI" und wenn der fertig ist, dann merge ich den in den Branch 3.6.0 zurück. und wenn dann die 3.6.0 released ist, dann merge ich diesen Branch in den Main und das ist dann die Version, die Produktiv eingesetzt ist. Das würde dann bedeuten, wenn es Fehler an der Version gibt, die direkt gefixt werden müssen, dann kann ich einfach einen Fix-Branch aus dem Main ziehen und den Fix machen und einsetzen, das ganze wieder nach main mergen und der 3.6.0 Branch und alle darunter müssten dann nur ein Update ziehen und hätten den Fix direkt verbaut.
Nein, du müsstes den Fix in beide Branches - main & 3.6.0 mergen. Dafür gibt es zwei Wege, die beide ok sind:
Fix auf alter Version, Übernahme in aktuelle Version
Man macht einen Branch von dem 3.6.0er Branch und fixed dort den Fehler. Den Branch mergt man dann in 3.6.0 und in main rein und hat den Fix dann in beiden Versionen
Fix auf aktueller Version, Übernahme in alte Version
Man macht einen Branch vom main, Fixed dort den Fehler und mergt den in den main. Dann übernimmt den Fix-Commit (bzw. alle, wenn es mehrere sind) per Cherry-Pick in den 3.6.0er Branch. Wichtig ist hier Cherry-pick und nicht merge, weil sonst würde man den gesamten main Stand in den 3.6.0er Branch schieben - das will man nicht.
Das wichtigste ist - GIT ist eingentlich nur eine Sammlung von Commits mit Vorgängern/Nachfolgern als Baumstruktur und Zeiger mit Namen, die auf einzelne Commits zeigen.
Hier einfach einmal ein kleines Verständnis von Git und die Unterschiede zu Svn (Ich hoffe ich irre mich bei svn jetzt nicht, das ist doch wie cvs gewesen, oder?)
Git hat immer alle Dateien im Blick. Du checkst also einen Gesamtstand ein. Du hast z.B. die Dateien a, b, und c und dann ist in dem Stand auch a, b und c drin. Es werden keine Einzelnen Dateien berücksichtigt wie es z.B. CVS (und damit meines Wissens auch svn) gemacht hat.
In Git hast Du erst einmal für Dich drei Bereiche:
1) Dein Arbeitsbereich. Das sind alle Dateien, die Du lokal im Projekt hast. Diese können alle einen bestimmten Status haben wie: Ich bin eine neue Datei und noch nicht in den anderen Bereichen oder die Datei ist bereits in dem anderen Bereich und ist dann unverändert oder verändert.
2) Der zweite Bereich ist der Staging Bereich. Du kannst Änderungen in den staging Bereich bringen. Das ist oft ein git add Aufruf. Da hast Du dann sozusagen eine Kopie von den Dateien in einem Bestimmten Zustand.
3) Der dritte Bereich ist das Repository. Hier sind dann die ganzen Versionen gespeichert, die in das Repository "commited" wurden.
Das sind unter dem Strich immer komplette Sätze von allen Dateien, die eben eingecheckt wurden. So ein Satz hat ein Vorgänger. (Was dann natürlich auch dazu genutzt wird, dass nicht immer alles gespeichert werden muss und so. Git kann da den Speicherverbrauch auch optimieren)
Damit hast Du dann einfach nur einen Baum an Commits. Und es kann jederzeit ein neuer Commit hinzu gefügt werden, der irgend einen anderen Commit als Vorgänge hat.
Jeder Commit hat eine eindeutige id. Dies kannst Du alles sehr gut sehen, wenn Du z.B. das UI Tool gitk aufrufst (Das sollte bei einer git installation dabei sein). Dann siehst Du da sowas zwei wichtige Dinge bei einem Commit:
Also hier erst einmal wichtig: Du hast eine eindeutige Id (Die muss man nicht ganz angeben. Es reicht, dass man etwas angibt, das eindeutig ist. Da reichen teilweise schon 6 Stellen aus, aber oft werden wohl 8 Stellen genommen um auf de sicheren Seite zu sein. Manchmal will man bestimmte Dinge angeben um ein diff zu machen oder so...
Jetzt haben wir aber nur diese "Commits" mit Ihren ids. Damit kann man nicht arbeiten. Also gibt es noch sowas wie Zeiger, die man benennen kann. Man kann also ein Schild erzeugen und dieses an ein Commit hängen.
Schild an ein Commit hängen? Das klingt erst einmal direkt nach einem Tag. Du schreibst an einen Commit: "Das ist die ausgelieferte Version 1.0.0"
Damit kannst Du da gut drauf zugreifen.
Aber auch Branche sind eigentlich nichts anderes. Du hast ein Schild "main", das an einem Commit hängt. Und wenn Du nun eine neue Version von main eincheckst, dann kommt halt dieses neue Commit und im Anschluss wird das Schild "main" umgehängt auf den neuen Stand.
Da ist dann natürlich für den Ablauf wichtig: Du willst immer Stände haben wie A -> B -> C -> D Und das Schild main wandert dann von A nach B nach C nach D. (Aber das ist nicht wirklich erzwungen. Man kann also auch etwas mehr Schindluder treiben, aber das sollte man eher vermeiden ...)
Du kannst an jeden beliebigen Punkt ein Schild setzen. So es ein Branch ist, dann kann der beliebig starten. Du kannst Also einen Branch a haben, da machst Du einen Branch b von ... innerhalb des b Branch startest Du dann den Branch c.... Die kannst Du dann auch beliebig mergen. Du musst also da keine Reihenfolge oder so einhalten.
Und bei Branches auch wichtig: Du kannst die Basis eines Branches versetzen. Du kannst also ein rebase machen. Wenn Du also so wie oben die Branche a, b, und c hast und in b sind nun Entwicklungen, die Du auch in c brauchst, dann kannst Du ein rebase machen und sozusagen die Änderungen aus b mit in c übernehmen um dann auf der Basis zu arbeiten. Das Szenario ist also hier in etwas so:
Du hast den development Branch ... dann kommen die feature1 und feature2 Branches auf dem development Branch. feature1 ist fertig, wird in development gemerged und das ganze geht dann in Produktion. Nun kann feature2 ein rebase machen, damit es auf dem aktuellen development Branch aufsetzt. Das hat den Vorteil, dass der spätere Merge einfacher ist.
Also in meinem Kopf ist so ein Konstrukt, dass ich einen Branch erstelle 3.6.0. Da dran hängen dann Branches, wie "Überarbeitung UI" und wenn der fertig ist, dann merge ich den in den Branch 3.6.0 zurück. und wenn dann die 3.6.0 released ist, dann merge ich diesen Branch in den Main und das ist dann die Version, die Produktiv eingesetzt ist. Das würde dann bedeuten, wenn es Fehler an der Version gibt, die direkt gefixt werden müssen, dann kann ich einfach einen Fix-Branch aus dem Main ziehen und den Fix machen und einsetzen, das ganze wieder nach main mergen und der 3.6.0 Branch und alle darunter müssten dann nur ein Update ziehen und hätten den Fix direkt verbaut.
Es wäre kein "Update ziehen" - die Änderungen wandern da ja nicht direkt rein. Der Startpunkt eines Branches bleibt bei Commits immer fest. Nur weil es in main eine neue Version gab, bleiben alle Branches auf der Version, auf der sie gestartet wurden. Aber die Operation gibt es und es wäre ein rebase (So wie ich Dich verstanden habe)
Das war das Wort, dass mir gefehlt hat. Jetzt habe ich es verstanden und dann werde ich evtl. mal einen Termin mit den Entwicklern machen und wir reden darüber, wie wir das in Zukunft handhaben wollen.
Aber für mich wäre der Ansatz praktikabler, als wir ihn vorher in SVN gehalten haben, weil da haben wir alle direkt in den trunk (main) commited, ohne Code Review o.ä. Vorher musste man halt einen "Update to Head" machen, damit man auf der aktuellen Revision ist und sieht, ob jemand in denselben Klassen geändert hat, wie ich. Da war auch SVN schon so schlau, dass es eine geschlossene neue Funktion in einer Klasse einfach hinzugefügt hat.
Dann, nach dem Release wurde ein Branch vom aktuellen Trunk als Version gezogen und dann wurde fröhlich im Trunk weiterentwickelt.
Kam es jetzt in der Produktion zu einem Fehler und der Code musste gefixt werden, dann musste ich alle meine aktuellen Änderungen erstmal in den Trunk committen und mir dann den Branch ziehen. Dort den Fix machen und wenn der dann produktiv war, habe ich wieder in den Trunk gewechselt und da den Fix noch einmal gemacht, also die Gefahr des Vergessens war hier unglaublich hoch.
Jetzt würde ich das System anders herum benutzen. Main ist die aktuell produktive Version und bekommt einen Tag mit der Versionsnummer o.ä. Sollte es dann in Produktion zu einem Fehler kommen, dann mache ich den Fix auf Basis von Main, Merge dann auch direkt in Main, wenn der Fix eingesetzt ist und gebe den Tag mit der Fix-Nummer und dann kann ich den aktuellen Entwicklungsbranch mit der Versionsnummer rebasen und alle Branches, die davon gerade abhängen auch.
Die Einfachheit bei unserem Projekt ist, dass die Software nur auf einem Cluster, bei uns im Einsatz ist. D.h. mich interessieren nur zwei Versionen, die aktuelle im Einsatz und die nächste. Ich muss mir nicht zig Versionsstände merken, weil irgendwelche Kunden schon lange kein Update mehr bezahlen wollten, aber gerne Feature-Requests machen wollen.
Also wie viele Branches Du nutzt oder eben nicht, musst Du wissen. Generell kannst Du auch komplett über den main Branch gehen und alles darin machen. Dann wären die Releases einfache Tags.
Sollte da dann mal ein Fix benötigt werden, dann kannst Du auf Basis des Tag Standes einen Branch machen, da den Fix einbauen um ein neues Release zu erstellen (Der Commit würde dann halt auch den Tag bekommen). Und am Ende merged Du dann in den main Branch zurück, so dass der Fix auch in der aktuellen Version ist.
Das ist einfach nur eine Frage der Arbeitsweise und was ihr genau wollt. Wenn ihr sehr selten Fixes erstellen müsst, dann kann das Sinn machen, denn dann hättet ihr fast nie Branches. Setzt aber auch voraus, dass ihr keine parallele Entwicklung habt, die sich gegenseitig beeinflusst. (Also Szenario: Zwei Entwickler arbeiten an etwas, Zwischenstände werden eingecheckt und schon gibt es Probleme weil Änderungen von Entwickler 1 nicht mit den Änderungen von Entwickler 2 zusammen arbeiten.)
Meine persönliche Sicht / Erfahrung ist hier:
Ja, man kann durchaus gemeinsam in einem Branch arbeiten, so die Anzahl der Entwickler gering ist und diese gut vernetzt sind. Das kann funktionieren.
Generell sind Branche aber einfacher. Dann kann jeder frei machen, was er will und man hat die regelmäßigen commits. Die halte ich halt für wichtig, um halt auch einen Backup-Punkt zu haben. Wenn meine Festplatte plötzlich kaputt ist, dann verliere ich wenig, wenn ich oft eingecheckt habe. Da ist alles halt auch auf dem Server
Wenn die Zusammenarbeit in einem Branch gut funktioniert, dann liegt das in der Regel daran, dass die Änderungen halt doch relativ gut getrennt von einander sind. Wenn das der Fall ist, dann ist aber auch im anderen Szenario der merge oder rebase Aufruf trivial und es entsteht kein wirklicher Mehraufwand.
==> Ich sehe eigentlichen keinen Grund, auf die Branches für die Entwicklung zu verzichten.
Um etwas in die Details zu gehen: Die gemeinsame Arbeit in einem Branch war damals nicht auf Basis von git sondern des TFS (Team Foundation Services). Der große Unterschied hier ist: Bei der Sourceverwaltung von TFS sind Dateien schreibgeschützt. Um eine Datei zu ändern musste man diese erst auschecken. Damit war dann sicher gestellt, dass nie zwei Personen eine Datei parallel verändert haben, so dass wir nie komplexe Merge Szenarios hatten. Da dies im Workflow von git nicht vorgesehen ist, hast Du aus meiner Sicht ganz klar einen Merge Aufwand. Und das bei potenziell jedem anstehenden Commit!
Prinzipiell scheint es egal zu sein, wann der Merge Aufwand entsteht: Beim (bzw. vor dem) Commit oder bei einem Zusammenführen von Branches. In der Praxis ist das aber sehr wohl relevant, denn es erfordert ein gewisses KnowHow und es ist möglich, Fehler zu machen. (Wenn man liest: "Git hat Änderungen einfach so verworfen" oder so, dann ist das eigentlich immer ein: Anwender hat was falsch gemacht.) Meine SIchtweise ist nun einmal so, dass Entwickler nicht Experte in jedem Bereich sein müssen. Viele Dinge nutzt man einfach. So auch hier: Ein Entwickler muss nicht zwingend gut mit Git umgehen können. Es reichen Basics, die ein Grundschulkind lernen kann - das kann reduziert sein auf:
Auf den für ihn angelegten Branch wechseln
Dort regelmäßig seine Änderungen einchecken
Alles Andere kann von Anderen übernommen werden. (Ja, das ist ein absolutes Minimum. Da kann vieles mehr beigebracht werden wie Pull Requests erstellen oder seinen Branch selbst erstellen ... Aber eben kein komplexes Mergen ist notwendig.
(Also gerade aus Sicht eines Teams mit Senior- und Junior Entwickler: Da will ich gewisse Dinge den Junior auch nicht unbeaufsichtigt machen lassen, weil es mir hinterher deutlichen Mehraufwand bereitet.)
Und natürlich gibt es auch komplexere Probleme, wenn man alles in einem Branch macht. Dann hatte man eigene Änderungen erst einmal separat für sich weggeschoben (Also das, was bei git das git stash ist) um dann die Änderungen der Anderen zu übernehmen und die eigenen Änderungen dann nach und nach zu integrieren ...
Also generell gilt: Es ist viel möglich, ihr müsst finden, wie ihr am Besten klar kommt. Zur Not einfach ausprobieren und selbst Erfahrungen sammeln. Sowas kann auch durchaus eine Team Entscheidung sein: Wie will das Team arbeiten? Und egal, was ihr entscheidet: Es ist ja nicht fest: Ihr könnt es immer anpassen.
Aber eigentlich ging es ja um Git. Hier nochmal eine Frage zu Absicherung, weil ich mein, dass ich weiß, dass es geht:
Kann man Branches auf Branches machen? Also in meinem Kopf ist so ein Konstrukt, dass ich einen Branch erstelle 3.6.0. Da dran hängen dann Branches, wie "Überarbeitung UI" und wenn der fertig ist, dann merge ich den in den Branch 3.6.0 zurück. und wenn dann die 3.6.0 released ist, dann merge ich diesen Branch in den Main und das ist dann die Version, die Produktiv eingesetzt ist. Das würde dann bedeuten, wenn es Fehler an der Version gibt, die direkt gefixt werden müssen, dann kann ich einfach einen Fix-Branch aus dem Main ziehen und den Fix machen und einsetzen, das ganze wieder nach main mergen und der 3.6.0 Branch und alle darunter müssten dann nur ein Update ziehen und hätten den Fix direkt verbaut.
Hi,
hab mir jetzt nur das Bild angeguckt und das ist genau das. Muss ich mir bei Gelegenheit dann mal alles durchlesen und schauen, was in unserer Firma umsetzbar ist. Thx dafür.
Hi,
hab mir jetzt nur das Bild angeguckt und das ist genau das. Muss ich mir bei Gelegenheit dann mal alles durchlesen und schauen, was in unserer Firma umsetzbar ist. Thx dafür.
Hier auch evtl. der Ansatz: Probiert Dinge aus. Es sollte halt darum gehen, dass das Team möglichst gut zusammen arbeitet. Es ist ja nichts in Stein gemeißelt und man kann am Vorgehen immer etwas verändern.
Sehe ich auch so. Deswegen habe ich einen Termin mit dem Projektteam angesetzt, da kann jeder einmal seine Ideen präsentieren und am Ende nehmen wir meine ;.)
Ich muss doch einen gewissen Stand Qualitätssichern. Dafür braucht man in der Regel auch Zeit. Und wenn der Kunde einen anderen Stand hat, dann muss ich manchmal diesen Hotfixen.
Wir nutzen bei uns Git-Flow und Bitbucket macht die ganze Arbeit. Das ist so simpel da denkt man nicht drüber nach.
Denke an der Stelle kann man auch das Tobias Experiment wieder beenden.
Das hast du in der Pipeline in Form von Unit und Integrationstests.
Und bei Bedarf geht es dann im Rollout Bereich weiter. Du lieferst per Pipeline direkte Ergebnisse in eine Umgebung. Diese kann dann von da ja einen Workflow durchlaufen, so dass die Container dann in eine Abnahme Umgebung kommen oder so ehe es dann in Produktion geht. Das ist dann außerhalb der Entwicklung.
In der Cloud Welt (so nenne ich es mal) hast du die Kontrolle. Du überlässt es nicht mehr Kunden selbst. Und dann bekommen Kunden gezielt die neue Version. Kunden bekommen halt nur die Nutzung der Software, die man selbst kostet ….
Ja, das ist sehr eingeschränkt und es deckt nicht alle Anforderungen ab. Aber das Entwicklungsmodell selbst kann gut funktionieren. Ich erlebe es beruflich im SAFe Umfeld mit mehreren Hubs und es ist interessant. Gerade bei „unwichtigen“ Daten hast du dann eine tolle „Time to market“ (Bullshit Bingo!)
Die Anforderungen sind aber oft anders und da geht es nicht. Daher sind wir am Ende wieder bei dem, was wir schon hatten: man muss die Anforderungen anschauen und überlegen, wie man diese am besten umsetzen kann.
Nein, die Idee ist dabei aus meiner Sicht eine Andere:
Du hast eine Version, die du in einen Test geben willst. Diesen Stand musst du markieren. Das kann ein Tag sein. Du kannst also ein Tag haben, das den aktuellen QA Stand kennzeichnet.
Jetzt ist die Frage: gibt es an der QA Version Fixes? Wenn ja, dann brauchst du für diesen einen Branch. Wenn dies oft genug vorkommt, dann macht man den Branch direkt.
Und dann ist nur die Frage, wie man die Branche nennen will. Das ist aber aus technischer Sicht egal.
Generell ist der Hinweis selbst aber durchaus richtig aber ich verstehe ihn als: Prüft, ob ein Branch sein muss oder nicht. So viele Branche wie nötig, so wenig wie möglich. Dann löscht man Branche auch, wenn man sie nicht mehr braucht.
So pauschale Aussage sind Quatsch. Das hängt von vielen Faktoren ab - insbesondere was für eine Software man entwickelt, wie sie ausgeliefert wird und was supported wird.
Beispiele:
Bei uns intern haben wir einen main branch und hotfix Branches für alle Versionen, die noch im Support sind (und auch für die die nicht im support sind). Keinen develop, keinen Release Branch. Entwickelt wird mit gerrit, damit entstehen im Main Repository gar keine Branches. Selten werden Feature Branches angelegt, wenn ein Feature groß ist und nicht geteilt gemergt werden kann. Sie vermeiden wir aber nach Möglichkeit, weil sie Aufwand machen.
Bei einem Kundenprojekt hatten wir einen master Branch und zwei develop Branches. Teilweise gab es auch release Branches. Entwicklungen gingen per Pull-Request über Feature Branch, der nach dem merge wieder gelöscht wurde. Grund für die drei Hauptbranches:
Es gab genau eine produktive Version = der master
Es wurde an zwei Versionen parallel entwickelt (Eine die in drei Monaten live geht, eine die in einem Jahr live geht)
Testphasen vor einem Go Live waren 6+ Wochen lang - dementsprechend musste es release Branches geben, damit man weiterentwickeln konnte, aber gleichzeitig auch Fehler im Test fixen konnte.
Beides war sinnvoll. Wichtig ist nicht einen Branch nicht einzusetzen, weil er cool ist, sondern weil man ihn braucht. Jeder Branch produziert Overhead und man muss schauen wann muss wer den Branch wohin mergen - daher ist es sinnvoll die Zahl gering wie möglöich zu halten. Aber so pauschale Aussagen sind schwachsinnig.
JWT as authentication tokens are constructed for Google/Facebook scale environments, and absolutely no one who is not Google/Facebook needs to put up with the ensuing tradeoffs. If you process less than 10k requests per second, you’re not Google nor are you Facebook.
Ähnliches gilt hier. Google ist eine Software Firma, die extensive Infrastruktur hat und dementsprechend ganz andere Möglichkeiten bei QA, Test und Rollout hat. Wenn ich die habe, dann kann ich commit early, commit often, deploy often auch wirklich machen. Aber das geht nicht in allen in Firmen und Konstellationen. Und sobald das deploy often nicht möglich ist (und das ist es oft nicht), dann brauche ich bereits zwangsweise mehrere Branches. Deswegen immer mit Verstand ran
Bullshit. Gin hat keine Spitze, sondern ist eine beliebig gefächerte Baumstruktur mit verteilten Repositories. GIT kommt aus der Linux Kernel Entwicklung wo naturgemäß dezentral mit vielen parallelen Entwicklungen gearbeitet wird. (Aber was diskutiere ich mit einem Tobias....)
Wenn Du mit Spitze HEAD meinen solltest: Du hast auf deinem System ein HEAD, das ist richtig. Aber das ist halt sozusagen die Spitze des aktuellen Branches. Aber jeder Branch hat seine eigene Spitze und mit einem Wechsel in den Branch wird die Spitze des Branches zu dem neuen HEAD.
(Ganz einfach ausgedrückt.)
Man kann sich sein HEAD ansehen: Einfach mal die Datei .git/HEAD anschauen.
Man könnte jetzt noch auf Dinge eingehen, wie detached HEAD, aber das ist erst einmal egal.
Zu den Git Grundlagen wurde ja schon genug geschrieben bezüglich des Aufbaus. Von wegen Commits mit Vorgängern und dem daraus entstehenden Baumstrukturen und dass dann einzelne Commits Kennzeichnungen haben in Form von Tags oder Branch-Hinweisen.
Wäre git das falsche Werkzeug für die genannten Szenarien, dann hätte es sich bestimmt nicht so durchgesetzt, wie es sich durchgesetzt hat. Denn genau dieses Szenario ist doch eigentlich das übliche und die "neue Arbeitsweise" kommt nur nach und nach. Zumal die Frage immer ist: Kann man die eigenen Anforderungen überhaupt entsprechend abdecken? Es ist vieles möglich. Aber unter dem Strich läuft es dann oft darauf hinaus, dass man Dinge nur verlagert. Die Entwicklungsteams können da fleißig Ihre Features heraus pumpen ohne sich Gedanken zu machen. (Man hat halt Unit- und Integration Tests und das war es) aber an anderer Stelle setzt dann die QA dennoch an. Denn darauf wird ja nicht verzichtet werden.
Hier muss man ja nur einmal überlegen, was für kritische Software es gibt. Konzerne haben existenzielle Daten und existenzielle Systeme. Ausfälle bedeuten, dass die Konzerne schnell in den Nachrichten sind und das oft nach wenigen Tagen der Konzern schlicht insolvent ist. Da ist eine gewisse QA schlicht Pflicht. (Egal an welcher Stelle!)
Hier muss man ja nur einmal überlegen, was für kritische Software es gibt. Konzerne haben existenzielle Daten und existenzielle Systeme. Ausfälle bedeuten, dass die Konzerne schnell in den Nachrichten sind und das oft nach wenigen Tagen der Konzern schlicht insolvent ist. Da ist eine gewisse QA schlicht Pflicht. (Egal an welcher Stelle!)
Ich habe gerade Meetings gehabt, wo wir genau das diskutiert haben. Wie gehen wir mit Fehlern um, wie stellen sicher möglichst keinen Datenverlust, möglichst schnelle Recovery. Und da diskutieren wir Szenarien wie "Was ist wenn das AWS RZ ausfällt", "Was ist wenn wir einen kritischen Bug mit Datenverlust haben", "Was ist mit einem Cyberangriff (Ransomware)". Was sind die Strategien, wie erkennen wir das, wie reagieren wir, wie minimieren wir das Risiko etc...
Ich habe gerade Meetings gehabt, wo wir genau das diskutiert haben. Wie gehen wir mit Fehlern um, wie stellen sicher möglichst keinen Datenverlust, möglichst schnelle Recovery. Und da diskutieren wir Szenarien wie "Was ist wenn das AWS RZ ausfällt", "Was ist wenn wir einen kritischen Bug mit Datenverlust haben", "Was ist mit einem Cyberangriff (Ransomware)". Was sind die Strategien, wie erkennen wir das, wie reagieren wir, wie minimieren wir das Risiko etc...
Ja, das sind halt alles sehr wichtige Punkte. Ich denke, wenn man in Konzernen arbeitet, dann kennt man das. Und damit verbunden ja auch, dass Alles, was man plant (Desaster Recovery Pläne), ja auch regelmäßig durchexerziert. So nach dem Motto: Wir ziehen jetzt den Stecker in der Lokation A und schauen, ob die Failover alle funktionieren. Ob Notfallhandbücher Up-to-date sind und und und ... Als Entwickler stellt man da ja oft genug den 3rd Level Ansprechpartner / Rufbereitschaften ...
Also man kann Software immer so verwenden, wie der Hersteller sich das vorgestellt hat, aber manchmal gibt es auch einen "alternativen" Weg, der für manche funktioniert. Und manchmal setzt sich sogar der alternative Weg durch und wird vom Hersteller zum Standard erklärt.
Ich habe z.B. gerade bei Primefaces einen Request offen, weil ich zwei Features in einem Element parallel benutzen möchte und dies zu Fehlern führt und jetzt wird darüber diskutiert, ob es überhaupt gehen kann, dass beide Features zusammen funktionieren.
Also nicht immer ist der Hersteller der Gott seiner eigenen Software.
Und ich gehe da mit KonradN und LimDul d'accord, dass jeder Git in dem für sein Projekt/Team am besten geeigneten Rahmen verwenden sollte. Solange die Nutzung nicht zu Bugs führt, bei denen man ganze Branches verlieren könnte oder später ein Merge nicht mehr möglich ist, kann es ja nicht gegen die Software sein.
Dazu auch direkt nochmal eine Frage:
Wenn wir einen Versions-Branch hätten, daraus zieht man sich einen Feature-Branch, aber dann stellt man fest, dass es das Feature nicht in die Version packt, kann man den Branch dann "umhängen"? Also ein Branch hat ja quasi einen Vater und kann man den abändern?
Dazu auch direkt nochmal eine Frage:
Wenn wir einen Versions-Branch hätten, daraus zieht man sich einen Feature-Branch, aber dann stellt man fest, dass es das Feature nicht in die Version packt, kann man den Branch dann "umhängen"? Also ein Branch hat ja quasi einen Vater und kann man den abändern?
Ohne das vertiefen zu wollen: Wir haben einen User, der sich regelmäßig nicht benehmen kann und der daher regelmäßig gebannt wird. Seine Accounts werden nie älter als 1 Woche, weil früher oder später Ausfälle kommen.
Bezüglich dem rebase: Das nutzen wir sehr stark. Wenn wir etwas mergen, dann machen wir relativ zügig rebases bei den anderen Feature Branches. So ist sicher, dass ein Merge zurück immer trivial ist.
Das will ich aber nicht als Best Practice oder so verkaufen. Das ist einfach etwas, das wir als Team für sinnvoll erachtet haben. Aber das mögen Andere (evtl. zu Recht) als Unding ansehen. (Da ist halt der wichtige Punkt: Ihr müsst für euch eine Arbeitsweise finden, mit der Ihr euch wohl fühlt und mit der Ihr klar kommt.) Unser Punkt ist hier halt, dass wir lieber in einem Feature Branch was zerhauen als am master oder main.
Ich hab mir gerade mal den Artikel durchgelesen und muss sagen "Wow". Eigentlich habe ich von uns ITlern immer gedacht, dass wir die mit der Medienkompetenz sind. Soll jetzt kein direkter Angriff sein, weil die Aussagen in dem Artikel sind ja nicht falsch, aber es ist eben das Entwicklertagebuch EINES Entwicklers, also alles nur aus der persönlichen Evidenz heraus, hat beim ir nicht geklappt, klappt deswegen bei euch auch nicht.
Solche Aussagen wie "Ein Branch sollte nie mehr als wenige Tage existieren", "Bei mir lebt ein Branch immer weniger als einen Tag". Was packt er in einen Branch? Eine Methode einer Klasse mit 5 Zeilen? Und dafür den kompletten Overhead eines Branches erzeugen?
Er findet Git flow zu kompliziert. Das System hat in seinem Grundbedürfnis 4 Befehle und das ist zu kompliziert? In welcher Sprache entwicklet der? Brainfuck?
Also das "Rebasen" hatte ich anders verstanden, ich dachte das wäre das "Update to HEAD..." aus SVN. Gibt es dazu ein äquivalent in Git? Also zum Update to head? Wir hatten zwar sehr selten, aber dennoch schon mal größere Merge-Arien durch, weil ein Kollege sehr lange an seiner Entwicklung hing und nie Update to Head gemacht hatte und am Ende zig Klassen geändert waren, die in vorherigen Commits schon betroffen waren.
Ich hab mir gerade mal den Artikel durchgelesen und muss sagen "Wow". Eigentlich habe ich von uns ITlern immer gedacht, dass wir die mit der Medienkompetenz sind. Soll jetzt kein direkter Angriff sein, weil die Aussagen in dem Artikel sind ja nicht falsch, aber es ist eben das Entwicklertagebuch EINES Entwicklers, also alles nur aus der persönlichen Evidenz heraus, hat beim ir nicht geklappt, klappt deswegen bei euch auch nicht.
Ja, das war auch ein erster Eindruck von mir. Zumal er ja auch direkt schreibt: "Some people can handle all this mental juggling but I can’t." Also er ist zu blöd dazu
Aber zur Ehr-Rettung: Er schreibst zwar seine Sicht, aber die geht ja nicht nur auf Ihn zurück. Er ist ja in Projekten und hat die Erfahrung gesammelt auch in Bezug auf andere Entwickler. Er ist ja nicht alleine stehend. Daher bitte sowas nicht überbewerten. Es ist halt sein Schreibstil.
Solche Aussagen wie "Ein Branch sollte nie mehr als wenige Tage existieren", "Bei mir lebt ein Branch immer weniger als einen Tag". Was packt er in einen Branch? Eine Methode einer Klasse mit 5 Zeilen? Und dafür den kompletten Overhead eines Branches erzeugen?
Da hat er prinzipiell Recht. Vergessen wir einmal die git, denn es geht ja um Feature Branches, also es geht um die Implementation von Features. Wenn wir in den agilen Arbeitsbereich gehen, dann landen wir z.B. beim Scrum und dann wird aus Features die Tasks vom Sprint Backlog. Evtl. auch mehrere, die zusammen gehören....
Und die sollten eigentlich so geschnitten sein, dass so ein Task in einem halben Tag fertig ist. Maximal ein Tag. Wenn die Welt untergeht und ein Task mal zwei Tage dauert: Ok, die Welt geht unter ... dann ist das halt MAL so.... So Dinge sind also schnell fertig gestellt und eingecheckt und abgehakt. Und natürlich auch gemerged, denn darauf basieren dann ja andere Tätigkeiten mit Abhängigkeiten!
Daher ja: dies kann ich durchaus nachvollziehen und das ist ein valider Punkt.
Aber die Probleme, die er da hinein interpretiert, die sehe ich nicht.
a) komplexer merge, wenn da ein Branch lange existiert? Wenn man regelmäßig ein rebase macht, dann ist das eben nicht auseinander gelaufen.
b) Komplexe Änderungen sind schwer zu reviewen? Ja evtl. sollte man eine Entwicklung über lange Zeit nicht erst am Ende prüfen? Was spricht gegen regelmäßige Code Reviews?
Bei allen anderen Komplexitäten: Hier ist immer die Frage: brauche ich das? Was sind die Anforderungen? Wie kann ich diese umsetzen? Was sind die geeigneten Mittel? Und da gilt immer: je einfacher ein Mittel zu bedienen ist und je einfacher man ans Ziel kommt, um so besser. Also was wir ja auch kennen: KISS.
Meine svn Zeit ist lange her, so dass ich da ChatGPT fragen musste, was das war. Und laut ChatGPT brachte das dein Arbeitsverzeichnis auf den aktuellen Stand. Also klingt es etwas nach einem "git pull", das dir (aus deinem Branch) die Updates holt und dann auch tatsächlich dich zum aktuellen HEAD des Branches bringt. Aber ich habe mich da jetzt nicht wirklich tief mit auseinander gesetzt.
Also das "Rebasen" hatte ich anders verstanden, ich dachte das wäre das "Update to HEAD..." aus SVN. Gibt es dazu ein äquivalent in Git? Also zum Update to head? Wir hatten zwar sehr selten, aber dennoch schon mal größere Merge-Arien durch, weil ein Kollege sehr lange an seiner Entwicklung hing und nie Update to Head gemacht hatte und am Ende zig Klassen geändert waren, die in vorherigen Commits schon betroffen waren.
Ich hole mal was aus und gehe mal auf das Konzept der Repositorys ein. Git ist ein Verteiltes Versionskontroll-System, wo es aus technischer Sicht keine zentrale Stelle gibt. Die gibt es nur per Konvention.
Es gibt in der Praxis in der Regel folgende Dinge:
Das Remote Repository (Was in der Regel in einer Firma per Konvention die zentrale Stelle ist) und was auf einem entfernen Server lebt (REMOTE)
Eine Kopie des remote Repository (KOPIE) - in git auch origin genannt
Das lokale Repository (LOKAL)
Den aktuellen Arbeitsbereich (ARBEIT)
Es gibt diverseste Befehle um damit zu hantieren.
git fetch
Aktualisiert KOPIE, in dem aus REMOTE die aktuellen Daten lädt
git merge
Mergt zwei Branches - die können beliebig aus KOPIE und LOKAL sein. Ohne weitere Parameter mergt es den Branch aus der Kopie in das lokale Repository.
Beim Merge gibt es mehrere Strategien
Fast-Foreward - wenn es in LOKAL keine Änderungen gibt, wird einfach der Stand aus KOPIE dran gehangen
Merge-Commit - Es gibt in LOKAL Änderungen. Es wird ein zusätzlicher Commit gemacht, der die Änderungen zusammenführt
Rebase - Es gibt in LOKAL Änderungen. Es wird der Stand aus KOPIE übernommen und die lokalen Änderungen hinten dran gehangen (Der Vater der Änderungen in LOKAL wird geändert)
git pull
Macht die beiden obigen Schritte.
Das heißt, wenn jemand direkt auf dem main branch arbeitet, reicht ein regelmäßiges git pull aus um aktuell sein.
Arbeitet er auf einem Feature-Branch, so sollte man regelmäßig ein git fetch gefolgt von einem git merge origin/main machen.
Ob man das per Merge Commit oder Rebase macht - Geschmacks/Konvetionssache. Eigentlich sogar auch fast egal, wenn man auf einem Feature Branch arbeitet, weil bei mergen des Feature Branches kann man sich entscheiden, wie viel der Historie des Feature Branches man mitnehmen will.
Und jetzt noch eine Frage zu einem Thema vom Anfang: Issues
Ich hatte ja geschrieben, dass wir das aktuell in JIRA machen (habe auch heute festgestellt, dass wenn man seine Commits ordentlich benennt, dann werden die sogar im JIRA mit dem zugehörigen Artikel verknüpft, ich sehe sogar, dass der JIRA an einem Pull-Request dran hängt).
Jetzt hatte ich schon mal eine Konversation mit Primefaces, die machen das komplett über GitHub. Das heißt ich eröffne einen Issue und darin läuft die gesamte Kommunikation ab.
Ich möchte mich jetzt nicht sinnlos in das Thema vertiefen, aber kann man hier JIRA und Git-Issues irgendwie verbinden?
Da wir hier von einem Firmen-Umfeld reden - da muss man immer so Dinge wie Datenschutz, DSGVO, Compliance bedenken. Wenn man Jira mit externen Anbietern verbindet ist da selten die Technik das Problem - eher das organisatorische. Den in einem Firmen-Internen Jira stehen oftmals auch Firmen-Interna drin. Und wenn man das mit einem öffentlichen Github verbindet, wird das sehr schnell gefährlich. (Falls sowas hier gemeint ist)
Nene, alles cool, wir haben ein eigenes GitHub in der Firma, alles andere wäre hier der Supergau. Ich musste mal hier einen Beitrag im Forum löschen lassen, weil ein Servername eines unserer Server in dem Beitrag stand.
Das war der Grund, warum ich nicht gefragt habe, ob wir einfach auf JIRA verzichten und alles in GitHub machen. Da nutzen wir in JIRA doch zu viele Möglichkeiten, wie das Schätzen von Aufwand, das Protokollieren von Aufwand und Überpunkte mit lauter Unterpunkten, usw.
Und jetzt mal eine Praxisfrage. Da ich aktuell der einzige Entwickler in unserem Projekt bin, kann ich ein wenig "spielen".
Ich habe also einen großen Feature-Branch da soll ganz viel rein. Branch A
Dann kam eine Anforderung rein, die Prio hatte, also habe ich einen neuen Branch vom main gezogen. Branch B
Also habe ich in Branch B alles fertig gemacht, abnehmen lassen und ein pull-request in main gemacht.
Also waren alle Änderungen aus Branch B im Main-Branch.
War mir bis eben egal, weil keine Dateien in beiden Entwicklungen doppelt angefasst wurden. Aber leider nur bis heute.
Also brauchte ich die neuste Version aus dem main-Branch in Branch A.
Ich hab ungefähr 3 Anleitungen gelesen und will nicht zählen, wie viele Zeilen Code ich verwendet habe.
Ich benutze aktuell MINGW64, weil wir noch nichts anderes haben. Die Konfiguration für Eclipse wird nicht gewartet, weil wir nächstes Jahr auf IntelliJ umsteigen werden.
Die Befehle waren in der Reihenfolge:
Code:
git checkout main
git pull origin main
git checkout BranchA
git merge main #An der Stelle musste ich eine Commit-Nachricht schreiben und erstmal googeln, wie ich das Fenster wieder verlasse
Dann waren alle Dateien in BranchA, welche im Main geändert worden sind auch geändert.
Ich war extra vorsichtig, damit es keine Konflikt-Dateien gibt, aber das wird der nächste Versuch sein.
Wir nutzen da aber oft kein merge - wir nutzen bei uns ein rebase, das etwas ähnliches macht. Der Verlauf der vorhandenen commits ist aber unterschiedlich.
Edit: Weil das bisher noch nicht angesprochen wurde: In dem Link wird auch beschrieben, wann rebase nicht verwendet werden sollte! Das ist vom Verständnis her sehr wichtig!
