Wie funktionieren Versionskontrollsysteme wie Git & Co.?

Joel Kaczmarek: Hallo und herzlich willkommen zu einer neuen Folge Blackbox Tech von digitalkompakt. Mein Name ist Joel Kaczmarek. Hallo Johannes.

Johannes Schaback: Hallo Joel. Alte Keule, it's been too long. Ich freue mich. Ich freue mich sehr.

Joel Kaczmarek: Ich mich auch. Man merkt es manchmal nicht so als Zuhörer, aber wir haben viel zu lange nichts aufgenommen. Wir haben natürlich voraufgenommen. Aber wenn man dann sich mal so gefühlt drei Wochen ganz oft sieht und dann mal sechs Wochen gar nicht, dann hat man ja Entzugserscheinungen.

Johannes Schaback: Richtig. Und wir haben auch nur Plätzchen gefuttert die ganze Zeit.

Joel Kaczmarek: Dafür siehst du körperlich aber nach wie vor exzellent aus. In diesem Sinne wollen wir mal schauen, ob du den Komplimenten auch inhaltlich gerecht wirst. Wir reden heute über ein Thema, das so mancher vielleicht auch schon mal kennengelernt hat, selbst wenn er nicht Kerntechniker ist, dass er gemerkt hat, oh, meine Techies, die haben ja da so ein Tool, dieses GitHub, was ist denn das? Wir reden heute nämlich über Versionskontrollsysteme. Das klingt jetzt erstmal so ein bisschen wie Homer Simpson im Atomkraftwerk, muss da irgendwie was managen. Vielleicht ist es auch auf eine Art ähnlich komplex. Git hat da als ein spezielles Beispiel. Wir werden sicherlich auch mal über so Dienste wie den Bitbucket reden und auch noch ein paar andere Alternativen. Lass uns doch mal ganz simpel starten. Was genau ist ein Versionskontrollsystem und wozu brauche ich das?

Johannes Schaback: Genau, dafür muss man sich als allererstes vor Augen führen, wie Entwickler arbeiten. Also insbesondere Entwickler. Es ist jetzt Versionskontrollsysteme machen, wo wir anders sind. Aber Entwickler haben das Problem, dass sie an ganz, ganz, ganz vielen Dateien arbeiten und ganz viele kleine Änderungen an solchen, in der Regel Textdateien, arbeiten und eine Datei aufmachen, zwei, drei Zeilen ändern, speichern, kompilieren, ausprobieren, dann irgendeine andere Datei anfassen, speichern, kompilieren, ausprobieren und es dann ganz, ganz viele inkrementelle Änderungen an diesen Dateien vornehmen. Und so ein normales Softwareprojekt, Wenn es klein ist 10 Dateien, wenn es groß ist, so ein SAP hat wahrscheinlich mehrere Millionen, aber ein großes Software-Projekt hat mehrere 10.000 Dateien. Und die Änderungen in diesen Dateien müssen ja auch zu den anderen Teammitgliedern übertragen werden. Und das in einem konsistenten Zustand, sodass nicht eben eine Änderung fehlt, dafür ist die andere mitgekommen zu meinem Teammitglied, sondern es müssen wirklich alle Änderungen komplett sauber übertragen werden. Und hinzu kommt, dass ja unterschiedliche Leute gleichzeitig an denselben Dateien arbeiten. Das heißt, es kann zu sogenannten Konflikten kommen, dass ich eine Datei ändere und ich würde sie ihm schicken, vielleicht per E-Mail und mein Kollege hat aber dieselbe Datei schon geändert. Das ist auch ein Problem. Man kennt dasselbe Problem, insbesondere die Juristen unter uns kennen das, wenn man in einer Gruppe einen Vertrag entwirft, verwenden viele dieses Feature von Word Track Changes oder man spricht auch von einem Redline, weil dieses Track Changes letztendlich nichts anderes macht, als alle Änderungen rot zu untermalen oder zu unterstreichen, sodass andere Leute, die nach einem dieses File anschauen, sehen, wer wann was geändert hat. Und dann kann man einfach sagen, alle Änderungen übernehmen, sozusagen abnicken und sagen, alles klar, ist cool. Und so wird letztendlich Kollaboration organisiert an der ein und derselben Datei und Konflikte aufgelöst. Beispielsweise Google Docs funktioniert so, dass es live geändert wird. Das heißt also, jede Änderung ist unmittelbar und Leute können gleichzeitig an derselben Datei arbeiten. So wird es auch vermieden, dass der eine das andere überschreibt, weil jede Änderung unmittelbar ist. So, jetzt zurück zu diesem Versionskontrollsystem. Was die machen, ist, dass die die Änderung aufschreiben und übertragen. Es gibt da zwei Hauptprinzipien. Einmal gibt es das sogenannte zentrale Speichermodell, dass alle Änderungen als Kopie auf einem zentralen Server gespeichert werden. Und die Entwickler ziehen sich dann Kopien, sprich auch manchmal von Checkout, wieder runter auf ihre lokale Festplatte. Es gibt auch das andere Prinzip, das ist sozusagen das verteilte System, wie in so einem Peer-to-Peer-System. Netzwerk werden die Änderungen einfach mit allen Leuten, die das interessiert, verteilt. Und das ist so ganz grob, was Versionskontrollsysteme machen. Änderungen können, wenn sie eben Konflikte erzeugen, weil zwei Leute gleichzeitig dieselbe Stelle in einem Fall geändert haben, aufgelöst werden. Manchmal, weil dieses Versionskontrollsystem sehr smart ist und weiß, welche Änderung die letztendlich gültige ist. Und zusätzlich kann ein Feature verwendet werden, das nennt sich Branching, dass sozusagen ein neuer Arbeitszweig aufgemacht werden kann auf einer Kopie der ganzen Dateien, um dann sozusagen Änderungen über einen längeren Zeitpunkt hinweg zu tracken in dieser Kopie, um sie dann sozusagen in einem großen Schritt zurückzuführen in einen zentralen Arbeitsstrom. Man spricht dann auch von Merge. Man mergt den Branch dann wieder zurück in einen Hauptzweig, der dann beispielsweise released wird. Also so kann man sich das ungefähr vorstellen.

