00:00:00: Hallo und herzlich willkommen zu einer neuen Folge von Devs on Tape. Heute mit dem Titel

00:00:04: "Keine Versionierung, who cares? Ja, uns." Deswegen machen wir jetzt die Folge diese Woche zum

00:00:10: Glück auch wieder zu zweit. Und ja, caro, herzlich willkommen und viel Spaß bei der neuen Folge.

00:00:16: Ja, herzlich willkommen auch von mir. Ich bin sehr gespannt, wie die heutige Folge so wird. Es

00:00:38: geht um Versionierung, das habt ihr schon gehört, zum Einstieg, bevor wir so die Grundlagen erklären,

00:00:45: quasi bevor wir sagen, was es dann alles so gibt und was das eigentlich für einen Sinn hat.

00:00:50: Kai, wie war dein Einstieg in das Thema? Also hattest du eher einen positiven Einstieg oder hattest du einen negativen Einstieg?

00:00:57: Was sind so deine Emotionen dazu?

00:00:59: Ja, also ich habe dadurch natürlich im beruflichen Umfeld das erste Mal irgendwie was mitbekommen,

00:01:06: weil früher, wenn man natürlich selber entwickelte private Projekte und so Freizeitsachen,

00:01:10: Das hatte noch nicht den Umfang und noch nicht so diesen kritischen Faktor, dass man da direkt

00:01:14: mit gestartet hat.

00:01:15: Heutzutage ist das, glaube ich, ein bisschen anders, weil der Zugang da ein bisschen einfacher

00:01:19: ist als früher.

00:01:20: Da kommen wir heute mit Sicherheit auch noch mal drauf zu sprechen.

00:01:21: Bei mir war das tatsächlich so, dass ich dann im beruflichen Umfeld diese Komponenten

00:01:26: als Handwerkzeug mitbekommen habe, dass ich in Projekte gekommen bin, bei denen das schon

00:01:32: gang und gäbe war, dass man das verwendet, dass man seinen Code am Ende des Tages eincheckt

00:01:37: oder auch häufiger eincheckt und dass man sein Source Code irgendwo ablegt,

00:01:41: was nicht auf der lokalen Maschine ist.

00:01:42: Und das gibt ziemlich viele Gründe, die wir heute besprechen werden,

00:01:45: warum das sinnvoll ist, dass man es nicht nur lokal bei sich auf dem Gerät speichert.

00:01:49: Ich habe praktisch gelernt, damit zu arbeiten, noch bevor ich

00:01:53: irgendwie riesengroß positive oder negative Erfahrungen damit machen könnte.

00:01:58: Das kam dann alles etwas später.

00:02:00: Ja, das war für mich halt ein Handwerkszeug, wie jedes andere Tool auch, was ich verwende.

00:02:05: Wie war es denn bei dir?

00:02:07: Hast du da positive oder negative Erinnerungen?

00:02:09: Ja, also ich habe das tatsächlich auch relativ spät erst die ersten Kontakte mit gehabt,

00:02:16: weil vorher war es einfach nicht notwendig, weil ich eher so kleinere Ein-Mann-Projekte oder Ein-V-Projekte hatte.

00:02:21: Ja, und mein erster Kontakt war da tatsächlich ganz gut, also sehr, sehr gut sogar, weil ich mit einem Kollegen zusammen an einer Anwendung entwickelt habe.

00:02:33: Und wir sind uns da öfter mal in die Quere gekommen.

00:02:36: Wir mussten am Ende halt so Installationskrips zur Verfügung stellen.

00:02:40: Und durch die Versionierung hat sich das grundsätzlich geändert,

00:02:43: dass wir viel, viel mehr Qualität in diesen Installationskrips hatten,

00:02:47: dass wir viel mehr Qualität in den Sources hatten.

00:02:50: Dadurch, dass wir uns nicht erdauernd unsere Sachen zerschossen haben.

00:02:54: Das ja, also das war für mich ein Gamechanger, sage ich mal.

00:02:59: Also äußerst positiv.

00:03:00: Du hast jetzt schon die verschiedenen Ansätze oder die verschiedenen Gründe genannt oder Punkte

00:03:06: genannt, warum das das Leben vereinfacht oder verbessert hat bei euch jetzt in eurem Projekt.

00:03:10: Aber vielleicht sollten wir noch mal einen kleinen Schritt zurückgehen und mal besprechen,

00:03:13: was denn eigentlich Versionierung ist. Bevor wir das jetzt hier in diesem Podcast so inflationär

00:03:18: verwenden und so viel darüber sprechen, sollten wir vielleicht einfach mal diesen Begriff

00:03:22: Versionierung erklären. Was steckt dahinter? Was bedeutet das eigentlich, Caro?

00:03:27: Also Versionierung kennt wahrscheinlich fast jeder auch aus dem beruflichen oder universitären oder

00:03:35: aus dem schulischen Kontext. Das ist nicht nur auf die Entwicklung beschränkt, sondern wenn wir uns

00:03:41: zum Beispiel einen Sharepoint vorstellen, wenn wir uns irgendeine Dateiverwaltung vorstellen,

00:03:44: die ein bisschen mehr ist als unser Explorer auf dem Rechner, dann haben wir da oft auch eine

00:03:50: automatische Versionierung mit drin. Das heißt, dass wir zum Beispiel auch eine Version zurückrollen

00:03:54: könnten oder dass wir Änderungen rückgängig machen können, hat man zum Beispiel auch in

00:03:59: OneDrive oder so. Also da gibt es ganz, ganz viele verschiedene Stellen, wo man eigentlich schon

00:04:04: versteckte Versionierung hinter hat und wo das Thema auch gar nicht auf die Softwareentwicklung

00:04:09: beschränkt ist. Ja, eigentlich sogar tatsächlich sogar in der Office Suite. Also wenn man so ein

00:04:13: Word-Dokument hat und man nimmt den zurück- oder vorwärts-Button, dass man so kleine Incremente

00:04:18: von dem, was man gemacht hat, wieder vor- und zurückspringen kann. Ich glaube, da steckt

00:04:22: überall so dieser Gedanke der Versionierung hinter. Ich glaube, da ist auch nochmal der Begriff

00:04:26: Revision richtig an Ort und Stelle, sag ich mal, weil man glaube ich von verschiedenen Dokumenten

00:04:32: wie Verträgen oder Meldungen oder weiß ich nicht was für Dokumenten, dass man da verschiedene

00:04:37: Revisionen hat, die quasi aufeinander aufbauend sind. Dass man jetzt gerade bei Dokumenten,

00:04:41: das ist vielleicht sogar immer das Gesamtkonstrukt, was da ist. Ich habe eine erste Version davon und

00:04:46: dann habe ich eine zweite Ausführung, eine zweite Version, wo geringfügig was verändert wurde,

00:04:50: wo man dann im Nachhinein nochmal nachvollziehen kann, wo sind die Änderungen von dem ersten zu

00:04:56: dem zweiten Konstrukt oder von dem ersten Dokument zum zweiten Dokument. Ich glaube, dass diese

00:05:01: Erklärung oder dieses nicht ganz abstrakte, aber dieses besser vorstellbare, wenn man zwei Dokumente

00:05:06: hat, lässt sich ganz gut als Grundlage dafür nehmen, zu erklären, was Versionierung ist.

00:05:11: Und ja, du hast gerade schon erwähnt, was das für Vorteile hat. Wie hast du denn da jetzt deine

00:05:17: Entwicklung sozusagen verändert, seitdem du Versionierung kennst. Wie hat der Schritt,

00:05:22: was hat sich konkret getan bei dir, als du dann jetzt auch gleich damit gestartet bist?

00:05:26: Also einmal hat man oder in meinem speziellen Fall jetzt, ich bin ja in der Datenmarkteentwicklung

00:05:34: eher, das ist alles so ein bisschen hintendran, sage ich mal, im Gegensatz zu der Webentwicklung,

00:05:40: der modernen oder der Java-Entwicklung. Aber bei mir hat das ja im Grunde so verändert,

00:05:49: dass ich meine Sourcen nicht komplett in der Datenbank, das ist so typisch, dass man immer

00:05:53: alles so direkt in der Datenbank macht, dass das nicht mehr passiert, sondern dass ich das

00:05:57: zum Beispiel in meinem Dateisystem ablege. Die Scripts, die ich dort schreibe, die zum Beispiel,

00:06:03: die schreibe ich direkt in die Dateien rein und führe die dann im Anschluss in der Datenbank aus.

00:06:08: Also das von der Denkweise her, die Reihenfolge, wie ich mit Dateien arbeite,

00:06:14: zum Beispiel hat sich verändert.

00:06:15: Also ich lege dann alles in meinem Explorer zum Beispiel ab, also in meinem Repository lokal

00:06:20: und verwalte darüber dann meine Sources anstatt andersrum,

00:06:24: dass ich das direkt in der Anwendung oder in meiner Datenbank mache.

00:06:27: So man hat praktisch auch noch im Kopf, dass man quasi nicht

00:06:31: also dass das dieser eine Ort der Wahrheit sich verändert,

00:06:35: Also, dass man jetzt nicht sagt, alles das, was in der Datemarkt ist oder bei anderen Programmiersprachen,

00:06:40: nicht alles, was sich in diesem konkreten Projektordner, den ich lokal bei mir liegen habe,

00:06:44: ist die Wahrheit und es ist das einzig wahre sozusagen in meinem Projekt,

00:06:48: sondern es wird in vielen Unternehmen oder in vielen Projekten so gelebt,

00:06:53: dass das, was in der Versionskontrolle, zum Beispiel im Git,

00:06:56: da können wir später nochmal drauf zusprechen, auf die einzelnen Softwarekomponenten,

00:07:00: aber das, was in der Visionierungssoftware liegt, ist die Wahrheit.

00:07:03: Das ist die finalisierte aktuelle Version

00:07:06: oder das ist der aktuelle Zustand des Source Codes.

