Moin zu Folge 25 von Einfach Komplex. Burkhard ist wieder da, mein Burkhard. Moin Gerrit. So, und zwar soll es heute gehen um Versionsverwaltung, spezifischer sogar um Git, wahrscheinlich gerade die berühmteste Versionsverwaltung, die es so geht. Aber Burkhard, in deiner Historie gab es ja auch noch andere Systeme, habe ich schon gehört, die dazu verwendet wurden, oder? Ja, ja, mich gibt es schon länger als geht.
Insofern habe ich auch schon andere Sachen gesehen. Ja, ich hoffe, wir nerven euch nicht. Also Gerrit hat mich heute schon so ein bisschen demotiviert. Heute Morgen meinte, ich habe schon mal geguckt, es gibt tausend Podcasts über Git. Aber ich glaube, er fand sie alle noch nicht so richtig überzeugend. Also bin ich doch wieder motiviert, um mal zu gucken, ob wir Git irgendwie auch mal ein bisschen lustig und überzeugend erklären können.
Ich wollte nicht demotivieren, das tut mir leid, wenn ich das gemacht habe. Demotivieren ist vielleicht auch falsch, aber mir ist das andere Wort nicht eingefallen, da habe ich lieber schnell demotivieren gesagt, bevor du wieder schneiden musst. Okay, genau. Bevor wir dann aber in Git reingehen und die Versionsverwaltung, lasst mich einen Hinweis geben. Wir haben ja diesen Discord-Server, wo wir...
mit Hörerinnen und Hörern diskutieren können. So viel wird der Discord-Server noch nicht genutzt, aber wir haben jetzt dort Feedback bekommen, dass wir in Folge 20 und 22 hier und da mal einen kleinen Fehler eingebaut haben, natürlich nicht wissenslich und nicht mit Absicht, aber das passiert natürlich bei den ganzen Inhalten, können wir, kann Burkhard auch nicht immer alles auf dem Schirm haben.
Wen es interessiert, was da genau schiefgelaufen ist, soll sich bitte bei Discord anmelden. Der Link ist in den Shownotes. Und wir haben überlegt, wir wollen jetzt nicht jede Folge hier irgendwie jede kleine Korrektur wieder einspielen, sondern wir machen vielleicht irgendwann mal eine große...
Ja, Shame on Us-Folge, wo wir dann irgendwie alle Fehlerchen korrigieren, die so aufgelaufen sind. Es ist aber nichts gravierendes, so viel kann man sagen. Voll die lustige Idee, da freue ich mich schon drauf. Und auf der müssen wir auf jeden Fall ein bisschen was trinken dabei. Heute ist nämlich morgen, das wisst ihr ja nicht. Heute Morgen können wir ja noch nichts trinken nebenbei, außer Kaffee, sonst ist der Tag dahin. Gut, das nur zur Vorrede.
Dann lass uns in die Visionsverwaltung einsteigen und ich vermute, du hast irgendeine Art von Einführung, aber mich würde erst mal interessieren, was ist das? Versionsverwaltung bzw. warum ist sie eigentlich so wichtig und wie sieht die Welt ohne Versionsverwaltung aus? Du hast dann wahrscheinlich da und hier und da schon mal eine Erfahrung gemacht. Oh, die Welt ohne Versionsverwaltung, die kenne ich fast gar nicht. Ich glaube, die haben nur die Embedded-Entwickler manchmal immer noch.
Boah, das wäre schon krass, ohne Versionsverwaltung. Also Versionsverwaltung in der Software ist Brot und Butter. Also es gibt eigentlich keine Software mehr, die ohne Versionsverwaltung geschrieben wird, weil das so essentiell ist. Selbst wenn du es alleine schreibst, ist es noch essentiell irgendwie. Warum? Weil du so eine Software ja nicht...
Außer der Autor von Git selber, der hat das irgendwie in ein paar Monaten zusammengestellt, der hätte vielleicht sogar darauf verzichten können, nämlich Linus Torwalz. Aber kommen wir gleich zu. Nee, weil du ja an so einem Softwareprojekt irgendwie, das machst du ja nicht an einem Tag fertig. Und dann ist es fertig, sondern das dauert ja einen Moment. Und du gehst ja auch nicht, also es sei denn, du bist der Mozart, der Softwareentwickler, geht das ja nicht ohne Fehler von vorne nach hinten.
Sondern du stellst dann irgendwann fest, meine Entscheidung da vor einer Woche, ich weiß auch nicht, da kommen wir nicht so richtig hin und so, dann musst du wieder zurück. Dann willst du aber nicht alles zurück machen, du hast dir vielleicht an anderen Teilen von der Software gearbeitet und so weiter. Das heißt, du brauchst da irgendwie ein System, was dir dabei hilft.
genaue Historie zu wissen, wann hast du was gemacht, damit musst du auch selber ein bisschen was rein, also das kann dir nicht komplett abgenommen werden, du musst halt auch immer dran schreiben, was habe ich gemacht tatsächlich und warum, kommen wir gleich zu. Aber wenn du das hast, dann willst du halt sauber was rückgängig machen können. Bestimmte Teilaspekte sogar vielleicht nur rückgängig machen.
Das ist das eine, was du auf jeden Fall brauchst. Und dann habe ich schon mal so ein Bild genommen. Ich weiß gar nicht, in welcher Folge. Ist auch egal. Wenn du Software im Team schreibst, was ja typischerweise der Fall ist. Dann kann man sich so vorstellen, als würden irgendwie 10, 20 Leute, je nachdem groß ein Team ist, an einem Buch schreiben.
Was gefälligst irgendwie dann, wenn es fertig ist, sehr lesbar ist, eine Einleitung hat und einen roten Faden und so. Und wo du auch gar nicht merkst, dass es 20 Autoren waren, sondern im besten Fall liest sich das wie aus einem Guss.
Jetzt kannst du dir mal überlegen, wenn du das in echt probieren würdest, sagen die 20 Leute, lass dir mal ein Buch schreiben und dir dazu eine Idee. Die dürfen ja alle Ideen haben zu allen Kapiteln, also du teilst es nicht auf, du schreibst Kapitel 1, Kapitel 2, das wäre ja einfach. Aber die schreiben alle wild gleichzeitig am ganzen Buch rum. So kann man sich das vorstellen, so ist Software.
Und wenn du das nicht koordinierst mit dem System, wo die ihre Konflikte, kann ich ja sagen, die wollen an der gleichen Stelle editieren im Buch, weil der eine findet, die Geschichte soll so weitergehen und der andere so. Und wenn du das nicht irgendwie... koordinierst, technisch, dann kannst du dir schon vorstellen, wie das Buch dann aussieht und lesbar ist.
Also dafür brauchen wir, wir brauchen dafür Versionskontrolle. Software ist halt einfach quasi Text, der entsteht großer, langer, viel Text, von vielen Leuten geschrieben und die Versionskontrolle sortiert den ganzen Kram aus, sodass das zum Schluss irgendwie sagt. dass du vor und zurück gehen kannst und dass du siehst, wer hat was gemacht. Okay.
In einer der echt letzten Folgen, also noch nicht so lange her, dass du dieses Buchbeispiel gesagt hast. Und jetzt hat nicht vielleicht jeder und jede schon mal ein Buch mitgeschrieben, aber ich glaube, wir kennen ja alle die ganzen Office-Dateien, Verträge. irgendwelche Pamphlete, irgendwelche Memos, die man vielleicht schreibt und dann auch im Team schreibt. In der Google WorkSuite oder wie das heißt von Google oder halt bei Office 365 jetzt inzwischen.
Kann man sicher heutzutage dieses ganze V1, V2, V3, V-Final, V-Final, Final und so weiter. Irgendwie steht das halt spannend. Jeder, der in der Bachelorarbeit oder Masterarbeit oder irgendetwas geschrieben hat oder überhaupt einen längeren Text. Einen Aufsatz vielleicht schon. Ihr kennt das vielleicht schon so ein bisschen. Und ich gebe noch was dazu. Stell dir mal vor, du schreibst ein Buch und dein Hauptcharakter heißt irgendwie Bill.
Weil jetzt hast du irgendwie schon mal ein paar Seiten geschrieben und das ist immer der Bill und dann vielleicht noch seine Freundin, die Mary oder so, kommt halt auch vor. Und jetzt überlegst du dir, ah, Bill ist ein richtig blöder Name aus irgendeinem Grund. Jetzt willst du halt den Bill umbenennen, der soll halt Werner heißen oder so. Das nennt man Refactoring bei der Software. Und jetzt musst du halt an jeder Stelle, wo Bill vorkam, den Werner einführen.
Das geht jetzt einfach bei Word auch, also Search Replace kennen wir. Das heißt aber, dass du halt quer durch das ganze Buch, wo du immer aufkommst, eine kleine Veränderung machst. Und wenn du das halt mit mehreren Leuten machst, die dann jetzt vielleicht auch schon, also zum Beispiel, du schreibst es nicht alleine, mindestens zu zweit.
Und dein Kollege, der ist irgendwie gerade auf der Insel, weil er sich da gut entspannen kann, kann einen tollen Beitrag zu deinem Buch schreiben. Der kriegt ja gar nicht mit, dass du jetzt gerade mal den Bild zum Werner gemacht hast. Und der schreibt immer schön noch sein Kram mit Bild.
Und wenn ihr das dann wieder quasi in die Hauptlinie des Buches reinpackt, dann hast du auf einmal einen Werner und einen Bild im Buch. Dann ist der Leser, der komplett verwirrt. Und genau das alles wird dann aussortiert. Durch Technik und auch durch Prozesse, die darum etabliert werden. Auf beides gehen wir, glaube ich, ein. Okay, das war eine coole Einleitung.
Versionsverwaltung erlaubt, transparent zu machen im Code oder was am Ende auch Textdateien letzten Endes sind und sorgt dafür, dass es dann eben auch für alle nachvollziehbar ist, was dort passiert ist, indem man vielleicht kommentiert oder irgendwelche Notizen mit abspeichert. Das war das glaube ich schon so. angerissen gerade, ja. Prima.
Hast du noch was hinzuzufügen? Ja, ich habe was auf der Zunge, was ich schon mal vorbereiten will. Ich habe nämlich vor, dieser Folge eine kleine Wendung zu geben, eine vielleicht überraschende Wendung. Aber ich will mal eine Sache sagen, was das System technisch leisten muss.
ist quasi kleine Blöcke von Editierungen verwalten. Also wenn ich jetzt bei Nix anfange und fange an zu schreiben, dann schreibe ich vielleicht in einem Abend eine halbe Seite. Okay, da habe ich viel Wein getrunken. Sagen wir mal, ich schreibe zwei Seiten oder so. So, und dann bilde ich quasi diese zwei Seiten. einspielen in dieses Versionierungssystem. Also habe ich wie so eine Art Blog von Content bei uns in der Software als Sourcecode.
Und dann mache ich weiter. Und was das System leisten muss, ist, dass immer diese Blöcke sauber aneinander hängen. In einer Kette quasi. Ein Block nach dem anderen. Und dass ich quasi immer und zu jeder Zeit manipulationsfrei weiß, ich kann auch zurückgehen. Also ich kann dann quasi, wenn ich... ich sage mal, zehn Abschnitte geschrieben habe, zehn Blöcke gemacht habe, habe immer dran geschrieben, was habe ich da gerade gemacht.
Dann kann ich halt ganz transparent zurückgehen und gucke mir an, an welchem Tag, zu welchem Uhrzeit habe ich was verändert in diesem Buch. Weil diese Blöcke quasi kryptografisch sauber aneinandergereizt sind. So funktioniert Git intern auch. Mehr sage ich gerade mal nicht. Vielleicht ist der gewiefte Zuhörer, bei dem hat schon irgendwas geklingelt mit Block untereinanderhängen und kryptografisch und so. Bei mir hat es geklingelt, ja. Lustigerweise ist...
In einem der Podcasts, die ich zur Vorbereitung gehört habe, auch die Blockchain dann entsprechend gefallen. Sehr schön. Der Ritz ist ein aufmerksamer mit Podcaster. Die Blockchain, die werden wir nämlich auch noch mal ganz kurz anreißen und dann machen wir noch eine eigene Folge über Blockchain. Aber wer Git gut verstanden hat, der hat schon 90% der Blockchain.
Und das Geile ist ja, ich sage es jetzt, weil wir gerade das haben, das Coole ist ja, das Git, ich würde sagen, na klar, wir kennen ja alle jetzt irgendwie die Bitcoin und so.
Das ist ja ein bisschen speziell, aber so wirklich in einer krassen Anwendung und verteilt und im vollen Einsatz ist die Blockchain. Es ist nicht ganz eine Blockchain, da streiten sich aber auch die Geister, was ist wann eine Blockchain, aber Git ist schon... ziemlich krasse Block, also ziemlich nah an der Blockchain und es ist voll im Einsatz überall und zeigt den coolen Nutzen von so einer Technologie.
Also an dieser Stelle ist richtig, richtig nice so. Ich erzähle dann nachher nochmal, warum es nicht ganz so ist wie eine Blockchain, die wir so heute unter Blockchain verbinden, weil das ganze Proof of Work ist. nicht dabei ist, das wäre schlecht. Das ist nämlich...
Das ist nämlich, jetzt mache ich gerade eine Überleitung, das ist nämlich einer der Designgründe, überhaupt der Hauptgründe gewesen, warum Git entstanden ist, ist nämlich Performance. Jetzt müssen wir ganz kurz, wenn ich einhacken darf, nochmal zu Git kommen oder von Versionsverwaltung zu Git. Und dann nachher, ich glaube, wenn dann Git erklärt ist oder nochmal das ganze Versionsverwaltung, wie es jetzt heute verwendet wird,
dann kannst du wahrscheinlich wieder den Bogen schließen zur Blockchain. Können wir machen, ja. Genau, Versionsverwaltung ist klar. Jetzt haben wir schon gehört, es gibt Ähnlichkeiten zur Blockchain auch. Aber dann lass uns doch anfangen mit Einführung Git. Was ist Git? Warum ist gerade das? Das Versionsverwaltungssystem, was wir uns jetzt hier rausgepickt haben.
Und wie ist es zu Git gekommen? Da hast du auch schon den Linus Torwalz erwähnt. Ja, genau. Also wir wollen nicht zu lange die Geschichten machen, das kann ja jeder auch bei Wikipedia nachlesen. Aber genau, so grob gesprochen ist der Linus Torwalz, ist ja der... der Hauptautor des Linux-Betriebssystems und wacht quasi auch über diesen ganzen Linux-Kernel, wie es so heißt. Der Kernel ist quasi das Betriebssystem von Linux.
Und da kann man sich halt vorstellen, das macht er ja nicht alleine, sondern eine riesige Menge von Mitentwicklern entwickeln an dem Linux-System und machen das besser, also verändern Source-Code quasi. Und der arme Linus Torvalds, der ist auch so ein bisschen Benevolent Diktator oder sowas, aber man kann sich so vorstellen, dass fast alles an Veränderungen bei ihm irgendwann auf dem Schreibtisch vorbeikommt und er sich das anguckt, ob das passt.
Und wenn das so sein soll, dann braucht er halt ein Versionssystem, weil die Sachen kommen ja asynchron vorbei und dann gibt es hier nochmal eine Anmerkung, dann geht das wieder zurück, dann kommt das nochmal vorbei und in der Zwischenzeit sind drei andere Sachen vorbeigekommen und so weiter und so fort.
Für den ist so ein System zu haben, das total transparent und sehr schnell diese ganzen Sachen irgendwie darstellt. Was würde jetzt passieren, wenn dieser Schnipselcode noch eingefügt wird und so? Also das sogenannte Diffing, also sowas vorher, so sieht es danach aus und so weiter. Für den ist das ultra wichtig, ja. Und Linus Torvalds selber war mega genervt um 2000. Jetzt muss ich ein bisschen spicken, um 2005 herum gab es nämlich zwei Systeme. die Versionsverwaltung gemacht haben, aber...
Die waren halt alle irgendwie auch ein bisschen langsam. Und der Linux-Körnel ist halt auch mal richtig ein dickes Buch. Und wenn du dann langsam bist, dann dauert es halt einfach Zeit, bis es alles so durchläuft. Warum waren die langsam? Wahrscheinlich, weil es ein zentrales System war. Ja, genau. Es war auch ein zentrales System. Was heißt zentral? Also das heißt quasi, dass dein...
Dass deine Single Source of Truth, also dein Buch, quasi an einer Stelle auf einem zentralen Server quasi gehalten wird und alle, die daran arbeiten, die schicken quasi ihre Blöcke, also ihre Änderungswünsche quasi gegen diesen zentralen Server. Das setzt voraus, dass du irgendwie Internet hast, das setzt voraus, dass diese zentrale Mitte da irgendwie relativ performant ist und so weiter. So waren die meisten. Und dann kam noch dazu, dass auch eins, ich glaube, es war Bitkeeper, genau.
Eins von diesen Source Control Management Systemen, wie man sagt, SCM, auch die Abkürzung. Die haben, glaube ich, ihre Lizenz noch gewechselt irgendwie und es war irgendwie mal frei und sollte es dann nicht mehr sein. Und dann hat Linus gesagt, Wir brauchen irgendwie was, was schnell ist, was frei ist und was meine großen Anforderungen an so ein System erreicht. Und hat dann Marktanalyse gemacht und hat gesagt, es gibt keins.
Was machst du als Softwareentwickler? Setz dich halt in den Baust selber. krasserweise hatte das, glaube ich, in ein, zwei Monaten runtergetickert. Die erste Funktionäre von GTA. Er hatte, glaube ich, im April 2005 angefangen und ich meine, irgendwie einen Monat später hat das Ding schon den ersten...
Release gemacht quasi. Wann hast du das erste Mal dann davon gehört? Oder warst du da schon ein aktiver Softwareentwickler? Ja, auf jeden Fall. Ja, mich hat das auch voll aus dem Hocker gehauen. Ich habe vorher SVN benutzt, das war die Subversion, hieß das.
Es war das de facto System zu der Zeit, da habe ich noch am European XFL programmiert, auch mit einer ganzen Gruppe. Und wir hatten unsere ganze Versionierung quasi, und das war ein zentrales System, darauf gestellt, mit den ganzen Nachteilen, die ich so hatte. Die will ich jetzt hier nicht ausbreiten, aber es war schon schmerzhaft, auch für mich, als Gruppenleiter dann drauf zu gucken und das alles zu koordinieren.
Und wir hatten auch eine mega fail kurze Anekdote. Ich habe da mal nicht aufgepasst irgendwie und in Subversion, das war auch nicht ganz so sicher gegen... Du konntest das auch richtig auseinander treten, wenn du da nicht aufgepasst hast. Das wurde in sich gerubt oder nicht gerubt vielleicht, aber so unüberschaubar mit den Commits, dass du irgendwie nicht mehr zurück und nicht vorgekommen bist.
Und ich habe tatsächlich, und jetzt kann man mal sehen, wie wichtig so ein Versionierungssystem ist, ich musste tatsächlich fast ein ganzer Monat Entwicklungsarbeit. die Becher runtertreten von meinem Team, weil wir es nicht mehr geschafft haben, aus diesen ganzen verzettelten Branches, wie man das nennt, also aus diesen Einzelanforderungen, ein gesamtes Bild zu schaffen. Wir haben es nicht geschafft.
Du kannst dir vorstellen, es wurden so viele extra kleine Kapitelchen geschrieben und wir haben es nicht mehr geschafft, es in dieses eine Buch so reinzufügen, dass das Buch halt fehlerfrei lesbar war. Also der Code funktionierte nicht mehr. Wir mussten zurück an eine Stelle, wo es noch ging. Das war natürlich mein Fehler. Aber vielleicht auch ein bisschen ein Fehler von der Technologie, weil die halt nicht so überschaubar war.
Ja, ich würde sagen, mit Git kann ja heute sowas nicht passieren, weil das lässt dich nicht dazu führen, dass du irgendwie so komplett in die... Und mein Team war natürlich mir sehr dankbar dafür, dass ich gesagt habe, jetzt müsst ihr nochmal anfangen. Entschuldigung, die letzten 20 Tage waren für den Arsch. Jetzt könnt ihr nochmal neu machen.
Ich hoffe, das passiert mir nie wieder in meinem Leben, aber lesson learned so, ja. Und das zeigt, wie komplex und wie der Prozess an sich auch schon ist, wenn man mit einem großen Team Software entwickelt und wie gut man das Tool verstanden haben muss und damit umgehen muss. Ist es denn so, dass tatsächlich, ich sage jetzt mal an einem Feature zum Beispiel, du sagst jetzt Kapitel, aber ich würde jetzt mal einfach sagen ein Feature, was irgendwas tut in deiner Software.
typischerweise an diesem Feature auch mehrere Entwickler und Entwicklerinnen arbeiten oder hat dann schon jeder seine Domäne? Und es gibt nur bestimmte Bereiche im Code, wo dann doch wieder...
mehrere zusammenkommen. Das ist total individuell. Das ist so, wie die Entwickler das Team Bock hat oder der Manager von dem Team. Und das darf überhaupt gar keinen Einfluss haben auf das Tool, was wir heute besprechen. Das muss das alles abbilden. Genau. Da kommen wir aber später zu. Ich werde das ein bisschen verschieben, dieses Thema. Es gibt natürlich... konfliktreichere Prozedere mit so einem Tool zu arbeiten als andere. Das machen wir zum Schluss.
Passt völlig, hat mich jetzt nur interessiert, weil man könnte ja auch sagen, warum hat nicht jeder Entwickler und die Entwicklerinnen einfach ein Kapitel und macht das fertig und am Ende kannst du es ganz easy zusammenbauen. Aber es gibt offensichtlich die Anforderung, dass auch gemeinsam an Themen einfach gearbeitet wird, an den gleichen Themen. Genau. Und du hast ja solche Sachen wie Pair-Programming. Manchmal hast du ein Feature, was ziemlich dick ist.
Also ein Feature kann ja was ganz kleines sein. Manchmal ist es einfach ein kleines Feature, weil man sagt, der Knopf soll jetzt noch das und das können. Das kann einer Entwickler an einem halben Tag bauen, plus Tests. Und dann hast du irgendwie ein anderes Feature, keine Ahnung, wir müssen hier das Authentifizierungssystem umstellen. Das dauert auf einmal zwei Monate und schafft gar nicht einer alleine. Feature ist ja nicht gleich Feature und Bug ist auch nicht gleich Bug.
Aber wie gesagt, lass uns das kurz noch ein bisschen verschieben. Total. Aber jetzt, gut, dann ist es 2005 und Linus Torvalds hat dann gesagt, Mensch, jetzt hier Linux-Körner lässt sich mit BitKeeper, hast du glaube ich gesagt, nicht so toll. verwalten und versionieren. Ich hau mal eben Git raus. Genau. Und dann war Git da und hat sich dann verbreitet in der Community. Ja, das ist so wie in den sozialen Medien. Das Ding ist viral gegangen. Auf der ganzen Welt, also in allem.
Ich habe jetzt gehört, dass hier und da dann... Vielleicht auch gerade da, wo eher auf Windows vielleicht entwickelt wird, vielleicht hier und da nochmal Subversion Windows wird. Ja, aber die sollten dann bitte schnell umsteigen. Okay, es gab früher Versionsverwaltungen, es gibt auch heute noch andere, aber Git ist der Branchenstandard und der Branchenprimus. Voll, ja und zu Recht. Ja und wenn man jetzt irgendwo als Entwicklerin oder Entwickler anfängt, dann sollte man das
Ja, das muss man erstmal lernen und tatsächlich ist Git und da braucht man eine Minute für und das ist, weil dieses Tool, das muss man erstmal verstehen, das ist gar nicht so einfach. Also wenn man noch nie was von Git gehört hat, ich brauchte das tatsächlich auch.
Ich kam ja aus Subversion und dann haben mir meine Entwickler gesagt, Burkhard, das geht so nicht weiter, du musst halt jetzt Git lernen, wir wollen alle Git machen. Ich sagte, okay, dann machen wir jetzt Git so und ich habe echt Schmerzen gehabt. Das ist echt schon ein Konzept-Dings. Und jetzt fangen wir mal an. Lass mal kurz verstehen, was geht ungefähr ist.
Wir müssen ein paar Glossaries machen, also das Wort Repository müssen wir mal können. Ein Repository ist quasi, kannst du dir vorstellen, wie ein Filesystem. Ja genau, da sind halt quasi die Daten drin, die du über eine Versionskontrolle verwalten möchtest. Das ist das Repository. So, und in diesem Repository gibt es sogenannte Branches, das muss man auch verstehen. Also du kannst quasi, ich glaube mal, das ist ein Buchbeispiel. Also typischerweise gibt es einen Master-Brand.
Das ist so eine Art, ja, der ist immer da. Das ist so der Hauptbranche überhaupt. Der macht halt Versionskontrolle und ein Branch ist quasi... Jeder Branch für sich macht eine eigene Versionskontrolle, kannst du so sagen. Du kannst dann immer quasi kleine Blocks in so eine Kette hinzufügen. Ein Git-Sprech ist, wenn du einen Block hinzufügst, dann machst du einen Commit.
Den Wort müssen wir auch mal sagen. Also wenn du jetzt bei Null anfängst, sag ich mal, so ein Projekt, dann hast du so einen Master-Branch. Da ist jetzt noch gar nichts drauf und dann macht man so einen initialen Commit, sagt man, initial Commit. Dann hast du also quasi, vielleicht hast du quasi eine Readme gemacht, drin steht, was planst du jetzt zu tun hier, was wird das für ein neues Projekt und dann gehst du quasi hin, schreibst deine Readme als Tag.
Und jetzt hast du ein Repository und das ist wichtig. Das Repository lebt. mit dem du sprichst, zunächst erstmal ganz lokal bei dir. Das ist die Idee. Auf deinem Rechner. Auf deinem Rechner, ja. Das heißt, du brauchst gar kein Internet, um Versionskontrolle zu machen. Das ist total wichtig. Das gibt halt auch Speed.
Du kannst erst mal ganz lokal bei dir anfangen, ja. Das heißt ja aber, jetzt fasst du mich gleich als nächstes hin, wie kriege ich dann irgendwie von Lilly irgendwie die Sachen zusammen? Lilly hat auch ein lokales Repository. Und jetzt ist die Kunst... Und jeder hat ein lokales Repository bei Git. Und deswegen kann jeder irgendwie schon mal arbeiten, jeder kann irgendwie Commits machen, also Blöcke von Code in das Repository einfügen.
Und dann gibt es ein zentrales oder auch mehrere Zentrale, ich lasse es mal gerade weg, sonst wird es kompliziert, aber sagen wir mal, es gibt ein zentrales Repository, was auf einem Server liegt in der Cloud, wo ich tatsächlich dann irgendwie mal zu einem gewissen Zeitpunkt eine Internetverbindung brauche. Denn irgendwann will ich das mal synchronisieren zu der Wahrheit, zu meinem zentralen Repository.
Und so funktioniert Git. Deswegen ist es auch am Anfang ein bisschen kompliziert, weil du verschiedene Levels hast der Synchronisierung. Wenn du deinen File editierst, und heute ist das so, dass das Git ist quasi... Das ist eigentlich ein Kommandozeilen-Tool. Das reicht auch völlig aus, wenn du das mit der Kommandozeile bedienst. Aber wie wir das so wissen, Kommandozeile, da musst du halt dich ein bisschen auskennen.
Das ist halt super geil eingebaut in alles, was irgendwie heute in Editor ist oder auch in diese Web-Oberflächen und so. Es geht quasi mit grafisch eingebaut und du kannst es halt einfach klicken. Und wenn du das jetzt benutzt, sagen wir mal, du hast also, also was passiert, du musst halt natürlich erstmal quasi, normalerweise ist das ein Ordner, du hast einen ganz normalen Ordner, auf dem Fall ist es Windows oder Linux völlig wurscht und in diesem Ordner sagst du mal git init.
Du initialisierst quasi diesen Ordner, dass du jetzt quasi von diesem Repository unter Versionskontrolle kommst. Und dann entsteht in Linux und wahrscheinlich auch in Windows ein kleiner Ordner, der ist versteckt, der heißt .git in diesem Ordner. Und da steckt die ganze Magic drin, ganz lokal. Und es ist quasi eine Datenbank drin, die quasi dann, wie ich es gesagt habe, die quasi blockartig trackt, was hast du verändert.
Und wenn du jetzt einen coolen Editor hast, wie zum Beispiel Visual Studio Code, Und du schreibst dann was, dann ist das schon direkt grün an einem Pfeil oder rot oder mit Farben markiert. Ist das ein neues Pfeil, was ich noch nicht kenne? Das muss also neu eingepflegt werden im Repository. Ist das ein Pfeil, wo ich drunter rumeditiert habe? Dann siehst du das schon. Dann siehst du da irgendwelche roten Markers.
Und weil das so cool integriert ist, kannst du dann auch draufdrücken auf die roten Dinger und dann siehst du direkt, wie sah es denn vorher aus. Also das macht gleich so eine Live-Veränderung, so eine Vorschau. Kennt man auch schon so ein bisschen von Word und so, aber das ist halt mega cool integriert.
sodass du immer genau siehst, was hast du hier gemacht. Und wenn du aus Versehen mal was, wenn, ich sage mal, so ein Mann kommt, du hast gerade nicht geguckt und der tapselt auf deiner Tastatur rum. und verschwindet wieder. Dann setzt du dich an den Rechner und siehst gleich so einen roten Balken an der Seite, dass da was modifiziert wurde. Dann alarmiert dich schon das System, dass da hier irgendwie Käse... Das ist mir gestern passiert.
Frederik hatte Papa arbeiten. Wollte mitarbeiten. Wollte mitarbeiten. Ich war gerade irgendwie draußen, weil ich habe noch eine Tochter, nach der habe ich geguckt und hatte gestern die Kinder alleine.
Und in der Zeit, wo ich nach der Tochter guckte, ich hatte meinen Rechner nicht gesperrt, muss man immer machen, gerade wenn man Kinder hat, sehr wichtig, nicht nur im Büro. Tippste der auf der Tastatur rum, hat direkt mal den Code editiert. Und da hat mir Gitter war auch gleich wieder geholfen und gesagt, okay, das ist ja neu und anders.
Du, ganz kurze Zusammenfassung, bevor du jetzt noch weitere Begriffe reinhaust. Also das Repository oder ich glaube Repo, dann häufig auch umgangssprachlich genannt, gibt es lokal bei jedem beteiligten Entwickler oder Entwicklerin? Plus es gibt dann diesen Master oder Main, der irgendwo zentral ist.
Ne, Vorsicht, der Master ist der Branch, den haben sie ja auch alle. Also die alle Branches sind auch quasi, ist alles dupliziert. Es gibt das Main Repository. Okay. So aufpassen, dass wir vorsichtig sind mit den Begrifflichkeiten. Das Repository, das Repository. Hält beliebig viele Branchen.
Und hält quasi das gesamte Konglomerat von allem, was ich versionieren werde. Ich sage zu den Branches gleich noch was. Aber dieses Repository gibt es einmal zentral und für jeden Mandanten, der irgendwie teilnehmen will an diesem... Okay, ein Repository managt typischerweise ein Softwareprojekt, ein Produkt, ein irgendwas auch immer. Richtig, genau.
typischerweise hat man für ein geschlossenes Softwareprodukt. Und dann hast du die ganzen Branches und dann gibt es irgendeinen Flow, einen Prozess, um diese Branches dann wieder zusammenzubringen. Und das ist dann wahrscheinlich der nächste Schritt. Ja, pass auf. Genau, also du kannst...
Normalerweise hast du einen Master-Branch und jetzt gibt es verschiedene Modelle. Das ist ja alles beliebig, was du damit machst. Ich nenne mal das Modell, was ich immer nutze. Es gibt ganz viele andere noch. Das hat auch einen Namen, den ich gerade vergessen habe. Das ist der Feature Branch Workflow. Ich habe hier gerade gespickt. Ich habe es Gott sei Dank noch vor mir gehabt hier auf dem Shop.
Man sagt zum Beispiel, der Master-Branch, der ist immer die Wahrheit. Das ist der aktuellste Stand der Entwicklung. Der wird auch manchmal Main-Branch genannt heute, aus politisch korrekten Gründen, weil Master aus der Zeit von Masterns Letztes. Ich glaube, man hat sich wieder zurück besonnen auf Master, weil man schon weiß, dass... Aber das ist quasi der Haupt-Master-Branch, wo die ganze aktuelle Entwicklung stattfindet.
Und jetzt kann man sich überlegen, wie kriege ich das jetzt gebacken alles? Wenn ich zum Beispiel, und ich mag das Beispiel, also was haben wir eigentlich meistens zu tun? Entweder entwickeln wir einen Feature oder wir fixen einen Bug. In meiner Welt mache ich mir das so einfach. Also alles, was an der Software, an Veränderung passiert, ist entweder ein neues Feature oder ein Fix von einem Bug.
Und wenn ich jetzt einen Bug fixen möchte, jetzt könnte ich ganz naiv sagen, okay, dann nehme ich jetzt halt den Master-Branch, der quasi synchronisiert ist über alle. Fange an, am Masterbranch-Code zu editieren und mache einen Commit, also schicke diese Veränderung direkt auf den Masterbranch.
Ansonsten ist das eine schlechte Idee. Weil wenn ich jetzt zum Beispiel mit dir arbeite, Gerrit, und wir haben jetzt beide ein Feature und du entwickelst ein Feature, ich fixe einen Bug. Und blöderweise... muss ich, um den Bug zu fixen, auch an Code-Stellen ran, die in deinem Feature vorkommen. Und jetzt bin ich etwas schneller als du. Du entwickelst dein Feature da und ich fixe einen Bug.
dann ist das ziemlich doof für dich, weil du dann irgendwie, wenn ich den dann jetzt quasi in den Masterbranch im zentralen Repository gespielt habe, bist du quasi out of sync. Dann ist die echte Wahrheit im Masterbranch schon eine neue. während du da dein Feature machst auf einer alten Version des Masters.
Weil ich diesen Master vorher zu mir rüber kopiert habe und das dann mein Branch ist, in dem ich arbeite. Genau, das muss ich vielleicht noch sagen. Das war für mich auch so ein Aha-Erlebnis. Also dieses ganze Git-Kram, das funktioniert tatsächlich in dem Ordner und dieses Git selber. sorgt dafür, dass die Dateien in dem Ordner sind, tatsächlich sich ändern.
Also direkt on the fly, in diesem Ordner. Also man sagt zum Beispiel ein Checkout. Ein Checkout ist quasi eine Kopie an einer gewissen Stelle eines Branches. Wenn du jetzt angefangen hast, einen Peacher zu machen, dann würdest du quasi den Master auschecken an der Stelle, wo er ganz aktuell ist, also am letzten Commit. Warum solltest du auch eine alte Version, du willst ja nicht auf einer alten Version dein Feature entwickeln. Und dann passiert tatsächlich, dass die ganzen Pfeils um dich rum
Die sind dann so verändert, dass sie genau diesem Stand entsprechen. Was du aber auch, was du machen könntest, geht einfach nur aus Spaß. Du könntest quasi einen Checkout an einer beliebigen anderen Stelle machen, an einer älteren Stelle zum Beispiel von diesem Master Branch. Und was dann passiert,
ist dann unter deinem Hintern werden die ganzen Files geändert, sodass sie wieder spiegeln den Status zu einem alteren Zeitpunkt. Das passiert immer alles auf dem gleichen, also da werden nicht mehrere Ordner nebeneinander angelegt, so Subversion-mäßig, da musst du das alles in verschiedenen...
Ändert einfach deine Files unter dir. Und du kannst dann auslesen mit Git, was zeigt es denn da gerade an? Wo bist du gerade? Und wenn wir das jetzt ordentlich organisieren wollen, und das sage ich nur heute, das funktioniert normalerweise so. Du hast den Masterbranch und wenn ich jetzt den Bug mache, dann gehe ich hin, dann muss ich erstmal dafür sorgen, dass mein lokaler Masterbranch, den gibt es bei mir lokal auch nochmal, erstmal synchron ist mit dem jetzigen...
Das nennt man, da mache ich ein sogenanntes, da mache ich ein Git-Fetch, sagt man. Also Fetch heißt, ich hole mir erstmal alle Informationen vom zentralen Repository runter, dass die da sind. Bei mir lokal, das ist dann quasi die Synchronisation. Und dann sage ich Git Pull, dann gehe ich quasi selber lokal auf den Master Branch und sage Git Pull.
Und dann zieht er quasi von dem zentralen Repository alle Informationen in mein lokales rein. Und dann bin ich erstmal mit dem Master-Branche synchronisiert. Und wenn ich das habe, dann mache ich einen neuen Branch. Also quasi, ich fange quasi eine neue Entwicklung. Im Branch kann man sich wirklich so abstellen, wie so ein Zweig. Also wenn der Master irgendwie so eine Linie ist mit...
Und dann sind das mal Punkte normalerweise dargestellt. Punkte sind quasi Reinspielung, neue Commits, also neue Blöcke von Änderungen in den Code, ja, Punkt, Punkt, Punkt, Linie, Linie, Linie. Und dann sage ich jetzt, okay, jetzt mache ich einen Bug, jetzt zweige ich ab.
Jetzt zweige ich ab nach unten quasi von der Linie, nenne denen, die haben immer einen Namen, diese Branches, also Master heißt ja Master und dann mein Bug-Branch heißt typischerweise so, wie dieser Bug ist, irgendwie, was weiß ich. Das Ausloggen da bei uns zum Beispiel, ja. Ja, genau. Fix Lockout Issue oder irgend sowas. Und der hat normalerweise auch eine Nummer und so. Das muss nicht, aber das verwaltet man ordentlich. So, und jetzt kann ich ganz in Ruhe diesen Bug fixen.
Und mache das so, ja. Und bin quasi auf einer parallelen Spur unterwegs. Und du hast zu der gleichen Zeit irgendwann gesagt, hier, mein Master, Pult und so weiter. Und du hast den Feature-Brand. erstellt, an einer bestimmten Stelle vom Master. Und es ist auch quasi in den Seiten, also auch quasi runtergebrancht und dann machst du deine Entwicklungen. Und jetzt können wir die unabhängig voneinander machen.
Du bist erstmal nicht gestört und jetzt kurz bevor du fertig wirst, macht man es meistens so, dass man sagt, so jetzt muss ich erstmal gucken, bevor ich das jetzt irgendwie blind in den Master reindonner, musst du jetzt nochmal... Deinen Branch mit dem Master synchronisieren. Das ist aber wieder eine private Sache für dich. Das heißt, du wirst jetzt hier fertig mit deinem Feature. Ja doch, genau, du hast das Feature gemacht. Dann sagst du, okay, jetzt spiel mir mal.
den neuen Master rein in meinen Code. In diesem neuen Master ist unter Umständen noch gar nicht drin, was du gefixt hast. Nee, aber der kann genauso aussehen wie vorher. Vielleicht hat keiner gearbeitet, dann hast du es einfach, dann musst du dich um nichts kümmern. Dann sagt dir, nee, ist alles auf Stand. Perfekt, Gerrit, alles prima.
Oder, und das Git sagt dir das alles. Oder Git sagt so, ja, hier sind irgendwie zwei, drei, vier, fünf Commits auf dem Master zwischendurch eingegangen von deinen Mitentwicklern. So, und die spielen wir dir jetzt mal ein. Und jetzt kommt... Das kann im schlechtesten Fall für dich schlecht sein.
Weil es kann ja sein, dass jemand rumeditiert hat, ohne dass du wusstest, auf Files, die du jetzt selber bespielt hast. Und auf einmal funktioniert es nicht mehr so, wie du gedacht hast. Und im schlimmsten Fall ist es sogar ein Konflikt. Und es kann auch Git dir nicht helfen, wenn du mit jemandem anders genau an der gleichen Zeile, Code, an der gleichen Stelle jetzt verschiedene Ideen hast, was da stehen soll. Dann ist das ein sogenannter Konflikt. Den muss man manuell lösen.
Und zeigt dir es aber an. Da steht dann hier, Gerrit, hast du das editiert? Und Lilly hat irgendwie das andere editiert. So, was willst du denn jetzt haben? Das von Lilly? Oder das von dir? Oder was ganz Neues? Irgendwie ein Kompromiss dazwischen? So, und jetzt musst du mit Lilly ein bisschen kommunizieren. Hilft nix, ja. Als Entwickler muss man dann ein bisschen kommunizieren an der Stelle. Und rausfinden, wie kriegen wir denn das jetzt hin, dass beides noch funktioniert.
So, um alles dieses transparent zu machen, brauchen wir eine Versionskontrolle. Und jetzt kommst du noch mit deinem Back und gleiches Prinzip. Gleiches Prinzip, ich werde mit meinem Bug fertig, dann muss ich auch meinen Master quasi erstmal synchronisieren. Und jetzt gibt es da auch noch zwei Wege, ich erwähne das nur, den Git ist wirklich kompliziert. Ich habe ja gerade am Anfang von Blockchain gesprochen, es ist ja auch nicht so, dass man Blockchain irgendwie...
in einem Atemzug versteht. Und dann auch noch die Flos sind echt kompliziert. Jetzt kann ich mir halt auch noch überlegen, wie ich das mache. Es gibt bei Git zwei Möglichkeiten. Das sogenannte Rebasing und das Merging. Also ich kann quasi dann sagen, okay, ich merge meine Änderungen quasi. mit den vorherigen Sachen zusammen. Und dann gibt es einen neuen Commit. Und die Commits haben immer so eine ID. Das ist quasi der kryptografische Schlüssel. Das ist so eine Hash.
Oder ich rebase und das rebasen heißt quasi, das will ich auch nochmal kurz erklären, das ist ganz schick, das machen wir nämlich hier immer und das habe ich von einem, ich habe das früher nicht so gemacht, das habe ich, ich kann den Namen mal erwähnen, Christian Stimming gelernt, ich würde sagen, der hat den schwarzen Gürtel in Git, Karate. Weil beim Rebasin, was da passiert, ist quasi die einzelnen Änderungen.
die jetzt zum Beispiel am Master vorgenommen wurden, während ich meinen Bug gefixt habe. Und die habe ich gar nicht mitgekriegt erst. Da kann ich sagen, okay, pass mal auf, linearisiere die Reihen, also spiele die zu dem richtigen Zeitpunkt einfach so rein, als hätte ich die gemacht. In meinen Branch. Das heißt, da wird nichts gemerged, sondern es bleibt quasi von der Historie lineare Punkte.
Aber die werden quasi an der richtigen Stelle retromäßig reingefügt. Und diese ganze Kette wird wieder neu aufgebaut. Das ist ja irgendwie noch, hört sich jetzt noch synchroner an irgendwie. Ja, es ist halt schick, weil es halt dann bleibt quasi, wenn du dann später auf deinen Masterbranch guckst, dann sieht es so aus, als hätten alle einfach sequenziell tak, tak, tak neue Commits gemacht.
Dieses Zeitgleiche und ineinandergeschobene wird dann quasi durch das Rebasen aufgelöst und du kannst dann später, wenn du von außen guckst, diesen Master Branch lesen und der hat halt zu richtigem Zeitpunkt immer die richtigen Einfügungen gemacht. ziemlich schick, das machen wir auch. Das ist noch feinteiliger am Ende.
letzten Endes auch die Historie deines Codes. Ja, genau. Die Historie ist klarer. Du hast nicht diese Merges, weil die Merges beinhalten ja wieder Veränderungen von anderen und so weiter. Und so kannst du halt immer genau sehen, welche Nase hat was, wann, wie irgendwie da in diesen Master da irgendwie reingehängt.
Also Rebasing, sagtest du? Rebasing heißt das. Merging oder Merge sind die zwei. Genau. Man kann beim Rebasing quasi, man kann es wirklich so verstehen, als würdest du schon Commits, die du in der Kette hattest. wieder auflösen, die Kette quasi und das kurz in der Hand halten, dann die Änderung an den richtigen Stellen, die von anderen kamen, rein spielen und deine Änderung wieder rein fügen. Also du brichst einmal die Kette ab, bist du der Stelle, wo es noch synchron war.
Und dann würfelst du das neu und bringst es in der richtigen Reihenfolge wieder zusammen. Das nennt sich V-Basic. Jetzt hätte ich noch eine Frage zu Git, bevor wir dann vielleicht zum nächsten Punkt dann auch kommen und weitergehen. Verstehe ich das so, dass dann jede Menge Merges oder so? Rebasing passiert und dann irgendwann entscheidet mal jemand, jetzt gibt es einen Release.
dieses Masters wieder und eine neue Softwareversion wird irgendwie veröffentlicht. Richtig? Also das ist dann auch beliebig irgendwann oder es wird vorher festgelegt, wann das ist. Also ist jetzt nicht Kernthema, aber irgendwann muss das ja passieren. Das ist eine gute Frage. Da habe ich noch gar nichts zu gesagt. Und du fragst dich, wie funktioniert das jetzt irgendwie in diesem Bild?
Ja, genau. Wie funktioniert das in dem Bild oder wie wird das typischerweise auch gelöst in Teams? Also bei dem Flow, den ich gerade besprochen habe, bei diesem, also... der Feature-Branch-Workflow, wo du quasi einen zentralen Master hast und immer die Bugs und die Features ausbranchen und wieder reinbringst. Du gehst mal raus und wieder rein, raus und wieder rein. Da funktioniert ein Release so, dass quasi auf dem Master-Branch
Da laufen übrigens die ganzen, ich mache mal kurz ein CICD und so weiter. Ja, das muss man jetzt nicht im Detail. Nicht im Detail, aber die passieren auf dem Master-Branch. Also immer, wenn der Master-Branch quasi einen neuen Commit-Bobble erhält, eine Änderung erfährt, dann wird quasi im besten Falle automatisiert, alles Testgedöns drumherum angeschmissen und auf dieser neuen Version des Masters wird die ganze Software getestet.
Und sagen wir mal, jetzt ist alles toll und der Scrum Master oder der Chef oder irgendwer entscheidet, jetzt müssen wir mal einen Release machen. Was man im besten Falle immer machen kann, das ist das Schicke an diesem Flow. Weil dein Master, wenn der ständig durchgetestet ist, Und wenn diese Prozesse des neuen Code-Einfügens, habe ich noch nichts gesagt, auch so einem Review-Prozess unterhalten, dann heißt es quasi, die Software, die dahinter steht, ist immer releasefähig.
Es ist einfach nur eine Entscheidung, eine politische Entscheidung, wann sage ich, ich mache das Release. Wie viele Features und Bugfixes fasse ich zusammen, die es mir wert sind, in einem neuen Release zu erscheinen. Das ist dann nur noch ein Politikum, aber kein Technikum. Das ist wichtig. Wenn jetzt ein Rallys passiert, dann gibt es ein neues Wort, das habe ich noch nicht erwähnt, das ist ein sogenannter Tag.
Also ich habe jetzt von Branches gesprochen und von Commits gesprochen und so weiter. Und ein Tag ist quasi auch ein Commit. Also quasi auch so ein Bobbel auf dieser Linie mit einem Namen. Und dieser Tag-Name ist dann quasi der Name des Releases. 1.2.4 oder so zum Beispiel. Und damit setze ich einfach nur einen Zeitstempel, damit ich da auch zurückverfolgen kann, wie sah der Code genau aus bei diesem Release. Total wichtig. Und auch dieser Tag, diese Bobbel, ist quasi auch dann...
Stelle, wo ich dann branchen würde, denn jetzt wird es ja noch komplizierter, das haben vielleicht unsere Zuhörer gar nicht so auf dem Zettel, aber es ist halt so, wenn ich zum Beispiel mehrere Versionen einer Software maintaine, wie man so schön sagt, Also ich habe vielleicht eine Version 2,x und eine Version 1, für die, die noch nicht zu 2 migriert sind.
Ich habe ja aber Bugs auf beiden. Und wenn ich die also maintaine, dann muss ich ja quasi für beide Versionen gleichzeitig Bugs fixen und das alles sauber managen. Und auch dieser Tag, den ich dann setze, der erlaubt quasi auch nochmal einen Branch zu machen. Das wäre dann kein Feature- oder Bug-Branch, sondern das ist dieser eine andere Branch, den ich erlaube, in diesem Flow zu entstehen, quasi um das Release...
weiterzuentwickeln, ein altes an dieser Stelle. Davon sollte man nicht zu viel haben, weil das ja mega aufwendig ist fürs Team. Also am besten ist, wenn man 100 Kunden hat, sollten die im allerbesten Fall auf der gleichen Version sein. Ja, im allerbesten. Aber wir wissen ja, wie es ist. Ja, wir wissen, wie es ist, genau. Aber ich habe immer gesagt, damit kommt man durch eigentlich als Software. Ich habe immer gesagt, so allerhöchstens zwei Versionen. Okay. Aber selbst dafür bietet...
geht noch technische Lösungen an. Total. Aber der Aufwand steigt. Der Aufwand steigt, weil man kann auch immer zwischen Branches hin und her diese Dinger verschieben und so, aber man kann sich vorstellen, wenn ich das jetzt so erzähle, Also du fixst zum Beispiel einen Branch in der allerneuesten Version, im Feature 2, und dann denkst du dir so, den hatten wir garantiert in 1 auch. So, und jetzt willst du diesen Fix quasi rückwärts rein spielen in Version 1.
Da ist aber schon deine ganze Umgebung anders, weil alles anders ist. Jetzt musst du da ziemlich aufpassen, das händisch da einfügen und so. Das kannst du nicht einfach die Code-Änderung darüber spielen und so. Jetzt merkt man dann, was das für ein Aufwand ist. Also Softwareentwicklung und dieses ganze Maintain von dem Kram und als Softwareanwender erwarte ich, dass alles schön funktioniert. Im Hintergrund.
ist das ein hochkomplexes Projektmanagement-Problem. Es gibt es bestimmt in anderen Bereichen auch und deswegen ist es vielleicht auch ganz spannend für andere Bereiche, aber es hat sich halt vor allen Dingen bei der Software durchgesetzt, weil das echt... Wenn man darüber nachsiniert, was da alles passieren muss und was ich alles richtig machen muss im Team mit mehreren Versionen, mit Bugs und gleichzeitig in Asynchron und so, das ist schon relativ komplex. Ja, ja.
Okay, du auch in Anbetracht der fortschreitenden Zeit, würde ich dann dich erst fragen, gibt es noch was Wichtiges zu dir hinzuzufügen? Ansonsten lass uns kurz über die gängigsten Plattformen, dass wir die mal anreißen. GitHub und GitLab und die haben ja irgendwie auch Git im Namen schon und es gibt auch noch Bitbucket und ich habe nochmal geschaut und Sourceforge und diverse andere Plattformen, die wahrscheinlich dann irgendwie dieses Open Source nutzen und wiederum noch mal
Also dafür sorgen, dass man sich selbst hosten muss, nehme ich jetzt mal an, und selber aufbauen muss, sondern einfach eine Plattform nehmen kann, die wieder cloudbasiert ist. Ich watsche das mal in einem Satz ab. Alle diese Tools sind im Prinzip Webplattformen, die genau das tun, was du gesagt hast, Gerrit. Die sorgen dafür, dass dein zentrales Repository ...
gehostet wird und transparent anschaubar wird, indem da eine Web-Funktionalität drum herum gebacken ist. Und du kannst dir dann genau angucken, was ist da los. Und die erlauben, also die basieren alle auf dem Git unten drunter.
Und das hatte auch Linus Torwald schon so vorgesehen, hat gesagt, ich mache hier nur ein Tool, was quasi die Technik kann, da gibt es keine UI zu und es soll einfach sein, für alle möglichen Leute ganz tolle Oberflächen dazu zu machen, um das zu bedienen. Und das sind sie alle in ihren Varianten.
Einer so, der andere so. Und es gibt halt quasi diese ganzen Tools. Dafür gibt es halt welche, die sind besonders dafür da, dass du quasi dein zentrales Repository, gegen die, die alle managt. Und dann gibt es viele andere. Grafische Tools auch, ich hatte die schon mal die Editoren genannt, also die IDEs selber, die haben das halt auch.
Die liefern dir die UI, die Transparentmachung für die verteilten anderen Repositories, also für die lokalen Repositories, mit denen du entwickelst und die Codesachen änderst. Und alles ist voneinander völlig unabhängig und du kannst das wild miteinander kombinieren, weil es einfach nur Grafik über immer das gleiche Git unterliegende Kernsystem ist. voll schön so. Es funktioniert einfach herrlich, ja. Aber jetzt könnte man auch, wenn man jetzt ganz...
besonders nerdig ist oder ganz besonders, das mag, sich dann selber irgendwie aufsetzen. Voll. Ja, klar. So haben wir das am Anfang gesehen. Ohne UI benutzen wir. Ohne UI, ganz genau. Du brauchst nichts. Das ist auch total schmal und richtig effizient. Wir brauchen kaum Speicher, es ist total schnell. Es ist gemacht mit einem Befehl. Du brauchst halt einfach einen Server, der irgendwo zentral erreichbar ist.
Mit einem Befehl hast du deinen Repository dargestellt. Ich denke mal, dass dann auch GitHub und GitLab und so dann doch noch wieder einen Tick mehr hier und da unterstützen und noch einfacher viele Dinge machen. Je größer das Team wird, desto eher würde man dann vielleicht auch wieder darauf...
Ja, voll. Es ist nicht zu empfehlen heutzutage, das ohne UI zu machen. Warum auch? So kann ich jetzt vielleicht sagen, so kann sogar ich ja beisteuern. Zumindest kann ich ja bei uns im Repository oder im GitHub... Bugs anlegen. Oder einen neuen Feature-Request reinschreiben und den du oder jemand anders aus der Entwicklung dann eben aufgreift und weiterverfolgt.
Ich will noch ein wichtiges Konzept sagen, wofür auch gerade diese Web-Oberflächen sehr gut sind und wo sich vielleicht auch die Spreu vom Weizen trennt, obwohl die mittlerweile, muss ich sagen, früher war es vielleicht noch krasser unterschiedlich. Heute sind die alle sehr, sehr gut. Das Reviewing ist ein wichtiger Punkt. Das habe ich noch gar nicht erwähnt. Habe ich weggelassen. Aber jetzt, wir nehmen nochmal kurz den Faden auf von du bist fertig mit deinem Feature, Gerrit.
und hast auch sauber den Master synchronisiert, alles ist fertig, technisch, dass dein Feature quasi wirklich in den Master... rübergehen kann. Dann wird quasi dein Feature-Branch gerebased oder gemerged, je nachdem, im besten Fall gerebased und gibt quasi eine neue Bobble in den Master. Also ein neuer Block wird quasi angehängt an die Entwicklungskette des Masters bis dahin.
Das könntest du jetzt machen. Bumm und fertig. Dann ist es verändert. Das wäre aber dann krass, da hätte ja gar keiner drauf geguckt. Weil bis jetzt hast du lokal gebrancht, hast du das gemacht. Hast vielleicht irgendwie mit jemandem gesprochen oder auch nicht. Und wenn du jetzt das einfach da reinknallen würdest, dann hättest du quasi dieses Buch, was entsteht, das Softwarebuch, verändert, ohne dass jemand Mitsprache gehabt hätte. Das passiert typischerweise nicht in der Software.
Sondern jetzt passiert quasi in dem Moment, wo du technisch fertig bist, es mit dem Master quasi zu verheiraten, deine Änderung, passiert ein Review-Prozess. Das heißt, jetzt kommt normalerweise ein anderer Entwickler mit ins Spiel. Das machen die Tools jetzt ziemlich toll. Da kannst du dann quasi sagen, bitte, liebe Lilly, ich bin jetzt hier fertig mit meinem Feature, kannst du da bitte mit drauf schauen? Kannst du das mal reviewen? Macht das Sinn? Habe ich hier irgendwo noch einen Fehler?
Kannst du dir das angucken. Und dann kann Lilly quasi sich auf, sie nimmt dann quasi lokal, sie macht dann wieder ein Fetch, sodass sie alle Informationen hat, die du mit dem Master synchronisiert hast, hat sie auch alles da. Und dann kann Lilly sich ja auch auf deinen... auf deinen Feature-Branch setzen Sie checkt den aus, dann hat sie alles so, wie du es sehen würdest.
und kann quasi den Code durchgehen, so wie du ihn vor dir hast. Und diese Tools wie GitHub und so weiter, die können das sogar im Web machen. Das heißt, Lilly muss das gar nicht mehr zu Hause machen bei ihr. Sie kann dann quasi diesen Review-Prozess auch auf der Web-Oberfläche machen, was ziemlich... was ziemlich elegant ist, weil ich dir gesagt habe, wenn du jetzt quasi dich hinsetzt auf einen anderen...
Branch auf einen anderen Kommit, dann wird ja quasi deine ganzen Files, die du hast, während du entwickelst, werden neu hingeschrieben, sodass sie dementsprechend, wie der Status ist. Jetzt kann es ja aber sein, Lilly ist mittendrin im Bugfix und hat drei oder vier, fünf Files modifiziert und angefangen. Alles, was sie jetzt nicht will, ist, dass sie das alles wegspeichern muss kurz. Dann kriegt sie eine ganz andere Codebase vor die Nase.
weil sie dann ein Review machen soll und dann wieder alles zurück. Da hat sie vielleicht überhaupt gar keinen Bock drauf. Habe ich auch oft keinen Bock drauf. Und dann ist es cool, das einfach im Web zu verhandeln. Dann geht halt, Lilly lockt sich halt auch mit ein in GitHub so und dann sieht sie quasi in GitHub schon diesen Review-Prozess. Und da sind dann einfach zwei Fenster, da sieht sie genau, was hat der Gerrit hier gemacht und da gemacht und dann könnt ihr quasi auch...
Da gibt es natürlich eine Chat-Funktion. Dann kann sie mit dir sprechen und sagen, Gerrit, warum hast du das gemacht? Und du antwortest das. Und dann wäre das so, wenn Lilly einen validen Änderungswunsch hat, dann würdest du sagen, okay, cool, das füge ich noch ein. Und dann machst du halt in deinem Feature-Branch noch 1, 2, 3, 4, 5 Commits, bis Lilly glücklich ist. Dann ist Lilly glücklich und gibt ihr okay, approve.
Und wenn das so ist in der Firmenpolitik, dass Lilly das entscheiden darf und ihr beiden seid glücklich, dann passiert der Commit in den Master. Und dann werden nochmal alle Tests angeschmissen und dann ist alles prima. So ungefähr. Könnte aber vielleicht sogar noch eine dritte Instanz wieder sein, die dann den finalen Commit noch... Ja, also das ist beliebig, wie kompliziert man dieses Review macht und wer da drauf gucken muss und wer da einen Proof geben kann und ob man das sogar technisch...
Du kannst das alles machen, du kannst sagen, du darfst das gar nicht, ich verbiete dir das Gerrit, erst wenn da grüne Licht leuchtet von vielleicht noch dem Senior oder irgend sowas, dann darfst du. Also das ist dann, das habe ich gesagt am Anfang, das hat mit Git an Technologie nichts mehr zu tun, das sind die Prozesse da drumherum. Und die erweitern halt diesen...
Diese Grundfunktion von Git, um alles, was Teamprozesse, Sicherheiten und so weiter angeht. Und das ist sicherlich sehr unterschiedlich. Ich glaube, mit der Größe der Firma muss man da auch tatsächlich andere Prozesse machen. Also bist du klein, kannst du es ein bisschen einfacher und schlanker halten, wie es im echten Leben ist. Da bist du eine Riesenfirma.
musst du da garantiert mehrstufige Review-Prozesse und so alles etablieren. Geht aber alles. Ja, dann opferst du Geschwindigkeit für vielleicht noch höhere Qualität und von 99,99 auf
Komma 999 zu kommen oder wie auch immer. Ja, das stimmt. Der Prozess bringt dir leider auch noch nicht die Qualität. Wichtig ist, dass die, das ist auch so ein Lesson learned, jetzt ein bisschen was Philosophisches, aber Wenn du im Team arbeitest, dann, die Entwickler denken ja meistens, sie werden daran gemessen, wie viele Features und Bugs. Sie selber fixen oder programmieren.
Das ist leider aber nur Teil der Aufgabe. Wenn du ein guter Entwickler bist, dann musst du halt vor allen Dingen reviewen. Also du musst halt einfach ganz viel Zeit haben vom Management bekommen, um ordentliches Review zu machen. von deinen Kollegen. Und das darf man überhaupt nicht unterschätzen. Das ist nämlich viel schwieriger, den du selber nicht geschrieben hast.
auf Ordentlichkeit zu überprüfen, als selber ordentlich einen Code zu schreiben. Verstehe. Weil wir Menschen haben ja einfach unterschiedliche Gehirne und Ideen. Du musst erst mal verstehen, was ist da los. Und dann musst du... Du hast dich ja dann wochenlang damit beschäftigt und hast dich irgendwie mit allen Cases, die da passieren können und so weiter, geschafft.
Aber wenn ich jetzt ein Review machen soll, und das soll im besten Fall nur ein paar Stunden dauern, dann muss ich ganz schnell schaffen, alles auf die Platte zu laden. Alles, was wichtig ist drumherum. zu sehen und zu verstehen, was du da tust und ob das gut ist oder nicht. Das ist eigentlich die höchste Kunst, schnell ein sehr gutes Review zu machen, was auch noch objektiv ist.
Und das ist auch noch was ganz Krasses, das muss ich auch nochmal an dieser Stelle sagen. Und da ist gute Software-Teamführung wirklich essentiell. Das ist ja auch ein hochemotionales Thema. Denn wo in der Arbeit werden wir, also als Softwareentwickler bist du ja so transparent. Durch diese Review-Prozesse läufst du die ganze Zeit mit runtergelassener Hose rum. Und jeder kann drauf gucken. So ist es wirklich.
Und wenn dann auch noch der Kommentar kommt, nee, es sieht irgendwie komisch aus, dann bist du erst recht irgendwie angefressen. Denn ein Review heißt ja, man gibt Kritik auch ab. Also wir machen das ja nicht nur, um zu sagen, boah, sind das schön.
gemacht. Oh, awesome, die Stelle, eleganter Code. Sondern da kommt ja eher sowas wie, raff ich nicht, verstehe ich nicht, was soll das? Das musst du mal umprogrammieren, das geht hier schief und das ist noch kacke, wo ist die Exception gefangen? Hier und so weiter.
Und du hast ja mit Schweiß deines Angesichts das hinkodiert und dann kriegst du noch Kritik dafür. Dafür, dass du auch schon irgendwie überstunden gearbeitet hast. Und da muss man dann halt gucken, dass man das auf einer emotionalen Ebene... Also von der emotionalen Ebene wegbringt und eine ganze Sachlichkeit da reinbringt und auch dieser ganze Review-Prozess, also auch das Wording, also wie schreibe ich das und so weiter.
mit ganz viel Höflichkeit verpackt. Das ist extrem wichtig und das ist, finde ich, Aufgabe des Teamleiters der Softwareentwicklung. da entsprechende Policies durchzusetzen und zu sagen, jetzt passt mal auf, ihr Lieben, hier wird ein ganz, ganz freundlicher Ton angeschlagen. Ansonsten gibt es hier sofort mal eine Abmahnung.
Kann man sich nicht vorstellen, aber das entwickelt eine Eigendynamik in der Gruppe. Ich habe das alles erlebt. Die haben sich da wie die Wahnsinnigen den Kram, also bei so einem Review, das ging rechts und links mit dem Chat. Da glaubst du, du dich tritt ein Pferd. Und dann hassen sich die Entwickler. Wenn die sich hassen, werden sie ein Buch schreiben sollen, dann ist das alles nicht gut.
Cool, dass du da... Ein bisschen Philosophie am Schluss so, aber ja. Ich glaube, das ist ziemlich wertvoll, ja, weil wer weiß, wir haben ja jetzt nicht, wir haben ja zum Teil, aber ja nicht zum Großteil. Entwicklerinnen und Entwickler auch hiermit Die zuhören, ja, und dann ist das ja coole Managementlehren, die man auch mitnehmen kann. Ja, genau, und für alle Manager, die zuhören, bitte.
beachten. Die jetzt noch zuhören. Du wolltest noch mal die Brücke schließen oder den Bogen schließen, sagt man glaube ich, zu Blockchain. Du hast es schon erläutert, bei mir hat es sich in meinem Kopf schon zusammengepuzzelt. Genau, also Git an sich von der inneren Struktur ist wie eine riesige Blockchain. Blockchain deswegen, weil du auch nicht, also Commits, die du mal gemacht hast, kannst du nicht manipulieren.
Weil der nächste Hash, also Hash ist ja die Commit-ID quasi. Also jeder Commit, quasi jede Änderung deines Codes wird quasi, da ist natürlich der Content, die Änderung selber mit drin und es wird versiegelt mit einem sogenannten Hash-Wert. der sich aus dem davorigen ergibt. Und deswegen kannst du quasi die Kette nicht manipulieren, ohne dass jeder das sofort mitkriegen würde, weil sich mich dann alle Hashes ändern. Eines der fundamentalen Grundgedanken, wie eine Blockchain funktioniert.
Und eigentlich, es gibt noch viel krasser als jetzt so eine normale Blockchain, weil wir auch noch ganz viele Ketten haben. Wir haben die lokalen Ketten, wir haben Zentralketten, die verschiedenen Branches und so weiter. Und alles das muss irgendwie gemenagt werden ineinander, diese ganzen Commits, also die Blöcke in der Chain, die fliegen irgendwie hin und her und so. Und trotzdem bleibt aber alles sauber und nachvollziehbar.
Deswegen ist das schon ein ganz schön cooles Beispiel. Wir machen vielleicht schon die nächste Folge mal über Blockchain oder die übernächste. Und dann bringe ich das alles zusammen, wo noch die Unterschiede sind. Aber da werde ich auch nochmal auf Git irgendwie Bezug nehmen. Vielleicht auch erst in zwei bis drei Wochen mal gucken, weil wir haben schon eine kleine Planung für den. Stimmt, richtig. Aber Blockchain wird kommen, so viel sei versprochen.
Cool, alles klar. Ich würde den Sack zumachen. Ich habe bestimmt was Wichtiges vergessen, aber das macht nichts. Ich glaube, wir haben ein bisschen eine Ahnung gekommen. Kann man auf Discord dann lesen. Ja, klar. Weißt uns gerne drauf hin, wie immer. Entweder ein Podcast at heisenwehr.com. als E-Mail-Adresse oder eben noch Discord.
Und vergesst nicht, uns zu abonnieren. Das musst du jetzt noch sagen. Leute, vielen Dank fürs Zuhören. Danke Burkhardt. Ich habe viel gelernt. Fand richtig gut, die Folge, auch wenn es jetzt wieder länger ging. als wir dachten. Ist ja meistens so und ist ja auch bei der Software immer so. Leider. Alles cool. Danke fürs Zuhören und bis nächste Woche dann.