Joel Kaczmarek: Ja, gerade dieses ganze Thema Branching, das kenne ich noch sehr, sehr gut. Wir haben damals früher, als ich SessionBird mitentwickelt habe, während ich dann irgendwie am Frontend irgendwas rumgeschraubt habe und irgendwelche tollen Webseitentexte gebaut habe, irgendwie in HTML und die haben die anderen im Backend was gewerkelt und dann hatten wir, glaube ich, SourceTree gebaut, unser Tool der Wahl. Kann das sein?

Johannes Schaback: Ja, bitte.

Joel Kaczmarek: Wo es dann auch genau um solche Sachen ging, wo ich auch erstmal verstehen musste, okay, also Branching kann man sich ja wie so eine Verästelung vorstellen. Das heißt, man hat einen Hauptstamm und dann irgendwann gehen so unterschiedliche Äste ab und dann ist die Frage, wie kriegt man es wieder zusammen? Das ist ja wirklich, da merkt man dann mal, wie komplex Programmierung eigentlich ist. Wenn du sowas im Kopf wieder zusammenkriegen musst, okay, Wahnsinn, ich editiere gerade was, während andere Leute am offenen Herzen mitoperieren und wir füllen das alles wieder zusammen.

Johannes Schaback: Branching ist ein absolutes Spiel mit dem Feuer. Also wenn man es vor allem nicht kann, dann kann man sehr, sehr viel damit kaputt machen. Es ist leider gerade bei Leuten, die sich mit Versionskontrollsystemen nicht so gut auskennen oder eben ein spezielles Versionskontrollsystem, was eingesetzt wird, nicht so gut kennen, ist es in der Regel so, dass man damit halt auch mal ein komplettes Entwicklerteam oder so eine komplette Firma, die eben dann vielleicht auf einem Branch arbeitet, komplett kaputt geht.

Joel Kaczmarek: Da kriegst du auch wirklich irgendwie einen Knoten im Kopf. Das habe ich mich immer gefragt, was mache ich, wenn irgendwie drei Leute am gleichen Modul arbeiten, alle ändern das so und wie kriege ich das jetzt wieder miteinander verheiratet? Hast du da irgendwie Tipps, wie man da möglichst reibungsfrei durchkommt?

Johannes Schaback: Naja, letztendlich muss man wirklich wissen, muss man diese Grundlagen studieren und je nachdem, welches Beziehungskontrollsystem man nutzt, muss man wissen, wie das genau funktioniert und was die da zugrunde liegenden Vorteile Funktionalitäten sind und was das genau macht. Es gibt wunderbare GUI-Tools, die das grafisch aufbereiten, wo man sich gerade befindet, ob man gerade gebranched ist und in worein man gerade schreibt oder ob man gerade seinem Kollegen rechts von einem in die Suppe spuckt. Das würde ich letztendlich machen. Also ich würde immer versuchen, jeden Entwickler in so eine Schulung zu schicken. Es gibt ja meistens Pros, die sich eben mit dem eingesetzten System gut auskennen und dann dafür sorgen, dass einfach vernünftige Visualisierungstools verwendet werden. Das ist letztendlich unser Geheimrezept auch. Darüber hinaus gibt es auch so Processes, also Best Practice Processes, dass du bestimmte Rezepte befolgst und einfach einen Schritt nicht vor dem anderen machst und einfach immer ganz stur bestimmte Befehle abarbeitest, sodass du einfach sicher gehen kannst, dass du keinen Scheiß baust. Nichtsdestotrotz, also gerade bei Git, Git ist schon sehr komplex. passiert halt schon echt noch häufig Mist und das sieht man schon einfach häufig, dass Branching einfach so komplex ist.