00:07:08: Und ich glaube, das ist das, was das Mindset

00:07:10: nochmal beim entwickeln ein bisschen verändert.

00:07:12: Wir haben einen aktuellen Stand, der für alle gleich ist

00:07:16: und das in der Versionierung.

00:07:17: Und von diesem Punkt aus wandern alle in unterschiedliche Richtungen weiter

00:07:20: und haben so eine eigene Version von dem, von dieser Wahrheit

00:07:24: bei sich auf dem Dateisystem und arbeiten da drauf.

00:07:26: Und in dem Moment, wo dieser Code, den ich lokal bei mir habe,

00:07:31: in die Versionierungs-Surfer wandert.

00:07:33: Da sind viele Prozesse mit involviert.

00:07:34: Auch das wird mit Sicherheit noch ein Bestandteil dieser Folge heute sein.

00:07:37: Also dieses Increment, was ich da rübergebe,

00:07:42: das wird in dem Moment dann zur Wahrheit, wo ich es abgebe.

00:07:44: Und das muss dann von der Qualität auch im Idealfall sein,

00:07:47: dass es das Zeug dazu hat, die neue Wahrheit zu sein.

00:07:50: Und ich glaube, das ist das, was in diesem Entwicklungsprozess

00:07:53: sich dann noch mal ein bisschen unterscheidet.

00:07:57: Genau. Und wie du es eben schon angesprochen hast,

00:08:00: Also man arbeitet auch auf dem gleichen Stand und man arbeitet dann dadurch auch irgendwie zusammen.

00:08:06: Also es hängt dann natürlich auch ein bisschen von dem System ab, was man benutzt.

00:08:09: Ich habe jetzt auch mit Git angefangen und da war es eigentlich ganz cool, dass mein Kollege und ich zum Beispiel unterschiedliche Datenmanken hatten.

00:08:18: Und wir konnten dann über Git quasi durch Branching, das ist auch nochmal ein weiteres Thema, was wahrscheinlich die Folge kommen wird.

00:08:26: hatten wir einfach die Möglichkeit, an verschiedenen Features zu arbeiten,

00:08:29: auf den gleichen Dateien, auf den gleichen Sources,

00:08:31: die dann am Ende zusammengeführt wurden.

00:08:33: Also man ist dort einfach flexibler, ohne dass man

00:08:38: das Ganze manuell zusammenführen muss in irgendwelchen Dateien.

00:08:42: Und dann geht irgendwas schief.

00:08:43: Das war bei uns öfter der Fall, dass dann die Installation nicht geklappt hat.

00:08:47: Und dann ist natürlich der Admin zu uns gekommen und hat uns

00:08:49: ja im übertragenen Sinne eine Stelle verpasst und

00:08:54: War natürlich für uns nicht...

00:08:57: Natürlich ist er nicht körperlich geworden,

00:09:00: aber er war nicht glücklich.

00:09:01: Und wir dadurch natürlich auch nicht.

00:09:04: Genau, das waren so die Kernthemen, die mich jetzt bewegt haben.

00:09:08: Also einmal die Zusammenarbeit mit den Kollegen,

00:09:11: dass das besser funktioniert hat mit den Dateien.

00:09:15: Und dass man die Wahrheit einfach zentral vorliegen hatte

00:09:20: und dass jeder auch wusste, wo die Wahrheit ist.

00:09:23: Also da gab es keine impliziten Absprachen oder so Interpretationsfreiraum.

00:09:29: Es ist einfach so gewesen, dass das im Repo lag und das, was im Repo ist, das führt halt,

00:09:34: egal ob jemand sagt, ich habe da was geändert oder nicht.

00:09:37: Es ist einfach dazu, es hat da zu sein quasi.

00:09:41: Das leitet auch schon direkt super zum nächsten Punkt weiter.

00:09:43: Also wir haben jetzt schon ein paar Tools genannt, wir haben jetzt auch schon mal Git konkret genannt

00:09:47: und wir haben auch schon so verschiedene Prozesse jetzt raushören können,

00:09:52: wie Versionierung funktioniert oder was da noch hinten dran hängt.

00:09:54: Also ich glaube, da kann man auch nochmal unterscheiden.

00:09:56: Was kann man mit Versionierung machen?

00:10:00: Was hängt da noch für ein, ich nenne jetzt einfach mal diesen Begriff DevOps.

00:10:03: Was kann sich, was kann sich da an diesem Versionierungssystem noch hinten dran

00:10:08: alles befinden? Ich glaube, das ist ein super Thema, um da nochmal

00:10:11: ein bisschen in die Tiefe zu gehen.

00:10:13: Und du hast gerade genannt, du benutzt Git, davon auch ein konkretes Feature.

00:10:16: Aber was nutzt du denn oder was kennst du denn noch so für Versionierungstools,

00:10:20: die man da verwenden kann?

00:10:21: Also es gibt natürlich eine ganze Menge.

00:10:24: Ich selbst habe tatsächlich nur zwei bis zweieinhalb in meinem Berufsleben getroffen bisher.

00:10:31: Das war einmal SVN, also Apache Subversion.

00:10:34: Das funktioniert einfach ein bisschen anders als Git beispielsweise.

00:10:39: Dann Git, mein absoluter Favorite.

00:10:41: Ich greife einfach schon mal vor.

00:10:44: Und dann habe ich auch noch Kontakt gehabt mit Microsoft TFS,

00:10:48: also dem Teams Foundation Server.

00:10:50: Das ist dann, denke ich, wie der Produktname schon sagt oder der Hersteller, das ist dann mehr für Microsoft Entwicklungen.

00:10:57: Ich meine, die Kollegen hatten da mit C# bzw.

00:11:02: .NET Anwendungen entwickelt und dort hatte ich dann so passiven Kontakt mit.

00:11:07: Ich glaube, da kommt dann auch wieder ein großer Begriff rein, und zwar einfach Integration.

00:11:14: Oder wenn man es auf Deutsch sagt, würde die Integration von der Versionierungssoftware in den Alltag oder in das Betriebssystem

00:11:20: oder in die Software, die man zur Entwicklung verwendet.

00:11:22: Und wenn wir jetzt SVN, Git und Microsoft TFS mal betrachten würden,

00:11:26: liegt natürlich nahe, dass bei der Entwicklung mit Microsoft Tools,

00:11:28: ob es jetzt Visual Studio ist, also nicht Visual Studio Code,

00:11:31: sondern tatsächlich diese große IDE noch, wenn man die verwendet

00:11:35: oder wenn man generell mit Windows unterwegs ist,

00:11:37: ist, glaube ich, die Integration von Microsoft TFS

00:11:41: früher zu dem Zeitpunkt, wo wir angefangen haben,

00:11:44: noch relativ größer gewesen als jetzt die Integration

00:11:48: von Git und SVN ins Betriebssystem.

00:11:50: Ich selber benutze auch am liebsten Git.

00:11:53: Ich habe aber auch mit SVN angefangen

00:11:55: und auch da sind verschiedene

00:11:57: Unterscheidungen nochmal zu machen,

00:11:58: wie man damit arbeitet,

00:11:59: was es da für Features gibt

00:12:00: und was es eben halt auch für Integration gibt

00:12:02: in dieser Software selbst.

00:12:04: Und wenn man jetzt mal

00:12:05: ein bisschen tiefer in Git reingehen wird,

00:12:08: da kann man da auch

00:12:09: verschiedene Plattformen schon mal nennen.

00:12:11: Das ist vielleicht auch ganz spannend

00:12:12: für unsere Zuhörer.

00:12:14: Wie kann ich denn das Ganze mal austesten?

00:12:16: Wie kann ich das Ganze denn benutzen?

00:12:18: Da können wir auch nochmal auf das grundsätzliche Prinzip von Git und SVN eingehen.

00:12:24: Aber an der Stelle können wir einfach mal ein paar Namen raushauen von Tools oder von großen Plattformen, wo man das verwenden kann.

00:12:32: Also für Git, kenn ich GitHub, Bitbucket, GitLab und letztendlich auch Git ist auch alleinstehend auf dem System verwendbar oder auch ohne große IDI darüber.

00:12:43: Du hast mit Sicherheit auch da eine Plattform, auf der du das verwendest, oder?

00:12:49: Ja, also ich selbst habe natürlich einen privaten GitHub-Account.

00:12:54: Natürlich.

00:12:56: Wenn man an Open-Source-Projekten mitwirken möchte, dann ist das meistens die Plattform der Wahl.

00:13:03: Ansonsten im Arbeitskontext habe ich bisher am meisten mit GitLab gearbeitet,

00:13:07: wobei das wahrscheinlich unter anderem daran liegt, dass GitLab ja auch eine kostenfreie Version hat,

00:13:13: wie man sich auf dem Server installieren kann und man dann einfach eine hübsche, übersichtliche UI hat.

00:13:19: Und ja, das ist mir ein Zusatz-Tool, aber tatsächlich gibt es auch noch Tortuase-Git, glaube ich,

00:13:29: das ist Git Tortuase, Tortuase-Git, ich weiß immer nicht, wie rum das geschrieben wird,

00:13:33: Aber das ist einfach nur mal so eine Integration quasi in den Windows Explorer, dass man, wenn man jetzt keine IDE hat,

00:13:39: so wie gesagt, das ist alles ein bisschen anders in der Datenbankentwicklung.

00:13:42: Die meisten Leute, die zum Beispiel moderner Webentwicklung oder moderne Anwendungsentwicklung unterwegs sind,

00:13:49: die haben ja auch so IDEs wie ja auch Visual Studio Code oder IntelliJ oder so.

00:13:56: Und dort ist das Ganze schon integriert.

00:14:00: Aber wenn man so was nicht hat, dann könnte man auch zum Beispiel

00:14:03: Tor Tor's Git benutzen, um dann Dinge zu pushen,

00:14:06: um das Ganze zu verwalten, ohne auf die Kommandozeile zurückgreifen zu müssen.