Joel Kaczmarek: Dutzende beziehungsweise unter Umständen sogar hunderte von Menschen schreiben an einem großen verteilten Buch und ich habe so ein bisschen die Aufgabe, man stelle sich vor, drei Leute schreiben ein Kapitel und sind eigentlich gerade auf der gleichen Seite tätig und das in irgendeiner Form zu orchestrieren und wieder aufeinander abzustimmen und da eine Kontrolle zu haben, wie das jetzt eigentlich gerade versioniert ist. Wie muss ich mir das denn jetzt vorstellen? Wie ist eigentlich so ein Source-Code generell irgendwie organisiert? Weil das ist ja so ein bisschen der Kasus-Knaxus, wie man eigentlich sich so einem Thema nähert. Und du hast ja auch gerade Git schon gesagt, wo wir eigentlich auch mal so ein bisschen irgendwie hinkommen müssen, was das eigentlich genau ist.

Johannes Schaback: Also Source-Code ist so organisiert, dass du viele Textdateien hast, die wirklich einfach gelesen werden und in der Regel Zeilenänderungen enthalten. Also ich fange an, eine neue Datei anzulegen, dann ist die Datei leer und dann fange ich an, Zeilen einzuführen. Also Carriage Returns, je nachdem, ob man Windows oder je nachdem. Also Zeilen einzuführen und dieses Versionskontrollsystem verfolgt danach, welche Zeilen wie geändert wurden. Und das ist auch letztendlich. dann, wenn ich ganz häufig dann sage, so liebes Versionskontrollsystem, übernimm bitte meine Änderungen, mach mal so einen Snapshot von meiner jetzigen Änderung, dann habe ich auch die Möglichkeit, das zum Beispiel zurückzudrehen und mir den Source Code aus der Vergangenheit anzuschauen. Und ja, letztendlich ist es so organisiert, dass du wirklich einfach einen großen Baum hast und ein großes File-System aus ganz, ganz vielen Dateien. Wie du schon sagst, das Kapitel-Ding ist richtig. Idealerweise hast du so viele Dateien oder es ist so gut organisiert, dass du als Entwickler nicht ständig mit deinem Team kollidierst, weil du an derselben Datei arbeitest. Es ist aber nicht auszuschließen. Also gerade bei Refactorings, also wenn du bestehende Funktionalitäten einfach nur durch andere Codemaßnahmen ersetzt, kommt es einfach häufig vor, dass du Sachen umbenennst und einfach dadurch einfach jemand anders, der da gerade im Workscope ist, was veränderst. Das ist die Antwort zu der Frage, wie ist Source Code organisiert. Zu Git. Git heißt auf Deutsch so viel wie Arschloch oder Schwachkopf oder Idiot. Git geht zurück auf Linus Torvalds. Das ist der Mitbegründer oder auch so ein langer und nach wie vor sehr, sehr intensiv aktiver Maintainer des Linux Kernels. Der Linux Kernel ist Open Source und aus diesem Rahmen ist das auch entstanden, also der Linux Kernel Entwicklung. 2005 wurde der Linux-Kernel bis zu 2005 gehostet von Bitkeeper. Linus Torvalds hat sich aber überworfen und im Rahmen dieses Partings hat Linus Torvalds sich entschieden, ein neues Versionskontrollsystem zu bauen. Und daraus ist letztendlich Git entstanden. Und Git ist eben ein sogenanntes verteiltes System. Das heißt also, es gibt nicht einen zentralen Server, der alle Änderungen zusammenführt, sondern es wird letztlich jede Änderung verteilt an deine Peers. Es gab davor, es gibt schon seit den 80er, wahrscheinlich seit den 70er Jahren, Versionskontrollsysteme, die unterschiedlich eloquent sind. Also nach Git, was heutzutage eigentlich de facto Standard und absolut das populärste System ist, gab es davor schon, also zu meiner Zeit, als ich angefangen habe, das sogenannte Subversion System. Oder SVN, das eben ein zentrales System war. Das heißt also, ich brauche immer, wenn ich eine Änderung hochladen möchte und irgendwie wieder bereitstellen möchte für meine Kollegen, eine Internetverbindung. Jetzt im Zugset beispielsweise kann ich das nicht. Das ist bei Git so nicht der Fall, sonst wird da einfach erstmal alles lokal abgespeichert. Vor Subversion gab es CVS, das ist einfach oldschool, war auch schon zentral. Und ehrlich gesagt, vor CVS weiß ich gar nicht, was es gab. Wahrscheinlich hat man sich damals dann die Dateien hin und her geschickt, I don't know. Und genau, also Git ist letztendlich schneller, hat deutlich besseres Branch Management, also mächtigeres Branch Management, ist aber auch sehr komplex und arbeitet eigentlich nicht in dem Sinne auf Versionen, sodass ich sozusagen Versionen hochzeichne. zähle, wie beispielsweise es bei SVN ist, wo ich jetzt jede einzelne Änderung, die ich hochlade, wird mitgezählt, sodass ich dann irgendwann nach zwei Jahren down the road in meinem Softwareprozess irgendwie die 21 Millionenste Änderung habe oder Version habe, sondern es wird einfach nur gesnapshottet. Das heißt also, es wird einfach sozusagen immer der Status des aktuellen Projektes mit gesnapshottet, gechecksumpt und dann verteilt.