00:14:09: Das ist tatsächlich sogar ein Tool, womit ich mit SVN angefangen habe.

00:14:12: Also da heißt es dann, ich habe es noch mal Tor Tor als SVN genommen.

00:14:15: Man kann es natürlich Tor2HLVN nehmen.

00:14:18: Auch das ist die Integration von von SVN in den Windows Explorer damals.

00:14:22: Also das kenne ich auch noch, dass man dann in dieses Rechtsklick Menü,

00:14:25: was man auf Dateien oder Ordnern aufrufen kann, dass man da halt direkt

00:14:29: einen Zugriff auf die Versionskontrolle bekommt, dass man sagen kann, ich füge jetzt hier Files dazu,

00:14:33: ich entferne Files, ich setze Kommentare, ich committe, ich branche, ich mache das auch immer mit meiner Version

00:14:38: oder mit meinem Files, die ich im System habe.

00:14:42: Die Plattformen, die du gerade genannt hast, GitHub, Bitbucket und GitLab,

00:14:45: die hängen natürlich direkt an Git hinten dran.

00:14:48: Und das liegt auch so ein bisschen an der, an diesem modernen, an dieser Bewegung,

00:14:52: dass Git tatsächlich mittlerweile, glaube ich, überhand gewonnen hat, was die ganze Softwareentwicklung angeht.

00:14:58: dass da wirklich überwiegend jetzt auf Git gesetzt wird.

00:15:00: Und ich glaube, da an dieser Stelle nochmal

00:15:03: dieses Konstrukt zu erklären, wie das Ganze funktioniert.

00:15:06: Also wir haben mit einer Versionskontrolle oder mit einem Versionierungssystem,

00:15:10: wie man es halt auch mal nennen möchte, haben wir ja immer eine lokale und eine remote

00:15:14: Komponente. Das heißt immer im Regelfall haben wir das.

00:15:18: Das heißt, wir haben einen SVN Server, wir haben Git Server,

00:15:21: der das Backend von dieser Software, die wir auf unserem Client laufen, darstellen.

00:15:26: Wir können Git aber auch Standalone verwenden und können

00:15:28: das alles lokal bei uns auf dem Gerät behalten.

00:15:31: Und auch bei SVN ist das so.

00:15:33: Wir können alles lokal auf unserem Gerät behalten,

00:15:35: können auf diesen Versionsständen arbeiten, neue Versionen erzeugen.

00:15:39: Man hat diese gesamte Historie

00:15:42: von den Files, die man verändert hat auf dem eigenen Datalsystem.

00:15:45: Ich habe es eingangs schon mal gesagt,

00:15:48: warum das sinnvoll ist, die ganzen Dateien, die ganzen Versionen

00:15:51: und die ganze Software, die man so entwickelt,

00:15:53: nicht nur lokal auf dem Laptop überliegen zu haben

00:15:55: oder auf einem USB-Stick,

00:15:57: sondern dass man das auf einem anderen, sicheren System auch nochmal ablegt.

00:16:01: Da kommen dann diese Plattformen, die wir genannt haben, ins Spiel.

00:16:03: Bei SVN ist es relativ einfach.

00:16:06: Da hat man eben dieses Apache Subversion, wofür das ja steht.

00:16:10: Hat man als Software, die man auf einem Linux-System einfach installieren kann.

00:16:13: Das wird dann über ein Port freigegeben

00:16:15: und dann kann man dann mit seinem Client das einrichten,

00:16:17: dass das jetzt mein Remote Server ist, auf den ich pushen kann.

00:16:20: Und dann kann ich lokal quasi an den Dateien arbeiten, Versionen erzeugen

00:16:24: oder kann mehrere Branches oder neuere Tags von meinen Files erzeugen.

00:16:30: Und dann, wenn ich sage, jetzt bin ich mal zufrieden mit diesem Verlauf, den ich hatte,

00:16:33: kann ich das Richtung Server schicken.

00:16:34: Und dann ist da auch die Historie komplett abgebildet auf dem Remote-System.

00:16:38: Und das ist nochmal alles in dieser Hierarchie sozusagen abgelegt.

00:16:42: Bei Git ist es so, dass man es auch standalone auf einem anderen Server installieren kann.

00:16:46: Diese Basisgeschichte, dieses Grundlegende, das kann man selber auch auf dem Betriebssystem installieren

00:16:50: und auch ebenfalls als Remote und als Origin einrichten auf dem eigenen System,

00:16:57: dass man da halt hinkonekten möchte.

00:16:59: Aber das ist natürlich etwas, wo man dann schon entweder gewisse Skills braucht,

00:17:03: wenn man das alles selber aufsetzen möchte

00:17:05: oder wirklich einfach viel Zeit, die man da reinstecken kann, hat.

00:17:08: Da macht es das Ganze natürlich einfacher, wenn man eine schöne Webseite hat,

00:17:12: auf die man gehen kann, die man einfach bedienen kann

00:17:15: und wo man sich seine eigenen sogenannten Repositories erstellen kann,

00:17:18: auf die man dann letztendlich hinterher pusht oder Sachen hochschiebt.

00:17:22: Ich glaube, GitHub, du hast es gesagt, du hast natürlich deinen eigenen GitHub-Account.

00:17:26: Ich glaube, das ist einfach dem geschuldet, dass GitHub die größte und bekannteste Plattform ist,

00:17:31: auf der man das erreichen kann, dieses Ziel.

00:17:33: Wobei GitLab da für mich damals die Nase vorn hatte, weil es, wie du schon sagtest,

00:17:39: eine kostenlose Variante gibt, nicht nur remote, dass man GitLab auf einer kostenlosen,

00:17:44: kostenlosen offiziellen öffentlichen Instanz von denen selber betreiben kann,

00:17:48: sondern dass das auch on-premises ohne Probleme gibt.

00:17:51: Also man kann GitLab sich runterladen auf seinem eigenen Server installieren.

00:17:54: Dafür braucht man ein bisschen Know-how, klar.

00:17:57: Aber das geht auch mittlerweile mit so One-Click-Installern mehr oder weniger.

00:18:01: Und in dem Moment, wo es installiert ist, hat man diese schöne UI,

00:18:04: diese schöne Website, auf der man, also Website jetzt mal ganz einfach ausgedrückt,

00:18:07: auf der man sich selber so viele Repositories installieren kann

00:18:10: und noch vieles, vieles mehr auch machen kann damit.

00:18:13: Dann ist GitHub auch mal nachgezogen, so ein bisschen zur Historie davon.

00:18:16: Und GitHub hat dann irgendwann auch ermöglicht, dass man private Repositories für diejenigen machen kann,

00:18:21: die ihren Software, ihren Code nicht gleichzeitig mit der ganzen Welt teilen wollen.

00:18:25: In dem Fall, wo die dann diese Private Repositories auch kostenlos zur Verfügung gestellt haben,

00:18:29: ist, glaube ich, noch mal sehr viel mehr Interesse von Entwicklern auf GitHub, ja, gelenkt worden, sage ich mal.

00:18:36: Und Bitbucket war für mich meistens eher so im Kundenprojektumfeld,

00:18:41: oder in zentrale Server aufgesetzt wurden, weil das, soweit ich weiß, auch aus der

00:18:45: Atlassian-Geschichte kommt, wo man dann auch eine Jira-Integration hat,

00:18:51: was sich ja auch einfach bei super vielen Kunden wiederfinden lässt und deswegen

00:18:54: diese Wahl dann auch zu Bitbucket häufig gelenkt wird.

00:18:59: Und ja, also ich bin heutzutage auch überwiegend auf GitHub unterwegs,

00:19:02: habe da auch meine Private Repositories.

00:19:04: Wir haben da auch einen Enterprise Account von der Firma.

00:19:07: Und mittlerweile kann man, auch wenn man ein bisschen Geld in die Hand nimmt,

00:19:10: und auch ein eigenes GitHub Enterprise bei sich installieren.

00:19:12: Da gibt es keine kostenlose Variante, aber auch da gibt es diese Ableger,

00:19:17: dass man quasi ein eigenes GitHub für im Internen aufsetzen kann.

00:19:19: Ja, auch...

00:19:22: Um es kurz vorwegzunehmen,

00:19:27: das ist mit Sicherheit Stoff auch nochmal für eine komplette weitere Folge.

00:19:30: Diese ganzen Suiten, die ermöglichen halt nicht nur einfach

00:19:34: das Administrieren von einzelnen Repositories,

00:19:36: also quasi neu erstellen, verwalten, Backupen löschen und so weiter.

00:19:39: sondern man hat auch noch die Möglichkeit, Pipelines zu erzeugen,

00:19:42: die auch noch direkt mit dem Commit, mit dem Abschicken von unserem Source-Scout

00:19:46: andere Dinge tun, wie paketieren, kompilieren,

00:19:49: auch in Datenbanken einspielen beispielsweise.

00:19:51: Das macht das Ganze noch mal ein bisschen interessanter.

00:19:54: Das ist auch jetzt mega gehypt worden in den letzten Jahren,

00:19:58: dass man praktisch mit jedem GitHub-Repository direkt auch noch

00:20:02: so eine komplette Pipeline-Workflows hinten dran kriegen kann,

00:20:05: wo dann sogar schon fertige Sachen vorgeschlagen werden.

00:20:08: ... hey, du hast ein JavaScript-Projekt, wie wär's denn, ...

00:20:09: ... wenn wir automatisch das Ganze mit ...

00:20:11: ... ESLint checken, was du da machst, oder ...

00:20:13: ... du hast ein Node.js-Tool, möchtest du es direkt ...

00:20:17: ... paketieren für alle Betriebssysteme, oder ...

00:20:19: ... ja, du hast ein C# oder C++-Projekt, ...

00:20:23: ... möchtest du es direkt kompilieren, wenn du es ...

00:20:25: ... wenn du eine neue Version erstellt hast oder so.

00:20:27: Da kamen immer mehr solche Funktionalitäten, ...