Joel Kaczmarek: Was ist denn gechecksumpt?

Johannes Schaback: Letztendlich gehst du über die Datei rüber und berechnest über den Inhalt der Datei eine kurze alphanumerische Zeichenfolge. Also beispielsweise SHA-1, also du hast eine große DEX-Datei, die kann beliebig groß sein. Kommt aber am Ende kommt ein Schlüssel raus, der eindeutig den Inhalt in dem Sinne kodiert, dass er, wenn du auch nur eine kleine Änderung vornimmst an dem Inhalt dieser Datei, ändert sich der Schlüssel komplett. Ferner kannst du nicht von dem Schlüssel, den du berechnet hast, oder von diesem String muss man sagen, du berechnest rückschließend auf den Inhalt der Datei. Das nennt sich Hashing.

Joel Kaczmarek: Da merkt man mal, wie abstrakt das manchmal ist.

Johannes Schaback: Genau. Das sind so die großen, großen Vorteile. Und es ist de facto, obwohl es saukomplex ist, hat es sich durchgesetzt. Das fand ich total interessant, weil ich war immer ein großer Subversion-Fan und musste wirklich einige Kröten schlucken, um mich auf Git einzustellen. Es gibt noch so ein Zwischending, das nennt sich Mercurial. Der Urban Legend nach wird das wohl auch bei Google eingesetzt. Mercurial ist zwischen Git und SVN so ein Mittelding. Es ist auch verteilt, aber deutlich leichter zu erlernen. Hat andere Nachteile, nicht so mächtig etc. Es gibt auch noch ein paar andere wie Perforce oder Bazaar. die aber de facto nicht relevant sind.

Joel Kaczmarek: Jetzt würde ja jemand, der irgendwie non-technisch bewandert ist, sagen, okay, Johannes, habe ich dich jetzt richtig verstanden? Git ist damit also ein Programm, um Versionen von Source-Codes zu kontrollieren.

Johannes Schaback: Exakt, genau. Ganz genau so ist es. Und auch zu verteilen. Du schiebst es auch hin und her.

Joel Kaczmarek: Und GitHub geht ja jetzt sozusagen noch einen Ticken weiter oder legt ja damit auch noch ein bestimmtes Layer drauf. Vielleicht gehen wir da auch mal drauf ein.

Johannes Schaback: GitHub ist ursprünglich mal gestartet als ein Git-Repository-Service. Also ich kann im Internet oder über eine Web-Oberfläche ein Git-Repository, also so ein Projekt, wo ich meinen Source Code drin organisieren möchte, anlegen und das dann veröffentlichen. Also andere können diesen Inhalt klonen, wie man so schön sagt, oder eben überforken, also unterschiedliche Arten von Kopieren in diese Source-Code-Repositories und kann dann mitarbeiten, kann also insbesondere für Open Source entscheiden, meine eigenen Änderungen einspielen oder kann es einfach nur beobachten oder kann es eben herunterladen und selber kompilieren. Und das ist eben GitHub. bei weitem nicht der erste Service, der damit gestartet ist. Es gab schon seit Jahren SourceForge. Es gab eben auch bis vor einigen Jahren Google Code, die eben etwas Ähnliches gemacht haben, das sozusagen Entwicklern ermöglicht wurde, insbesondere Open-Source-Projekte öffentlich zu hosten und immer diesen Source Code öffentlich zugänglich zu machen. Und das ist letztendlich die ursprüngliche Idee gewesen von GitHub. GitHub hat sich aber sehr schnell viel weiterentwickelt als ein reines Repository-Hosting. Es ist eine riesen Community aus Entwicklern. Es gibt sehr, sehr viele Statistiken und Tools, die um dieses Source-Code-Hosting herum entstanden sind. Also für das Tracen von Fehlern, für Project-Management, Wikis, Content-Management. Also ich kann meine Source-Code dokumentieren, mein Projekt dokumentieren. Ich kann downloaden. Ich kann also etliche Sachen machen, die um den Entwicklungsprozess von Source Code herum entstanden ist und der wichtig ist. Und ich kann mich insbesondere, und das ist eben noch das Tolle, ich kann mich als Entwickler auch ein bisschen selbst darstellen. Ich kann, indem ich bestimmte Projekte unterstütze oder weil ich eben einfach eine sehr, sehr populäre Open Source Library gebaut habe, der Welt zeigen, Jungs, guckt mal hier, so, das kann ich. Ich kann coden, so sieht mein Code aus. Ich mache meine Arbeit sichtbar, der Welt zugänglich. Ist interessant. Also wir gucken beispielsweise in den Bewerbungsgesprächen auch durchaus uns den Source Code an, den Leute auf Gitter posten.

Joel Kaczmarek: Ja, das ist mittlerweile ganz üblich geworden. Das höre ich öfters, dass die Leute sagen, wenn du jemanden hast, der innovativ denkt, der auch Lust hat, wirklich was zu kreieren, dass die dann wirklich hingehen und die bei GitHub irgendwie scannen und sagen, was machst du eigentlich so? Machst du auch Sachen, die irgendwie der Community wieder zurückfließen? Da habe ich jetzt schon öfters gehört, dass das passiert.

Johannes Schaback: Absolut. Es gibt eben den eben genannten, neben dem GitHub und dem Source, gibt es eben auch diesen großen Competitor Bitbucket von Atlassian, also dem Jira sozusagen Hersteller oder Entwickler, Und unterscheidet sich funktional, weil letztendlich ja dann doch Git drunter liegt, eigentlich fast gar nicht. Und GitHub ist eben sehr, sehr stark in der Open-Source-Community. Es ist auch vom Pricing her so, dass du für Open-Source-Projekte nichts bezahlen musst. Wohingegen du eben bei Bitbucket, wenn du private Repositories hosten möchtest, auch nichts bezahlen musst als Privatperson. Aber letztendlich unterscheiden die sich dann vom Pricing her mittlerweile nur noch wenig. Bitbucket ist leicht preiswerter, sind aber die beiden absolut zu nennen. Und bei Google Code damals war es sogar so, dass Google Code gesagt hat, okay, fuck. GitHub ist so groß, macht keinen Sinn für uns, sie weiterzumachen. Wir hören auf. SourceForge hat eben insbesondere aus der C- und C++-Community noch sehr, sehr viel. Ich weiß nicht, ob das ehrlich gesagt immer noch geht, aber du konntest sozusagen auf unterschiedlichen Betriebssystemen deinen Code kompilieren und ausliefern und testen. Das ist ziemlich gut. Aber ehrlich gesagt, diese drei, also GitHub, Bitbucket und Social, die nehmen sich jetzt nicht so viel. Es gibt auch noch zig andere kleine und haben von der Funktionalität oder von dem Problem, was sie lösen, sind die alle sehr, sehr ähnlich.

Joel Kaczmarek: Ich hänge ja gerade noch ein bisschen an dieser Kiste mit, man schaut als Arbeitgeber, was machen die Leute da. Ich habe ja witzigerweise, da kriege ich jetzt auch mit, dass das auch umgekehrt passiert. Also es könnte ja für viele Unternehmer relevant sein, dass man auch mal darüber nachdenkt. Es ist ja eine Form von Employer-Branding, dass einer zu mir gesagt hat, ja, ich bin Entwickler, ich wollte irgendwie zu dem und dem Unternehmen in Süddeutschland gehen. Dann habe ich mir mal die ganzen Techies rausgesucht und mal geguckt, was haben die eigentlich für Projekte bei GitHub. Da war da gar nichts. Keiner von denen war irgendwie bei GitHub existent. Also war für mich instant klar, da passiert nichts. Das ist irgendwie für mich die falsche Firma.