00:20:29: ... die früher Handarbeit waren, ...

00:20:30: ... kommen da direkt mit rein.

00:20:32: Das heißt, ich kann sogar mit einem einzelnen Push ...

00:20:33: ... von meinem Betriebssystem ...

00:20:34: ... ins Repository ...

00:20:36: ... sofort etwas triggern, ...

00:20:37: was am anderen Ende dann ein Produkt oder ein neues Release von meiner Software bedeutet,

00:20:43: ohne dass ich da selber ein großes Handat legen muss oder sogar Geld in die Hand nehmen muss.

00:20:47: Ja, man kann ja dann, also wenn wir von dem Level sprechen, das ist ja schon wirklich sehr,

00:20:52: also sehr weit hinten quasi ein Prozess, kann man dann auch automatisierte Tests ausführen und so.

00:20:57: Also alles das, was zu diesem automatischen Deployments etc. gehört,

00:21:01: das kann man damit auch sehr gut integrieren und implementieren.

00:21:07: wo ich ein Fan von bin, um da einfach mal ein bisschen aus dem Leben herrschen zu plaudern,

00:21:11: wo ich ein absoluter Fan von bin bei GitHub und GitLab,

00:21:15: bei Bitbucket gibt es das bestimmt auch, aber damit habe ich tatsächlich noch nicht gearbeitet,

00:21:19: ist die Möglichkeit, das Reviewing zu gestalten.

00:21:24: Also wenn ich zum Beispiel ein Code produziere,

00:21:28: dass dann das pushe auf meinen Branch, wie gesagt, Branding erkläre ich gleich noch.

00:21:35: Und dann sage ich, meine Entwicklung ist jetzt fertig.

00:21:39: Und das gebe ich dann meinem Kollegen zum Review.

00:21:42: Dann bieten diese Plattformen zum Beispiel elegante und schöne Möglichkeiten,

00:21:48: das Review relativ einfach zu gestalten, wo man dann in der Web-Anwendung angezeigt bekommt,

00:21:54: was gibt es für Änderungen.

00:21:55: Man kann dort direkt Kommentare in den jeweiligen Zeilen hinterlegen.

00:21:58: Man kann miteinander kommunizieren über den geänderten Code.

00:22:01: Man kann sich auch die anderen Sachen natürlich alle angucken.

00:22:04: Man hat das einfach an einer Stelle und das ist zum Beispiel für mich auch einfach ein riesiger Vorteil.

00:22:10: Bei GitHub und GitLab heißt das ein bisschen anders.

00:22:12: Bei GitLab ist es der Merchrequest und bei GitHub ist es der Pullrequest.

00:22:16: Das ist für mich auf jeden Fall ein Feature, das ich bei Teamarbeit absolut empfehlen kann,

00:22:22: wenn man dann so ein Reviewing, schwieriges Wort, Prozess haben möchte.

00:22:27: Das ist dann ja noch ein bisschen vorgelagert, aber auch da kann man dann genau diese Pipelines

00:22:33: Zum Beispiel anschließend, wenn man das Ganze dann mit dem Bestätigen des Merchrequests

00:22:38: oder des Pull-Requests in den Masterreihen mercht, dass man dann die Pipeline anstößt.

00:22:43: Also so könnte dann ein Prozess sein.

00:22:45: Man entwickelt, man pusht das, jemand reviewt das, jemand bestätigt das.

00:22:49: Man kann auch noch ein doppeltes Approval machen und so.

00:22:51: Also da gibt es ganz viele Möglichkeiten, die man dann auch einstellen kann.

00:22:55: Und dann kann man am Ende automatisiert eben das ausfüllen lassen, dass es dann zum Beispiel

00:23:00: auf meine Testumgebung deployed wird oder ähnliches.

00:23:02: Also da gibt es super viele Möglichkeiten, da richtig integrativ Dinge zu machen.

00:23:07: Auch so Code Review, dass ich meine, dass es von der Form her und von der Formatierung her

00:23:16: alles richtig passt.

00:23:18: Da gibt es ja auch Automatismen über bestimmte Software, die dann guckt, ob das dann den

00:23:23: Code-Konventionen entspricht, dass die Tests dann auch alle automatisch ausgeführt werden

00:23:29: und das dann deployed wird.

00:23:30: Also da gibt es echt eine Million Möglichkeiten.

00:23:33: Ich glaube, das kann man aber nochmal hervorheben.

00:23:37: Alleine dieses Aufbauen von so Hierarchien oder von so verschiedenen Rollen in so einem Projekt auf so einer Plattform.

00:23:45: Also wir haben grundlegend zum Beispiel jetzt in diesem Fall Git unten drunter liegen, was diese Versionierung selber erst mal ermöglicht.

00:23:50: Dann haben wir die integrativen Prozesse oder die Integration, die Automatismen ermöglichen wie Codecheck, Codeconventions und so weiter.

00:23:57: Aber wir haben auch diese klare Rollentrennung von den Mitgliedern in einem Projekt.

00:24:00: Wir können sagen, es gibt Architekten, es gibt Projektleiter, es gibt Reviewer,

00:24:05: es gibt Tester und es gibt alle möglichen unterschiedlichen Personen,

00:24:08: die basierend auf diesen Tools sind.

00:24:10: Das ist nicht eine Eigenschaft von Git, sondern eher von diesen Plattformen,

00:24:13: auf denen wir uns bewegen und von dem Prozess, der dahinter steckt.

00:24:17: Wenn ich jetzt mal ein konkretes Beispiel nehme, es gibt eine ganze Reihe von Entwicklern,

00:24:20: die ihre eigenen Branches, ihre eigenen Ableger von diesem Projekt Repository haben

00:24:25: und die dürfen natürlich nicht alle in den Core kommen,

00:24:27: weil sonst ist es eine verteilte Verantwortung, die alle tragen.

00:24:31: Das heißt, jeder hat die Möglichkeit, diese Wahrheit,

00:24:33: die ich schon mal eingangs erwähnt habe, zu verändern.

00:24:35: Und das geht vielleicht in manchen Fällen ein bisschen zu weit.

00:24:38: Wenn wir über große Softwareprojekte reden, wo es Entwickler gibt,

00:24:41: Lead-Entwickler, Projektleiter gibt, Architekten gibt,

00:24:43: vielleicht auch so eine Kunden- und Dienstleister-Sicht oder Entwickler

00:24:48: und wie auch immer man das Ganze im Konstrukt sieht,

00:24:51: dann gibt es unterschiedliche Berechtigungen für unterschiedliche Dinge.

00:24:54: Und da sind diese von dir genannten Pull-Requests oder Merch-Requests

00:24:58: sind da, glaube ich, auch eine ganz wichtige Instanz.

00:25:02: Also das ist ein ganz wichtiges Konstrukt,

00:25:04: dass vielleicht derjenige, der den Code committet, nicht in der Lage sein darf,

00:25:06: diesen selber zu merchen oder zu diesen Pull-Request anzunehmen,

00:25:10: dass es da vielleicht ein unterschiedliches Level gibt,

00:25:12: dass man entweder vier Augen Prinzip macht mit einem gleichgestellten Entwickler

00:25:15: oder gleich erfahrenen Entwickler.

00:25:17: Oder dass man sagt, der Lead Developer übernimmt permanent

00:25:20: eigentlich auch die Rolle, gar nicht mehr selber so viel Code zu schreiben,

00:25:23: sondern eher diesen Reviewing-Prozess zu betreuen,

00:25:27: dass er ein Code Review macht für das,

00:25:29: was die einzelnen Entwickler zu dem Projekt beitragen,

00:25:32: um dann zu sagen, ich sehe hier noch was,

00:25:33: oder hier könnte man noch mal besser dran gehen,

00:25:35: oder das stimmt vielleicht nicht mit den anderen Komponenten überein,

00:25:38: da müssen wir noch mal überarbeiten.

00:25:39: Und dieser gesamte Flow, der ist unabhängig von der Versionierungssoftware selbst,

00:25:43: einfach super abzubilden.

00:25:45: Ich habe einen Mission Critical Feature,

00:25:48: zum Beispiel, was rein muss, ganz dringend.

00:25:50: Ich habe das entwickelt, ich habe das selber geprüft,

00:25:52: Ich habe vielleicht auch die technischen Tests darüber laufen lassen.

00:25:55: Smoke Tests als Entwickler beispielsweise.

00:25:57: Aber ich muss dann auf jeden Fall sicher gehen, dass nochmal jemand,

00:26:00: der vielleicht ein bisschen mehr Erfahrung hat in diesem Feld,

00:26:03: mein Code reviewt, bevor der dann in die Endversion reingeht,

00:26:06: weil man dann einfach eine höhere Qualität erzielen kann.

00:26:08: Und das sind zum einen diese automatisierten Prozesse,

00:26:10: die das für mich dann auch nochmal alles checken.

00:26:12: Erst wenn diese Häkchen alle grün sind,

00:26:14: wird dann nochmal per V-Augen-Prinzip oder vielleicht sogar

00:26:18: mit noch weiteren Testern und Reviewern das konkret geprüft.

00:26:21: konkret geprüft und danach über diese schöne Web-Anwendung weitergeklickt und dann approved

00:26:27: und dann kann es erst mit diesem Approval in die Wahrheit, in den Core reinlaufen und

00:26:33: hat dann praktisch den Einfluss auf das gesamte Projekt genommen.

00:26:38: Und da kann es dann wiederum auch in diesen Plattformen genutzt werden, dass es da Kanban-Bots

00:26:45: gibt, dass es da für die Projektleiter auch Werkzeuge gibt, die ziemlich nah am Source

00:26:49: Code dran sind.

00:26:50: Ich kann sogar Commits einzelne Tickets zuordnen,

00:26:53: einzelne Feature-Requests zuordnen.

00:26:55: Ich kann Fehler im Code mit bestimmten Tickets verbinden.