Johannes Schaback: Es ist natürlich gefährlich, weil du auf GitHub insbesondere Open-Source-Code findest. Wenn du dir eine Firma anschaust, die eben nicht so stark in Open-Source arbeitet, investieren kann, weil sie zu klein ist oder weil das aus policytechnischen Gründen nicht funktioniert. Ich würde jetzt beispielsweise, wenn ich ein Atomkraftwerk programmieren würde, meinen Source Code auch nicht live stellen, auch wenn es sicherlich Sinn machen würde, dass eine Menge Augenpaare auf diesen Source Code gucken. Darüber könnte man übrigens auch mal sprechen. Letztendlich, wie picky sollte ich sein, meinen Source Code zu veröffentlichen? Dann findest du dazu nichts, was aber nicht automatisch heißt, dass nicht trotzdem guter Code geschrieben wird. Das folgt nicht notwendigerweise daraus. Aber klar, du kannst natürlich dir schon anschauen, was können die Jungs, was machen die Jungs in ihrer Freizeit.

Joel Kaczmarek: Also wir fassen nochmal ein bisschen zusammen, wenn wir jetzt mal unsere Metapher weiter ausschlachten. Man kann sich das ein bisschen so vorstellen, dass ein GitHub so funktioniert, wenn ich jetzt ein Autor wäre von irgendwie Kurzgeschichten, die könnte ich da theoretisch sozusagen hinterlegen. Und wenn ich jetzt sage, das sind Kurzgeschichten, für die ich kein Geld haben möchte, sondern die ich der Öffentlichkeit zur Verfügung stelle, damit man sich da, weiß ich, Metaphern, Charaktere oder sowas mit rausnehmen kann. dann kannst du das dort machen. Also man kann sozusagen das ganze Thema dort irgendwie hosten zugänglich machen und eigentlich auch diesen, ich finde diesen Community-Gedanken auch ganz spannend, dass ich mir sehr gut vorstellen könnte, du bist ja als Entwickler, bist ja ein Stück weit Künstler. Künstler jetzt vielleicht nicht mit Farben, sondern eher irgendwie mit Worten, mit Zahlen, mit Algorithmen, dass man da eigentlich wirklich so sich nicht nur organisiert, sondern auch selbst darstellt. Jetzt haben wir irgendwie viel darüber geredet, wofür das gut ist, was man damit macht. Das hat ja durchaus auch den ein oder anderen Nachteil. Also wenn ich jetzt mal so drüber nachdenke, mein Source-Code liegt da. Das ist, wenn ich mich nicht schwerlichst täusche, ein US-Dienst. Damit liegt mein Source-Code drei Finger breit entfernt von Kollegen Trump und Co., jetzt mal überspitzt formuliert. Ist das so ein Thema, worüber man sich Gedanken machen sollte und was sind sonst so Nachteile, die du beim Thema GitHub siehst?

Johannes Schaback: Absolut, darüber muss man sich total Gedanken machen. Letztendlich muss ich mir auch ähnlich Gedanken machen darüber, wenn ich mich entscheide, welchen E-Mail-Provider ich beispielsweise nutze. Die Terms und Conditions sind natürlich sehr, sehr interessant zu lesen oder wichtig zu lesen an der Stelle, aber natürlich muss ich auch wissen, wie meine Firma grundsätzlich dazu steht mit dem Intellectual Property. Grundsätzlich habe ich das Gefühl, dass das heißer gegessen wird, das Thema, als es letztendlich ist. Gerade für Leute, die nicht verstehen, was Source Code ist. Weil ich kann mir zwar den Source Code anschauen von einem Autopiloten, von einem Flugzeug. Das heißt aber noch lange nicht, dass ich automatisch weiß, wie ich das Flugzeug zum Absturz bekomme. Oder wenn ich mir Banking-Software anschaue, dann heißt das ja noch lange nicht, oder Encryption-Algorithmen, dann heißt das ja noch lange nicht, dass ich diese Encryption knacken kann. Das ist im Gegenteil sogar gerade der Fall, dass RSA beispielsweise ein Encryption-Verfahren Open Source ist, aber eben nur die Schlüssel, also die Daten, die du dafür brauchst, immer geheim gehalten werden. Das heißt also, das Verfahren, der Source Code ist zwar öffentlich, aber du brauchst in der Regel Daten und eine sehr spezielle Infrastruktur, um dieses Programm laufen zu lassen, damit du überhaupt irgendwie den Wert, den diese Software entwickelt, in Kombination mit den Daten und dieser Umgebung für dich erschöpfbar macht. Und wenn du jetzt nicht gerade eben diesen einen Magic-Algorithmus, die Cola-Formel, auf GitHub postest, dann ist das in der Regel wirklich kein Problem. Deswegen sind auch wir bei Lahnzeile sehr, sehr offen darüber zu sprechen, wie unsere Architektur ist, was für Technologien wir verwenden, wie was funktioniert. sehr viel zusammenkommen muss, damit du dieses Business, so wie es zurzeit sehr gut funktioniert, klaubar würde. Und das ist es eben in der Regel mit Source Code nicht. Aber ja, du musst dir echt Gedanken darüber machen, wo dein Source Code liegt. Und das ist letztendlich eine Abwägungssache. Eine Alternative gibt es natürlich noch. Du kannst ja auch Git selber, so ist es ja ursprünglich auch entstanden, selber hosten. Du kannst ja auch einfach einen Server in die Ecke stellen und sagen, okay, ich Installieren wir darauf jetzt mal ein eigenes Git-Repository. Selbst in AWS, also in Amazon Cloud-Umgebung oder auch Google Cloud, bieten, sogar Strato High Drive übrigens, bieten, also nicht unbedingt der Begriff der Innovation, bieten Git-Repositories an. Es ist einfach relativ einfach, das zu hosten. Oder eine weitere Alternative ist GitLab. Es ist letztendlich sozusagen das lokale, wenn man so will, so ein kleines lokales Mini-GitHub, was letztendlich sozusagen ein Frontend bereitstellt, um das Anlegen und das Managen von Git-Repositories und zusätzlichen Entwickler-Features bereitzustellen. Dafür entscheiden sich auch sehr, sehr viele Firmen, weil sie eben gerade den Source-Code nicht aus der Hand geben wollen.