00:26:59: Ich kann Code als Lösung für ein Issue, für ein Ticket hinterlegen.

00:27:04: Und das funktioniert alles vom Klein bis hinten hin zum fertigen Produkt,

00:27:08: alles automatisch.

00:27:10: Wenn ich in meiner Commit-Message kleinzeitig bei mir im System hinterlege,

00:27:13: das bezieht sich mit so einer Raute auf ein bestimmtes Issue,

00:27:16: ... dann wird automatisch in der Software, ...

00:27:20: ... in diesem Ticket unten vermerkt, ...

00:27:22: ... dieser Code, der von dieser Person ...

00:27:24: ... zu diesem Zeitpunkt mit diesem Titel ...

00:27:25: ... oder mit diesem Namen von diesem Commit, ...

00:27:28: ... der spielt auf dieses Ticket ein ...

00:27:30: ... und das kann man dann an der Stelle ...

00:27:33: ... vielleicht auch als gefixt sehen.

00:27:35: Und dann hat man immer eine super Historie, ...

00:27:36: ... kann immer den Zustand von so einem Support Ticket ...

00:27:39: ... super verfolgen und kann am Ende, ...

00:27:41: ... sich sogar dann auch noch, ...

00:27:42: ... das kann man auch mal oben draufsetzen, ...

00:27:44: ... wenn man ein Release zusammenschnürt, ...

00:27:46: kann man sagen, dieses Ticket, dieses Issue ist behoben worden.

00:27:49: Das ist der Titel von dem Fix.

00:27:50: Das sind die Codezahlen, die werden dann hervorgehoben.

00:27:52: Also mittlerweile sind wir da so weit, dass quasi die Diversionierung Software,

00:27:57: obsetzt GitHub, Bitbucket, GitLab oder was auch immer ist,

00:28:00: wirklich den kompletten zentralen Punkt von dem gesamten Projekt einnehmen.

00:28:06: Also diese Software übernimmt praktisch das komplette Zentrum

00:28:10: mit allen Funktionalitäten, mit allen Werkzeugen, die es in so einem Projekt gibt.

00:28:15: Ja, mir ist gerade aufgefallen, wir sprechen jetzt natürlich sehr,

00:28:19: sehr viel über unser Lieblingstool.

00:28:22: Ja, gut.

00:28:23: Genau, also da nochmal eine Notiz am Rand,

00:28:28: das ist mir eben erst wieder eingefallen oder klar geworden.

00:28:31: Also es ist ja zum Beispiel auch so, dass viele Wirtschaftsprüfer

00:28:33: oder KPMG oder wie die Unternehmen auch alle heißen,

00:28:38: die dann ins Unternehmen kommen und halt prüfen, ob alles revisionssicher ist und so.

00:28:43: Die verlangen auch oft zum Beispiel eine Versionierung,

00:28:46: also erst mal per se.

00:28:48: Und dann hatte ich es zum Beispiel schon häufiger,

00:28:52: dass die auch gerne einen Ausdruck daraus hätten, um nachvollziehen zu können,

00:28:55: wie die Software entwickelt wird, ob das alles sicher ist, ob das so erlaubt ist.

00:29:00: Genau, da wird eine Versionierung grundsätzlich

00:29:04: eigentlich auch immer gern gesehen.

00:29:06: Da gibt es auch so Zertifizierung für, glaube ich.

00:29:08: Also man kann als Entwickler oder als als Firma

00:29:12: die Software entwickelt, kann man sich zertifizieren lassen über diese Prozesse.

00:29:15: Da gibt es auch Richtlinien für einzelne Projekte in gewissen Umfelden.

00:29:20: Ist das Zipflora von Umfeld?

00:29:23: Umfelde?

00:29:24: Gibt es in verschiedenen Projekten die Anforderungen,

00:29:28: dass der Entwicklungsprozess einer gewissen Lizenzierung oder Standardisierung,

00:29:32: dass das zertifiziert sein muss, was man da macht.

00:29:35: Und das ist dann meistens ein Bestandteil davon, dass man eine Versionierung Software

00:29:38: verwendet. Genau, also ich würde gerne nochmal über die Vor- und Nachteile sprechen beziehungsweise

00:29:46: ein bisschen auch die Unterschiede beleuchten. Also du meintest ja, du hattest auch schon Kontakt mit

00:29:53: SVN und Git zum Beispiel. Wie hast du dort die Arbeit wahrgenommen? Wie hat sich das unterschiedlich

00:29:59: für dich geäußert? Ja, also ich, es wäre glaube ich vermessen, wenn ich behaupten würde, ich habe

00:30:06: mit beiden Systemen alle Features und alle Möglichkeiten bis zur Gänze verstanden,

00:30:11: ausgenutzt und auch richtig verwendet. Ich habe auf jeden Fall den Eindruck zumindest,

00:30:16: das kann ich so sagen, dass man bei Git wesentlich mehr Logik und wesentlich mehr

00:30:20: Funktionalitäten auf Serverseite hat und auch, dass es gleichzeitig auch ein bisschen komplexer ist,

00:30:25: als es bei SVN der Fall war. Wenn ich jetzt mal so zurückdenke, in die Zeit, wo ich mit SVN

00:30:30: gearbeitet habe, da hat man weniger die Version, die lokal geführt wurden, die glaube ich auch

00:30:36: wirklich nur sehr spartanisch vorliegen. Gar nicht so sehr diese Branchings und so weiter,

00:30:42: dass das alles so lokal so super verfügbar war, dass die Datenbank, die dahinter steckt,

00:30:47: so umfangreich war, dass man da alle Features, die jetzt Git beispielsweise zur Verfügung stellt,

00:30:51: ich wandere schon wieder in die Richtung, nur die Vorteile von Git irgendwie haben wir zu

00:30:54: Aber dass man da nicht so viele Möglichkeiten hatte,

00:30:58: was das Ganze weniger komplex gemacht hat.

00:31:00: Also für mich war das letztendlich Auschecken von so einem SVN Repository.

00:31:04: Heißt, alle Files wurden vom Server untergeladen.

00:31:06: Dann habe ich in dem Verzeichnis neue Ordner angelegt.

00:31:09: Und dann gibt es immer diese typischen Bezeichnungen,

00:31:12: dass man einen Trunk hat, einen Textordner hat

00:31:15: und auch einen Branches Ordner hat.

00:31:16: Und da hat man, glaube ich, mehr auf Datalsystemebene gearbeitet,

00:31:19: um die Version von den Files zu erzeugen.

00:31:21: Hat auf den Dateien gearbeitet

00:31:23: und hat diese Dateien einzeln der Versionierung hinzugefügt

00:31:25: und hat dann irgendwo am Ende einen Commit gemacht Richtung dieser SVN Datenbank.

00:31:30: Ich glaube, wenn man dann eine Version zurückspringen wollte,

00:31:32: hat man die dann wieder vom Server sich abgeholt und gar nicht so sehr alles lokal betrieben.

00:31:37: Aber das war vielleicht auch einfach historisch jetzt aus meiner Vergangenheit

00:31:41: so ein bisschen dadurch auch zu begründen, dass ich natürlich mit SVN gestartet bin damals,

00:31:45: also jetzt noch nicht den super professionellen Prozess der Softwareentwicklung

00:31:50: von Tag eins angemacht habe, deswegen vielleicht auch SVN

00:31:53: ein bisschen spartanischer genutzt, als es eigentlich möglich gewesen wäre.

00:31:57: Aber ich habe dann mit dem Kennenlernen von Gilt natürlich diesen Sprung gehabt.

00:32:01: Ich habe hier viel mehr Möglichkeiten.

00:32:03: Es ist aber auch viel komplizierter.

00:32:05: Ich muss mich da viel mehr einarbeiten, als es bei SVN war,

00:32:07: wo es bei SVN zum Beispiel die Möglichkeit gab, über dieses Tor

00:32:11: Tor, wie auch immer dann per Rechtsklick zu sagen, ich möchte

00:32:16: neuen Tag erzeugen.

00:32:18: Dieses Fall soll dazu hinzugefügt werden.

00:32:20: Ich möchte dieses File taggen, dieses File taggen,

00:32:22: hatte für mich den Eindruck gemacht, dass letztendlich einfach Kopien

00:32:25: oder Aliasse von dieser Datei in den Tag-Ordner gewandert sind.

00:32:29: Und erst dann, wenn man gesagt hat, ich möchte jetzt hier raus ein Release

00:32:32: oder eine fertige Version erzeugen, hat er dann mit diesen Aliasen das neu zusammengebaut.

00:32:37: So den Eindruck hatte ich dann an der Stelle.

00:32:39: Mit Git ist der Prozess ein bisschen anders.

00:32:42: Da ist ein bisschen mehr Komplexität auch auf dem lokalen Datalsystem.

00:32:45: Ich habe es gerade gesagt, dass man da Versionen vor- und zurückspringen kann,

00:32:50: dass man sich Unterschiede angucken kann von einzelnen Dateien,

00:32:53: dass ich diese gesamte Versionierung, diese gesamte Historie eines Files

00:32:59: auch bei mir lokal auf dem System habe,

00:33:01: noch bevor auch nur ein Remote-System davon irgendwas mitbekommen hat.

00:33:04: Und das war für mich das, was so als Unterschied im Kopf geblieben ist.

00:33:09: Ja, ich habe auch, also bei Sv1 habe ich tatsächlich auch das Gefühl,

00:33:13: Das fühlt sich oft, wie soll man sagen, simpler an.

00:33:17: Aber ich glaube, es gibt auch super viele Optionen, die viele gar nicht einschalten oder verwenden.

00:33:22: Da, wo ich es persönlich am häufigsten gesehen habe, was Git halt beispielsweise nicht hat,

00:33:28: weil es einfach dezentral auch gedacht ist und das nur über Plugins oder 4-Party-Software möglich ist,

00:33:35: ist zum Beispiel, dass ich sagen kann, ich möchte diese Datei locken.

00:33:38: Und was heißt das Locken? Also eigentlich nur Sperren.

00:33:42: Also nicht die Haare, sondern dass man die Datei sperrt für andere.

00:33:47: Und das mag jetzt wieder dann schwenk auf die moderne Softwareentwicklung, mag da jetzt

00:33:52: vielleicht nicht unbedingt Sinn machen, aber zum Beispiel wenn ich Binary Files habe, also

00:33:57: Dateien, die man nicht als Text quasi auslesen kann, was weiß ich, vielleicht Bilder am besten

00:34:05: als Beispiel.

00:34:06: Es gibt zum Beispiel im Oracle-Umfeld jetzt gibt es auch Anwendungen, wo man quasi so

00:34:13: ein generiertes File hat, was man nicht textuell auslesen kann.

00:34:17: Und das kann man dann ja schlecht merken, weil zum Beispiel Merchant heißt dann halt

00:34:22: eben zusammenführen meine Änderungen.

00:34:23: Und wenn man die Datei nicht auslesen kann, dann kann ich ja schlecht sagen, dass es dazu

00:34:29: gekommen ist und weggefallen ist.

00:34:31: Und in solchen Momenten ist dann dieses Sperren halt sehr von Vorteil, da wir dann einfach

00:34:36: sicherstellen können, dass kein Kollege neben mir an der gleichen Datei arbeitet.

00:34:40: Das ist so ein Vorteil, den ich am ehesten sehe bei SVN.

00:34:45: Ansonsten Branchen kann man ja wohl auch mit SVN, habe ich selber aber auch noch nicht

00:34:49: ausprobiert. Und ja, sagen wir mal so diese modernen, moderneren Features, die habe ich

00:34:54: mit SVN auch noch nicht, habe ich auch noch nicht mitgearbeitet, weil die meisten dann

00:34:58: auch ihre Umgebung halt hinstellen und ja dann vielleicht auch ein bisschen

00:35:03: fremdeln. Keine Ahnung ob es daran liegt, dass es dann vielleicht etwas anders

00:35:07: integriert ist als es geht oder ob es dann tatsächlich zu komplex wird, dass der Vorteil

00:35:11: von SVN eigentlich in dieser simplen Art und Weise liegt und das kann ich

00:35:16: aber auf jeden Fall bestätigen, dass GIT da ein bisschen komplizierter ist.

00:35:19: Allein dadurch, dass wir halt auch, das ist vorhin auch eben schon erwähnt, dass

00:35:24: man seine Sources immer lokal hat und dass man dann quasi so einen anderen

00:35:27: Status noch hat, so dazwischen, immer so eine Zwischenebene zwischen dem Zeitpunkt, wo ich

00:35:33: meine Software fertig oder meine Änderungen fertig gestellt habe und dem Server-Push im

00:35:40: Endeffekt. Dazwischen habe ich immer noch eine Ebene, weil ich kann zum Beispiel auch alles

00:35:43: lokal verwalten. Ich kann ja auch lokal sagen, ich habe meine Änderungen abgeschlossen und dann kann

00:35:48: ich sagen, okay, diese Änderung gebe ich jetzt folgenden Namen und da trage ich dann zum Beispiel

00:35:53: das, was wir vorhin schon erwähnt hatten, da trage ich dann zum Beispiel diese Ticket-Nummer ein,

00:35:56: die ich aus dem System habe, sei es Jira oder Redmine oder was auch immer für ein Tool man

00:36:02: dann da benutzt, also die Release-Nummer oder die Ticket-Nummer. Und dann bin ich in so einem

00:36:07: Zwischenstatus. Und bevor ich das zum Beispiel zum Server schicke, muss ich das halt explizit sagen,

00:36:13: ich möchte jetzt diese Änderungen zum Server schicken oder alle meine Änderungen, die ich

00:36:16: noch offen habe. Und das finde ich, da fängt es dann irgendwo schon an, dass Git ein bisschen

00:36:22: komplizierter wird. Gerade wenn Leute zum Beispiel vorher SVN benutzt haben oder irgendwie ein anderes

00:36:28: System, was ähnlich funktioniert, dann ist das einfach ein bisschen, das ist halt so ein extra

00:36:34: Schritt, den man dann auch mehr denken muss. Und ich finde auch, man muss ja auch oft so um die

00:36:40: Ecke denken. Zum Beispiel mit dem Branching. Wie waren denn so deine ersten Erfahrungen mit dem

00:36:44: Branching? Oder magst du vielleicht einmal kurz erklären, was das ist und wie dann so deine

00:36:49: Erfahrungen sind, hast du auch mal was kaputt gemacht zu mir.

00:36:53: Ja, ich glaube, es bleibt nicht aus, dass man in der Versionierungssoftware auch häufig mal an

00:36:58: den Punkt gekommen ist, am Anfang zumindest, dass man die Lokalen zuhause irgendwann einmal

00:37:03: alle weggeschmissen hat und einfach ein neues Verzeichnis ausgecheckt hat aus der Versionierung,

00:37:06: gesagt hat, jetzt lege ich da nochmal richtig los. Ja, also Branching, was macht das immer einfacher,

00:37:12: als diese Keywords oder diese Buzzwords aus der IT so zu nennen? Ist es häufig einfach vielleicht

00:37:17: vielleicht einen deutschen Begriff, der was Ähnliches dazu,

00:37:19: der das Ähnliche aussagt, der zwar weder in der Software

00:37:23: noch in so einem Projekt irgendwie mal auftaucht, aber ich glaube,

00:37:25: wenn man Branching mit Ableger aus der Pflanzenwelt vielleicht

00:37:31: erwähnt, dass man sagt, man nimmt das Repository zum gewissen

00:37:35: Zeitpunkt, erstellt einen Branchstoff an, einen Ableger,

00:37:38: der genau in dem gleichen Zustand ist und deren Namen bekommt,

00:37:41: dann ist es in dem Moment, wo ich ein Branch von meiner Repository

00:37:45: Erzeuger ist es ein identischer Klon, zeige ich mal.

00:37:47: Und es besteht nach wie vor, aber innerhalb der Versionierungssoftware

00:37:52: und ich rede jetzt natürlich mal wieder von Git, ist klar,

00:37:54: besteht nach wie vor immer diese Beziehung zwischen diesen beiden Klonen.

00:37:59: So, und wenn ich jetzt auf diesen Branch arbeite, weiß der Branch

00:38:03: auf jeden Fall, wo gehöre ich zu, zu welchem Zeitpunkt,

00:38:05: in welchem Moment, von welcher Quelle stamme ich denn ab?

00:38:10: Also wenn wir uns das jetzt bildlich,

00:38:12: wir haben unsere Notizen hier, wir gucken dann natürlich drauf,

00:38:14: wie so was aussieht oder wie so was dargestellt wird.

00:38:17: Wenn ich das jetzt versuche, halt nur über diesen Podcast

00:38:19: auf Tonspur zu erklären, würde ich mir das so vorstellen,

00:38:22: wir haben das Hauptrepository auf so einem Zeitstrahl

00:38:24: und ab einem gewissen Punkt auf diesem Zeitstrahl

00:38:27: fließt unsere Branch ab und läuft parallel zu diesem Zeitstrahl weiter.

00:38:31: So, Änderungen, die in dem Hauptrepository passieren,

00:38:34: während ich in meinem Branch bin,

00:38:36: während ich in meinem Ableger, in meinem zweiten Zeitstrahl bin,

00:38:38: kriege ich natürlich innerhalb meines Clones,

00:38:40: innerhalb von meinem Branch nicht mit.

00:38:42: Ich kann zwischendurch, kann ich mir natürlich,

00:38:45: das ist jetzt schon sehr in diesem Flow drin,

00:38:48: aber ich kann mir zwischendurch, während ich an diesem Branch arbeite,

00:38:50: wenn das etwas längerfristig oder so groß ist,

00:38:52: kann ich mir immer mal wieder die neueste Version vom Repository drüber abholen,

00:38:56: damit mein Branch nicht ganz so outdated ist.

00:38:59: Was das für Folgen hat, erkläre ich gleich.

00:39:01: Aber an der Stelle, wo ich auf diesem Branch arbeite,

00:39:04: baue ich auf dem Zustand des Repositories auf, den ich vorher hatte.

00:39:08: So, und ich kann aber an diesem Branch arbeiten,

00:39:10: ohne die Hauptfunktionalität des Cores von meinem Repository zu beeinflussen

00:39:15: oder auch andere Branches von anderen Kollegen zu beeinflussen.

00:39:18: So, und das ist dann so lange valide oder funktioniert so lange,

00:39:23: indem ich meinen Branch weiterführe, bis irgendwann der Punkt kommt,

00:39:26: wo ich sage, mein Branch, mein Ableger oder auch mein Feature,

00:39:30: was ich in Gens entwickelt habe, soll wieder zurück in den Core fließen,

00:39:34: in das Hauptrepository.

00:39:35: Und dann kommt der Punkt, den wir gerade schon mal erwähnt haben,

00:39:38: der Pull Request, der Merge Request, der das Ganze wieder zurückführt,

00:39:43: wo dann letztendlich der spannende Teil beginnt.

00:39:46: Also wenn ich im Unreal Feature arbeite,

00:39:48: können vielleicht Komponenten davon beeinflusst sein oder beeinflusst werden,

00:39:52: Dateiänderungen stattgefunden haben in der Software,

00:39:54: die auch in einem anderen Branch relevant waren.

00:39:57: Das heißt, es kann sogar unter Umständen passieren,

00:39:59: und ich mache das jetzt wirklich nur mit einem Branch

00:40:00: oder mit zwei Branches, die stattfinden, die parallel laufen,

00:40:03: dass zwei Personen in zwei unterschiedlichen Branches

00:40:07: die gleiche Datei von diesem Repository bearbeiten.

00:40:10: Da wird es in dem Moment spannend, wo ich das wieder zusammenführe