Joel Kaczmarek: Hast du sonst noch Faktoren, wo du sagst, die sprechen für dich eher gegen ein GitHub, wo du sagst, sollte man mal zumindest auf dem Schirm haben?

Johannes Schaback: Also es gibt natürlich Pricing-Argumente. Wir beispielsweise sind auf Bitbucket, was eher Feature-Gründe hat, weil wir eben eine sehr starke Atlassian-getriebene Firma sind. Die Integration ist unterschiedlich. Du hast unterschiedliche Möglichkeiten, in Chat-Clients dich zu integrieren. Das kommt wirklich sehr darauf an. nach meinem Dafürhalten ist, wenn man wirklich nur auf den reinen Git-Use-Case schaut, dann gibt es keine großen Vorteile zwischen den unterschiedlichen Hostern. Es ist wirklich dann letztendlich nur eine Pricing-Frage. Also wie groß ist mein Team? Wie viele Private Repositories möchte ich? Also die niemand anders sehen kann, außer meine Teammitglieder. Oder wie wichtig ist mir die Open Source Community? Dann würde ich mich eher für GitHub entscheiden. Also um mich dagegen zu entscheiden, ist es wirklich eher Ein Policy-Thema oder vielleicht ein Speed-Thema, dass ich immer so fette Repositories habe, die grundsätzlich nicht in der Cloud hausten möchte. Das sind so die zwei Hauptargumente, die ich jetzt aktuell sehe.

Joel Kaczmarek: Ja, das ist ja valide. So, jetzt haben wir irgendwie viel über Versionskontrollsysteme gesagt und GitHub als eine Plattform sozusagen, um damit zu arbeiten, vorgestellt. Was wären denn so deine drei bis fünf Tipps? vielleicht abschließend zu sagen, wenn ich mich mit dem Thema Versionskontrollsystem auseinandersetze, worauf sollte ich so im Daily Doing achten, worauf vielleicht auch bei der Auswahl und generell in der Abstimmung in meinem Team?

Johannes Schaback: Ja, da kann man in der Tat extrem viel verkacken von Anfang an. Und trust me, I'm an expert on verkacken. Wir haben da sehr viel gelernt, positiv formuliert. Also die Software-Architektur ist sehr, sehr entscheidend, dass die gut zusammenwirkt. funktioniert mit der Art und Weise, wie du deine Git-Repositories oder deine Versionskontrollsystem-Repositories schneidest. Also wenn du zum Beispiel in so einer Microservice-Environment bist, also du viele kleine Mini-Services programmierst, die du dann sozusagen zusammenorchestrierst, um einen großen Service anzubieten, kannst du dich entscheiden, ob du jeden einzelnen Service in ein einzelnes Git-Repository packst oder ob du ein großes Git-Repository hast, sodass du eben immer den großen Gesamtstate deiner gesamten Software-Landschaft snapshotten kannst. Das sind einfach unterschiedliche Ansätze. Das hat Vor- und Nachteile. Das eine ist, du kriegst immer, wenn du das alles in ein fettes Git-Repository packst, dann kriegst du das hin, dass du einen konsistenten Snapshot hast. Das heißt, wenn du einen Release machst, der irgendwie company-wide ist, dann kannst du den kompletten Release sicher sein. Das ist eben um fast alles. Was aber dazu führt, wenn du eine lokale kleine Änderung schnell mal hotfixen möchtest, dann musst du eigentlich den kompletten, je nachdem, kannst du noch branchen, aber in der Regel musst du das aus diesem Fan-Repository rausziehen. Wenn du das sozusagen in einem kleinen lokalen Repository hast, dann kannst du das leichter forken, kannst sozusagen andere Sachen machen. Häufig ist es auch einfach eine Größenfrage. Git funktioniert nicht so gut oder wie alle Versionskontrollsysteme mit sehr, sehr großen Files. Git hat es mittlerweile nachgelegt. Es gibt da Large File Support. Aber in der Regel, auch zum Beispiel auf Bitbucket, kannst du nicht mehr als drei oder vier Gigabyte hosten und danach ist Schluss. Das heißt, irgendwann musst du dich auch da entscheiden, wenn ich beispielsweise in einem grafisch intensiven Umfeld arbeite, dann will ich nicht meine ganzen riesigen RAW-Images oder Sound-Files in dasselbe Git-Repository packen wie mein Source-Code. Zumal das eben binäre Dateien sind und binäre Dateien lassen sich schlecht Mergen, weil wenn unterschiedlich, weil du nicht in diese Datei so richtig reingucken kannst. Das sind Sachen, auf die man total achten muss. Man muss darauf achten, wie mein Release Cycle ist, also wie mein Continuous Integration ist, also wie ich dafür sorge, dass mein Source Code ständig gecheckt wird, dass er korrekt funktioniert, wie er deployed wird, welche Leute was sehen dürfen. Es gibt auch Teams, die sehr restriktiv sind und sagen, ich möchte gar nicht, dass ein anderes Team sieht, wie mein Source Code aussieht, sondern die sollen ausschließlich über ein bestimmtes API mit mir sprechen und da dürfen sie die Dokumentation sehen. und das war's. Einfach auch um ihre Mental Load und ihre Versuchung einzuschränken. Da gibt es sehr unterschiedliche Ansätze, die man sich vorher gut überlegen muss. Weiter würde ich auf jeden Fall sicherstellen, dass wenn ich branche, ich weiß, wie man branched. Don't do it. Im Zweifelsfall erst mal starten ohne und dann mal gucken, wenn es mir zwei, dreimal auf die Füße gefallen ist, dass ich dann mir genau überlege, was meine Branching-Strategie ist und dann sowas zum Beispiel wie Gitflow oder Prozesse einführe und an die sich dann auch alle halten müssen. Weitere Frage ist Code Review. Wie funktioniert das? Also wenn ich jetzt beispielsweise jeder Entwickler Eine Möglichkeit, arbeitet immer erstmal auf seinem eigenen Branch und zieht erstmal alle Änderungen immer zu sich rein, ändert seine Sachen und schiebt es dann zurück. Und dann kann man sich entscheiden, gibt es einen Feature-Branch, wird der dann gereviewt, gecode-reviewt oder wird immer der Entwickler-Branch gereviewt. Also da gibt es unterschiedliche Methoden. Es gibt eine Vielzahl an Möglichkeiten, für die man sich entscheiden muss. Ich würde am Anfang immer erstmal sehr, sehr, sehr, sehr simpel starten. Erstmal, wenn ich sozusagen neu anfange, ein Repository, alles rein, Außer Bilder, also BDR-Dateien, aber allen Sourcecode rein und dann erstmal schauen, wenn das Projekt wirklich groß wird, wenn ich merke, meine Services müssen ständig getrennt deployed werden oder gehotfixed werden, wie auch immer, oder ich möchte wirklich nicht, dass es jemand sieht, dann ziehe ich das auseinander. Aber erstmal keep it super simple und das wäre meine Empfehlung.

Joel Kaczmarek: Hervorragend. Dann danke ich dir ganz herzlich für all die guten Tipps und auch für dein Wissen. Also man merkt, heute waren wir, glaube ich, schon nochmal ein Ticken technischer unterwegs als sonst, mit Forken, mit Merchen, mit Branchen, auch ein bisschen anglizistisch hier mit den Schwachköpfen, den Gits. Ich hoffe, man konnte ihm trotzdem folgen. und ich glaube, wenn jetzt aber jemand durch sein Office läuft und merkt, okay, der nutzt einer GitHub, dann sagt er, ah, das ist ein Tool, um mein Versionskontrollsystem zu managen. In diesem Sinne haben wir noch was vergessen? Nee, ich glaube nicht, oder? Ich danke dir ganz herzlich und danke natürlich allen fürs Zuhören.

Johannes Schaback: Vielen Dank.