00:40:14: und von beiden Seiten Änderungen in das gleiche Fall stattfinden.

00:40:17: Das ist eigentlich theoretisch, wenn man sich das überlegt

00:40:19: und alles händisch machen möchte, eine enorme Arbeit.

00:40:22: Weil wir haben vielleicht teilweise die gleichen Codezeilen,

00:40:26: die bearbeitet worden sind.

00:40:27: Die können mal so super einfließen, weil es die gleichen Änderungen sind.

00:40:30: Ein Parameterwechsel vielleicht oder ein Versionsänderung,

00:40:32: Kommentare oder was auch immer.

00:40:34: Es können aber auch zentrale Funktionalitäten in dieser Datei beeinflusst werden,

00:40:39: wo dann wirklich von beiden Seiten Zeilen ineinander greifen müssen.

00:40:42: Und deswegen ist es dieser Prozess bei dem Zurückführen von einem Branch in den Core

00:40:46: schon alleine eigentlich eine super Aufgabe von einem erfahrenen Entwickler in einem Projekt,

00:40:50: vielleicht ein Lead Developer, dessen Aufgabe ist es, diese Rückführung dieser Branches zu übernehmen.

00:40:56: Das heißt, ich bau am Anfang Ableger, bau da mein Feature, ohne beeinflusst zu werden,

00:41:01: führ den hinterher wieder in den Chord zurück,

00:41:02: hab automatisierte Tests, ob das ohne Reibung funktioniert.

00:41:05: Das heißt, Software sagt mir,

00:41:07: da ist ein Merge Request auf diese Files hier.

00:41:08: Die funktionieren mit dem aktuellen Stand des Repositories.

00:41:12: Da wird Codecheck gemacht.

00:41:15: Dann gibt's noch den händischen Prozess,

00:41:17: wenn wirklich was ineinander laufen muss.

00:41:18: Und dann am Ende bin ich wieder auf einem Repository Stand

00:41:21: mit meinem neuen Feature drin.

00:41:24: Und ich hab eine neue Version letztendlich irgendwann

00:41:27: von meinem Repository.

00:41:29: Das war jetzt mal so in a nutshell sozusagen, ...

00:41:31: ... wie so eine Branch funktioniert.

00:41:33: Wir können aber tatsächlich noch eine weitere Komplexität einführen.

00:41:38: Und zwar kann es auch noch verschachtelte Branches geben, ...

00:41:42: ... viel mehr parallele Branches geben.

00:41:44: Es kann Branches geben, die weitere Branches beinhalten.

00:41:47: Das sind Riesenprozesse.

00:41:49: Und um da noch mal so einen kurzen Begriff reinzubringen, ...

00:41:52: ... Gitflow nennt man das oder Gitflow heißt das.

00:41:55: Und das zeigt auch noch mal ein bisschen die Komplexität, ...

00:41:57: Abgesehen von dem, was ich gerade erklärt habe, noch mal rein.

00:42:00: Wenn ich mit der Versionierung anfange und ich entscheide mich zum Beispiel

00:42:03: auch alleine nur schon mal auf Git, dann gibt es da von Projekt zu Projekt,

00:42:06: von Kunde zu Kunde, von Auftraggeber zu Auftraggeber oder von Chef zu Chef

00:42:10: oder was auch immer.

00:42:11: Gibt es da unterschiedliche Verständnisse, wie ich da rangehe,

00:42:14: welche Features ich verwende, welche Regelungen ich eingehe,

00:42:17: wer darf was checken, wie häufig darf ich Merch Request machen,

00:42:21: wer prüft die und so weiter.

00:42:23: Das, was ich gerade erklärt habe, was Branches angeht, ist so

00:42:26: ... diese typische Prinzip.

00:42:27: Aber alles, was darüber hinausgeht, ...

00:42:29: ... würde ich fast behaupten, ...

00:42:31: ... ist überall unterschiedlich.

00:42:34: Also wie viele Branches tief darf ich gehen?

00:42:36: Wer darf welche Branches machen?

00:42:37: Wie häufig müssen die zurückgeführt werden?

00:42:39: Wie häufig bringe ich meinen Branch wieder up to date?

00:42:41: Das hinterher, das Zusammenführen des Codes ...

00:42:45: ... nicht irgendwie komplizierter macht.

00:42:46: In welchen Zeitabständen dürfen die sein?

00:42:48: Wie viele Features darf so ein Branch enthalten?

00:42:50: Das sind alles so Vereinbarungssachen ...

00:42:52: ... am Anfang von einem Projekt.

00:42:53: Deshalb möchte ich gar nicht, dass Branching ...

00:42:55: als solches hinstellen, wie ich es gerade gesagt habe,

00:42:58: und sagen, dass es jetzt jedem bekannt vorkommt

00:43:00: oder für jeden die absolute Definition dafür sein sollte.

00:43:03: Aber ich glaube, es erklärt ganz gut,

00:43:05: wie man das Prinzip Branching verstehen kann.

00:43:08: Nur noch eine kleine,

00:43:10: noch kleine Analogie zu der Softwareentwicklung,

00:43:15: die man früher vielleicht in den Anfängen,

00:43:18: den ersten Codezeilen so hatte.

00:43:19: Da hat man das Branching gemacht,

00:43:20: indem man den neuen Ordner, der auch neue Ordner hieß,

00:43:23: kopiert hat in neuer Ordner zwei.

00:43:25: ... danach aufzählen die Ordnernummern, ...

00:43:28: ... weil das hat Wunder so gut gemacht damals.

00:43:30: Und dann am Ende noch mal Unterstrich "Final" hintergesetzt.

00:43:33: So hat man früher Branching gemacht.

00:43:34: Ich habe meine Seite gemacht, die mir gefallen hat ...

00:43:38: ... und habe gesagt, jetzt versuche ich mal was Neues.

00:43:40: Jetzt bringe ich mal eine neue Komponente rein ...

00:43:42: ... und mein Weg, das zu machen, war ...

00:43:43: ... ich habe eine Kopie von meinem aktuellen Verzeichnis gemacht, ...

00:43:46: ... weil ich das, was da ja natürlich gerade schon existiert, ...

00:43:48: ... nicht kaputt machen wollte mit meinen Änderungen, ...

00:43:50: ... mit meinen Versuchen.

00:43:51: Deshalb habe ich da dran gearbeitet ...

00:43:53: ... und wenn das geklappt hat, habe ich aber eigentlich ...

00:43:55: diese vorherige Wahrheit, die funktioniert hat,

00:43:57: habe ich weggeschmissen und habe nur noch auf dem Branch weitergearbeitet.

00:43:59: Normalfall würde man das, wenn man das jetzt

00:44:02: in Relation zu diesem Git Prozedere sieht,

00:44:05: hätte ich eigentlich nur die Änderung, die ich in dieser Kopie meines Ordners

00:44:08: gemacht habe, wieder zurück in den Hauptordner geschoben und hätte gesagt,

00:44:11: so, das ist jetzt meine neue Wahrheit.

00:44:13: Ja, weil dieser händische Prozess natürlich so umfangreich ist oder wäre

00:44:17: und viele Sachen da wären, die, auf die geachtet werden muss,

00:44:21: hat man es natürlich früher nicht gemacht.

00:44:23: Das wird uns jetzt aber von Software wie Git übernommen und viel einfacher gestaltet.

00:44:31: Das ist für mich tatsächlich auch das Killer Feature von Git, das ganze Branching.

00:44:38: Damit einher geht auch so ein bisschen die Art und Weise, wie Git dann Änderungen ablegt.

00:44:43: Im Gegensatz zum Beispiel zu SVN.

00:44:45: Git zum Beispiel guckt sich, also das Beispiel, was wir vorhin hatten,

00:44:51: dass zwei Dateien zusammengeführt werden, dass man vielleicht an der gleichen Stelle

00:44:54: oder an einer anderen Stelle was geändert hat,

00:44:58: Git speichert sich quasi die Änderung weg.

00:45:00: Also er guckt, wie sieht meine Datei aus?

00:45:04: Erst mal schaut er, natürlich habe ich überhaupt Änderungen in der Datei.

00:45:06: Und dann guckt er in die Datei und zieht sich dann quasi die Zeilen raus,

00:45:10: also die Veränderung und speichert sich das dann so stückchenweise ab.

00:45:13: Und dadurch habe ich dann eben die Möglichkeit, dieses Branching zu machen,

00:45:17: dann das Merchen, also das Zusammenführen der Änderungen,

00:45:20: dass es dann auch relativ schnell geht, dass mir dann nur anzeigt, welche Zeilen sich geändert haben,

00:45:25: beziehungsweise dass er mir dann halt nur anzeigt, je nachdem, was für eine Strategie ich natürlich habe,

00:45:30: ja, was ich denn da zusammen merchen kann, beziehungsweise was dann da kollidiert.

00:45:36: Und genau, das für meinen Abschluss.

00:45:40: Also ich liebe Branching.

00:45:42: Vielleicht kann man es hören, vielleicht auch nicht.

00:45:45: Ja, und das ist für mich einfach so das Killerfeature von Git,

00:45:48: Wobei, wie gesagt, es kann auch branchen, aber die machen das auch irgendwie über Ordner.

00:45:53: Nur wie das technisch läuft, kann ich da tatsächlich auch gar nicht sagen,

00:45:57: weil die wenigstens benutzen, habe ich das Gefühl.

00:46:00: Ja, ich glaube, das ist mit mehr Projekt man auch arbeitet und je mehr man geht,

00:46:06: auch so letztendlich verwendet,

00:46:07: bekommt man immer ein besseres Feeling dafür.

00:46:09: Das Beste ist natürlich immer, wenn man jemanden hat,

00:46:11: der sich damit auseinandergesetzt hat und dann mal einmal diese Conventions einführt.

00:46:14: Diesen, ich habe es gerade mal genannt, Git Flow ist eine Art, wie man das machen kann.

00:46:18: Da gibt es eine Definition, die, glaube ich, GitHub selber auch veröffentlicht hat,

00:46:22: wo man dann praktisch sich auf diese Vorgehensweise mit der Verwendung

00:46:28: oder bei der Verwendung von Versionierungssoftware einigt, worauf man alle achtet und wo man dann arbeitet.

00:46:33: Und dann schneidet man sich praktisch irgendwo die Komplexität ab und alle arbeiten so.

00:46:37: Wenn man jemanden hat, der das schon sehr erfahren und sehr lange macht,

00:46:40: oder der sehr erfahren ist und das schon sehr lange macht, von dem kann man es direkt lernen.

00:46:45: hat am Anfang diese kleine Hürde, über die man springen muss,

00:46:47: weil man seinen eigenen Entwicklungsprozess anpassen muss oder verändern muss.

00:46:50: Aber ich glaube, am Ende des Tages mit jedem Projekt oder mit jedem Moment,

00:46:53: wo man mehr Versionierungssoftware einsetzt, mehr in diesem Denken ist,

00:46:57: fällt es einem leichter.

00:46:59: Und wenn man es auf gut Deutsch sagt, das rettet einem auch irgendwann mal den

00:47:02: allerwertesten, weil ich glaube, das ist auch schon häufig genug vorgekommen,

00:47:05: dass man da glücklich war.

00:47:07: Und das ist diese diese zu der Folgentitel nochmal die Erklärung.

00:47:11: Who cares?

00:47:13: Ja, ich glaube, Karol, ich glaube, wir beide können noch ein Lied von singen,

00:47:15: dass es mindestens einmal schon zu der Situation gekommen ist, wo uns das Ganze

00:47:20: wirklich gerettet hat, dass wir nochmal zurückspringen konnten und dass wir eine Version,

00:47:24: die vielleicht in der Produktion plötzlich nicht mehr funktioniert hatte,

00:47:26: ganz kurzfristig ohne vorher geplantes Backup einfach aus der Visionierung Software

00:47:31: nochmal wieder herstellen konnte und ein viel, viel einfaches Leben hatte am Ende

00:47:36: mit diesem Diffing, also mit diesem Diff, die Differenzen davon zu erkennen,

00:47:42: wo jetzt die Code-Änderungen waren und welche da vielleicht für die Probleme gesorgt haben können.

00:47:45: Wenn es dann wirklich mal zu dem seltenen Fall kommt, dass alle Automatismen diesen Fehler nicht erkannt haben,

00:47:50: sind wir doch bestimmt häufiger schon mal in die Situation gekommen, dass Diversionierungssoftware uns das Leben erleichtert hat

00:47:56: und gegebenenfalls sogar auch gerettet hat vor viel, viel mehr Arbeit, dass man wieder zurückspringen konnte

00:48:00: und innerhalb von kürzester Zeit wieder auf dem Stand war, den man vorher funktionierend vorliegen hatte.

00:48:06: Ja, da finde ich das an sich ein schönes Schlusswort, zumindest zu dem informativen Teil.

00:48:17: Daher, Kai, noch die letzte Frage an dich.

00:48:21: Was hast du so aus der Nutzung der Versionierung mitgenommen?

00:48:26: Was ist so das, was dich dort am meisten bewegt?

00:48:29: Was habe ich mitgenommen?

00:48:31: Auf jeden Fall eine ganze Menge mehr Versionen von meiner eigenen Software.

00:48:34: Nein, also ich habe festgestellt, dass ich sicherer entwickeln kann,

00:48:39: dass ich mir weniger Sorgen darum machen kann, wirklich mal irgendwas an die Wand zu fahren bei der Entwicklung,

00:48:43: dass ich nicht wieder herstellen kann, die Angst dateilich gespeichert zu haben.

00:48:49: Ja, also ich meine, das kann natürlich alles immer noch passieren,

00:48:54: aber ich glaube, die Sicherheit, die ich habe beim Entwickeln dadurch, dass ich eine Versionierungssoftware habe, ist erheblich gestiegen.

00:48:59: Auch die Möglichkeiten, nochmal zurückzuspringen, vorzuspringen,

00:49:04: mit mehreren Leuten zusammenzuentwickeln, das ist etwas,

00:49:06: was für mich heutzutage unverzichtbar ist für so ein Softwareprojekt.

00:49:09: Und was für mich natürlich auch nochmal so ein richtig spannender Teil ist,

00:49:13: mit dem Hintergrund als Systemintegrator.

00:49:14: Mich interessiert auch die Technologie und die Integration am Ende von so einer Versionierung.

00:49:19: Versionierung Software, wenn es jetzt GitHub oder GitLab zum Beispiel ist,

00:49:23: diese Prozesse und diese Workflows und diese Sachen, die man da automatisch einrichten kann,

00:49:27: Das lässt mein Herz tatsächlich deutlich schneller schlagen,

00:49:30: wenn ich das einsetzen kann.

00:49:31: Und ja, das ist das, was ich mitnehme von Versionierung.

00:49:35: Auf jeden Fall ein absolut notwendiges Mittel mittlerweile für die Softwareentwicklung.

00:49:39: Etwas, was ich sehr selten in Projekten nicht mehr sehe.

00:49:43: Das heißt, es gibt selten Projekte, in die ich gehe,

00:49:45: wo wirklich Versionierung noch überhaupt nicht eingeführt wurde.

00:49:47: Dementsprechend ist das für mich ein absolut notwendiges Werkzeug

00:49:51: für mich in meiner täglichen Arbeit.

00:49:52: Wie sieht es bei dir aus?

00:49:53: Carol, was hast du mitgenommen?

00:49:56: Ja, also ich hatte das im Laufe des Gesprächs ja schon erwähnt.

00:50:00: Also auf jeden Fall, dass es für mich einfach mittlerweile zur guten Softwareentwicklung dazugehört.

00:50:06: So pauschal kann und muss ich das dann an der Stelle auch sagen.

00:50:10: Ich habe vorher sehr, sehr viele Fehler gemacht, eben auch mit diesen Installationsscripts zum Beispiel.

00:50:15: Und es ist einfach, es hat sich halt einfach komplett geändert, seitdem ja,

00:50:19: seitdem dann diese Versionierung eingesetzt wurde.

00:50:23: Ich liebe das Branching.

00:50:24: Es ermöglicht mir vielleicht eine beliebte Meinung.

00:50:29: Ich weiß es nicht, aber es ermöglicht mir einfach parallele Bearbeitung von mehreren Themen.

00:50:33: Man soll sich natürlich nur auf eins konzentrieren, aber

00:50:36: ich habe einfach die Möglichkeit, Wartezeiten zu überbrücken und schon mit dem nächsten Thema

00:50:41: anzufangen an der gleichen Source oder halt einen Bug zu fixen,

00:50:45: während ich eigentlich noch ein Feature entwickle.

00:50:48: Das bietet mir halt einfach super viel Flexibilität.

00:50:51: Das liebe ich auch einfach total an dem Thema.

00:50:54: Wobei ich finde, ja, dass man also, du hattest es vorhin schon erzählt.

00:51:00: Ich hatte, ich habe mehr als einmal mein komplettes Repo weggeschlissen und neu gezogen.

00:51:04: Also man kann halt super schnell Dinge auch kaputt machen.

00:51:08: Also gerade eben mit Git.

00:51:09: Bei SVN hatte ich das, glaube ich, nur einmal, dass ich da irgendwas kaputt gemacht habe.

00:51:14: Und das sage ich einfach nur daran, dass er ich glaube, da gab es parallele Änderungen

00:51:18: oder so, die konnte er nicht richtig verarbeiten.

00:51:20: Aber bei Git passiert das sehr, sehr schnell und sehr oft.

00:51:24: Und man unterschätzt, glaube ich, auch manchmal einfach diese Komplexität,

00:51:27: vor allen Dingen, wenn man sich so Tools nimmt,

00:51:29: die einen dabei unterstützen sollen und man aber eigentlich noch gar nicht weiß,

00:51:33: was im Hintergrund dabei alles so ausgeführt wird.

00:51:35: Und ich hatte schon mehr als einmal die Situation,

00:51:38: dass ich mir da was angeguckt habe, was irgendwie kaputtgegangen ist

00:51:42: und ich mich gefragt habe, wie hast du das denn hinbekommen?

00:51:45: Was ist da passiert?

00:51:47: Ja, ja.

00:51:50: Das sind die Momente, an die man dann eher ungern zurückdenkt, aber die dann im Endeffekt

00:51:56: dann doch wieder gut ausgegeben sind.

00:51:57: Ja genau, also man kriegt das ja irgendwie alles immer gelöst, aber man braucht dann

00:52:00: tatsächlich jemanden, der dann ja auch Bescheid weiß, wie man das dann fixen kann.

00:52:05: Ja, aber alles in allem Versionierungen, also selbst wenn ich alleine entwickele in Projekten,

00:52:10: benutze ich mittlerweile, wenn dann, also mindestens eine lokale Versionierung mitgeht, einfach

00:52:15: um sicher zu sein, dass ich die verschiedenen Versionen auch abspeichern kann,

00:52:20: dass ich da zurückgehen kann und dass ich auch eine Ablage habe.

00:52:23: Was für ein wunderbares Schlusswort, Carbo.

00:52:27: Nochmal vielleicht abschließend keine Versionierung, who cares.

00:52:32: Wir definitiv. Bitte versucht euch dieses Thema mal anzueignen,

00:52:35: es überall mit einzubringen, wo ihr arbeitet, für euch selber einen neuen Ablauf

00:52:39: mit aufzunehmen, dann sind wir alle auf der sicheren Seite.

00:52:41: Und ja, wir hören uns in zwei Wochen wieder.

00:52:44: Vielen Dank fürs Zuhören und fürs Abonnieren, hoffe ich.

00:52:46: Bis übernächste Woche.

00:52:49: Danke dir, Caro, und bis dann.

00:52:51: Bis dann.

00:52:52: [Musik]