Einfach nur in der Nachbarstadt, dann wird es schwierig mit den USB Stick austauschen. Ne, das heißt du kannst über. Kannst du mal lustig vorbeibringen? Was machst dein Podcast rund um Softwareentwicklung und aktueller? Tag News herzlich willkommen. Geht schon los. Ja, ich glaub es geht los. OK, alles klar, herzlich Willkommen zu einer neuen Folge vom Coding Bodies Podcast. Ich bin natürlich wieder am Start der Fabi und auch noch der tolle Tino, also alle wieder
dabei. Jawoll, Moin Moin. Wir sind vollzählig, kann also losgehen, würde ich sagen. Joa, also wir sind vollzählig. Stimmt alle 2 da, genau da können wir ja eine neue Folge aufnehmen. Was ist das heutige Thema? Das heutige Thema ist Versionskontrolle beziehungsweise Versionierung von Software. Das ist irgendwie sehr wichtiges Thema und da wollen wir einfach mal ein bisschen drüber quatschen. Ja, möchtest du anfangen? Warum ist das wichtig, warum ist das ein wichtiges Thema?
Versionskontrolle, weil man. Uns das damals so beigebracht hat. Ich frage mich bis heute. Was macht man damit eigentlich? Was soll ich damit? Nein versions Kontrolle genau, also fangen wir mal grob an was ist das geht im Prinzip da darum seine Software in verschiedenen Versionen abbilden zu können. Dokumentieren zu können und eine Art Historie zu haben, das heißt die Weiterentwicklung des Source Codes abzubilden, einzelne, Ich nenne es mal Iteration.
Gehst du da soweit mit? Ja, klingt ganz gut. Iteration ist ja auch sehr. Agil, ja alteration, das ist ein tolles Wort, das ist so vielseitig einfach, sprich wenn ich Änderungen an meiner Software mache, kann ich diese auf einem Server bestmöglich remote quasi. Abbilden und speichern und habe dann einzelne Iterationen meiner Software abgebildet. Das heißt, ich kann einzelne Änderungen nachvollziehen. Sehen und auch gegebenenfalls zurücksetzen ist auch ein wichtiger Punkt ist.
Das klingt ja soweit erstmal ganz cool, fragen sich vielleicht Leute. Ja gut, ich kann auch einfach NUSB Stick nehmen und verschiedene Ordner meiner Software erstellen und dann einfach die Stände da rein laden, also rüber kopieren, ja das wäre damals auch ein Ansatz gewesen, aber ist natürlich nicht förderlich oder handhabbar das so zu machen. Ja, es wird dann relativ schnell
schwierig. Ne, also nochmal vielleicht so ein kleines konkretes Beispiel zu nennen, wenn man jetzt zum sagt, Man hat seine Code Basis und man möchte ein neues Feature implementieren und jetzt kommt jemand und.
Baut dieses Feature ein, ne, also sozusagen, es gibt einen Stand der Software und ohne Feature, jemand nimmt den Code, baut neues Feature ein, sagen wir mal feature x in den Code und dann wird sozusagen dieses Feature Remote als neue Version ne als ich sag jetzt mal Version 2 wenn es die andere die erste Version war eingecheckt, dann hat man 2 Versionen, Version 1 ist sozusagen dann in diesem Beispiel ohne Feature X und Version 2 mit feature x. Was natürlich den Vorteil hat,
dass du wenn Feature X total fehlerhaft ist und die ganze Software kaputt machen würde, du relativ schnell wieder einfach sagen kannst, o wir nehmen wieder. Stand also die Software Versionierung stand 1 ohne Feature x ne, also habe ich das so. Genau, also du kannst halt jede Änderung, die du verfügbar gemacht hast in Deiner Visions Controller Kontrolle, also nennen wir es mal Repository, da gehen wir mal auf den Fachbegriff ein, ja kannst du jederzeit wiederherstellen, was
hat ein riesen Pluspunkt ist. Jetzt ist natürlich die Frage wenn ich alleine arbeite und es gibt nur eine Richtung der Entwicklung also ich integriere halt immer weiter, ich entwickle meine Software weiter, es kommen neue Features rein und ich hab halt einen sehr geradlinigen Verlauf. Dann könnte man ja jetzt sagen, ja, aber wozu soll ich alte
Stände wiederherstellen? Deswegen würde ich einfach sehr gerne mal auf grobe Punkte eingehen, also übergeordnete Punkte, wann ist Sinn macht denn auch wirklich? Ein Tool für diese Source Code Management zu verwenden. Ja, dann halt doch mal den erst raus.
Woran denkst du denn gerade? Weil ich gerade meinte, wenn man alleine arbeitet, mag das vielleicht noch funktionieren, am aber definitiv nicht mehr funktionieren wird ist, wenn du in einem größeren Team arbeitest beziehungsweise meiner Meinung nach 2 Leuten macht es schon gar keinen Sinn mehr davon abzuweichen, nicht irgendwelche Arten und weisen
Versionskontrolle zu verwenden. Aber macht es keinen, also würdest du sagen, es ist nicht, also macht es nicht vielleicht trotzdem Sinn auch alleine n Repository zu nutzen, auch wenn man alleine. Arbeitet noch mal ein ganz anderer Punkt. Ende der Folge darauf eingehen. Ja OK, ehrlich gesagt, also lass uns mal. Erstmal stelle ich die Frage. Später noch mal.
Genau. Stellen sie einfach mal, weil das wäre jetzt zu ausschweifend, weil da werde ich richtig emotional bei diesem Thema. Nein, also wie gesagt. Also ich finde halt, sobald man im Team arbeitet ist ein must have auf solche Tools zu setzen, definitiv allein wegen der Skalierbarkeit. Umso mehr Leute, je mehr Leute desto schwieriger wird es einfach ohne. Da muss man ja natürlich auch dazu sagen, dass.
Also weil wenn du wenn ich jetzt zum Beispiel gar nicht wüsste, was so ein Repository für Vorteile hat, beispielsweise ne, wieso ist es dann wichtig, dass man das nutzen kann, also mit mehreren Leuten? Also angenommen ich denke jetzt, ob ich das jetzt lokal hab oder remote, was ist jetzt sehr große Unterschied wenn man jetzt mit mehreren Leuten dran arbeitet
wenn ich jetzt mal ganz dumm. Stelle weißt du ja genau, das ist ja genau die Skalierbarkeit. Also viele Entwickler bedeutet viele Änderungen am Source Code an vielen Stellen. Bestmöglich natürlich an unterschiedlichen, was aber
nicht mehr gewährleistet ist. Irgendwann, das heißt, du hast das Problem, dass Schnittstellen auftreten werden und Leute parallel an ihren eigenen Ständen am gleichen Source File sag ich mal arbeiten am gleichen Code und dann ist halt genau die Frage, wie willst du das jetzt wieder irgendwie geradlinig auf eine Struktur bringen, also auf einen Stand. Und um diese Konflikte, die da entstehen, zwangsläufig ne quasi Herr zu werden und das bewältigen zu können, sind genau
solche Tools gedacht dafür. OK, also diese solche Tools quasi haben die Möglichkeit dir sozusagen einen, also die die Änderungen zwischen verschiedenen Ständen anzuzeigen. Das ist unter unter anderem ein Feature. Genau, du kannst natürlich immer sehen, was ist denn jetzt der Unterschied zu der allgemeinen Code Basis, wie du so schön genannt hast und meinem lokalen Stand oder ich sehe halt natürlich auch was sind die Änderungen meines Kollegen. Ja.
Und wie passen die jetzt mit meinen eigenen Änderungen zusammen und wie kann ich das zusammenfügen, damit es einen gesamtheitlichen konkreten Software stand gibt? Ja, und da helfen diese Tools enorm, also wirklich so weit, dass ich sagen würde, ohne ist es schon fast gar nicht mehr zu bewältigen. Du redest einfach gar nicht, weißt, wo ist überhaupt was passiert. Ne, ja, also du redest jetzt immer von von Tools. Was gibt es denn so für? Tools ja, da gibt es sehr, sehr
viele. Also ich habe auch in meiner bisherigen Karriere, sag ich mal viele verwendet schon, aber im Endeffekt lande ich persönlich auch persönliche Präferenz eigentlich immer bei Git. Weil mir die Art und Weise, wie Geld funktioniert, sehr gut gefällt. Man kann ja kurz mal drauf eingehen. Der Vorteil bei geht den ich sehe ist, dass es verteilt ist.
Ein verteiltes System in dem Sinne, das heißt, du hast einerseits die Code Basis auf dem Server, also remote und gleichzeitig lokal bei dir und du musst halt nicht ständig Kommunikation mit dem Server betreiben, sondern kann es lokal auf deiner Code Basis arbeiten. Und erst beim Zurück spiegeln. Zum Server wird es dann halt entscheidend wieder diese Verbindung zu haben. Vorher bist du halt wirklich getrennt lokal auf deine eigenen Basis unterwegs.
Das bringt viele Vorteile mit sich, beispielsweise, dass du einfach keine Internetverbindung brauchst. Ich meine, das ist heutzutage schwer vorstellbar, irgendwo keine Internetverbindung zu haben, aber das ist halt schon noch ein Vorteil. Einfach in meinen Augen. Also du kannst halt lokal machen was du willst, ohne andere Leute zu beeinflussen, weil du den Remote nicht tangiert. Damit aber du. Hast ja wenn du sagst, dass
irgendwas remote liegt. Also wenn man jetzt zum Beispiel sagt, OK benutzt das Tool git, dann kannst du ja auf deinem Rechner das einfach versionieren. Ohne irgendwas Remote zu haben. Das mein ich ja, das ist ja die lokale Kopie, aber in dem Moment, wenn du mit mehreren Leuten zusammenarbeitest, brauchst du halt diese zweite Ebene des Remotes, also dass du quasi auf einem Server den Code Basis zur Verfügung stellst, auf die wieder alle arbeiten können.
Ja, aber das ist ja verteilt in dem Sinne, mal angenommen du hast jetzt 5 Entwickler und du hast halt dieses eine Repository wo der Code liegt, dann können ja alle auf diesem Repository arbeiten, haben aber jeweils eine eigene Kopie. Lokal und können damit machen, was sie wollen. Ja, also worauf ich gerade ein bisschen hinauswill, ist, dass man sich das vielleicht auch ganz gut vorstellen kann.
Das heißt, wenn es gibt ja Services, die in der Lage sind, wo man seine Remote Repositories ablegen kann, ne, also zum Beispiel so wie github oder ich glab und gibt es noch einige andere Services. Die eben so ne git Unterstützung anbieten, weil das sind ja 2 verschiedene Sachen. Also ich hab zum Beispiel auch schon öfter mal mitgekriegt, dass Leute, die jetzt zum Beispiel auch ein bisschen fremd sind, immer denken, dass Git und Github irgendwie das gleiche
ist. Aber eigentlich sind es 2 komplett verschiedene Sachen, weil das eine ist ja, also github ist ja ein Service wo du deine Repository Mode lagern kannst. Beispielsweise github in dem Fall und gibt s ja nur sozusagen Tool mit, was sozusagen die Versionierung. Am Ende überwacht ne also die sozusagen genau. Geht ist das versionierungs Tool genau sich und das andere ist halt wirklich nur n. Hab also wirklich n Server wo du halt deine Repositories hosten
kannst. Ja. Genau genau also nur, dass man genau also nur, dass man das einmal ne, wenn man sich das jetzt anhört, dass man denkt, OK, alles klar, ich kann git nutzen und um von diesem Remote Repository, von dem du geredet hast, das liegt beispielsweise um sich das n bisschen besser vorstellen zu können, bei Gitter Gitter, was auch immer, genau, und dann gibt es ja das Tool gibt wie du meintest, ich habe beispielsweise schon mit Git und
SVN gearbeitet, mir hat dann geht aber auch mehr gefallen als VN, wie ist das bei dir? Womit hast du denn zum Beispiel schon mal gearbeitet? Interessiert mich gerade, weil du meintest, dass du in deiner Karriere sozusagen auch schon einige Tools verwendet hast. In dem in der Hinsicht. Ja, also mit SVN auf jeden Fall. Auch SVN ist halt im Vergleich
zu geht halt zentral. Also das heißt du hast nicht dieses diesen verteilten Ansatz, dass du lokal arbeiten kannst, sondern du bist halt quasi immer auf der Remote Basis unterwegs.
Ist auch nicht schlecht, aber ich finde geht halt einfach auch wesentlich stärker beziehungsweise geht es einfach auch so. Ich will mich nicht zu weit aus dem Fenster lehnen, aber so der Branchen Hero also ich denke oder mein empfindest, dass die meisten auf Git setzen genau und Branchen spezifisch gibt es halt noch andere Tools und. Ich frag mich, wie hießen die? Clear case clear case, glaube ich hatte ich mal verwendet. Krass, ich gar nicht.
Ja frag mich nicht wer der Hersteller ist, aber also es gibt halt gewisse Versionierungs Tools die dann verwendet werden, wenn Prozesse eine Rolle spielen, also wenn Zeit harte Anforderungen gibt an Traceability, dass du wirklich alles ins kleinste Detail nachweisen kannst, obwohl das mit gilt grundsätzlich auch geht, also da ist steht in nichts nach, aber es ist halt einfach denn so.
Ein bisschen aus der Historie heraus, dass auf diese Tools gesetzt wurden und meiner Meinung nach ohne jemanden jetzt zu nahe treten zu wollen, finde ich, war die Handhabung bei geht immer am besten. Ja fand ich.
Auch also ich hab ja auch, ich hab auch wirklich nicht viel mit SVN gearbeitet, weil ich relativ schnell zu gibt, irgendwie dann auch geweckt oder alle da auch irgendwie gewechselt sind und ich kann mich ehrlich gesagt, wenn ich jetzt mal Hand aufs Herz lege, ich kann mich auch nicht mehr wirklich daran erinnern, was eigentlich bei bei SVN abging, muss ich ganz ehrlich sagen. Also.
Ich weiß es nicht. Ich könnte glaub ich gar nicht mehr erarbeiten, geschweige denn der jetzt aus dem Stegreif sagen, ja, das hat jetzt die und die Unterschiede zu gibt. Ne, also bin ich auch ein bisschen raus bei SVN weil geht einfach absolut gut für die Anwendung ist und genau das bietet was man irgendwie im Normalfall eigentlich braucht und sich irgendwie durchgesetzt hat. Das ist aber nur meine Meinung dazu, so wie ich das empfinde.
Weil du meintest, dass man ja zum Beispiel eine gewisse Traceability oder so ne überwachbarkeit oder wie man das übersetzen möchte hat. Du kannst ja bei Git, wenn du einen neuen stand, eine neue Version erzeugt, immer eine Message dazu packen. Das heißt, du könntest ja genauso gut, also ne, weil du meinst, bei github geht es ja auch eigentlich ganz gut um das Mal zu sagen, du kannst immer eine. Der handgeschriebene Nachricht also eine Commit Message, wie man das so schön nennt.
Aber deinen neuen Stand dran packen, ne, was ja zum Beispiel auch ein bisschen dafür dient, das n anderer Entwickler oder eine andere Entwicklerin bei einem bestimmten Stand von jemandem gut sehen kann. OK, was ist denn hier eigentlich passiert? Ne genau. Und das ist halt auch ein Punkt, den man wirklich bedacht leben sollte. Also nicht einfach irgendwie a
new Feature oder so was da rein. Greift, sondern halt wirklich versucht in diesem Satz. Also es kann länger sein, aber man sollte es natürlich auch möglichst kurz fassen, bedacht da reinschreiben, was wirklich passiert ist, damit Leute beim Überfliegen der Historie schnell sehen können, was mit jeweils dem Commit quasi in die Software gekommen ist.
Ja, wie handhabst du das, wenn wir jetzt zum Beispiel n sagen wir mal, Du entwickelst ein Feature und hast vielleicht zusätzlich noch so ein kleines Refactoring? Würdest du zusammenkommen, oder? Also würdest du da draus zusammen, um das jetzt mal in unserer aktuellen Beschreibung zu halten, würdest du zusammen eine neue Version davon neue Versions stand erzeugen, oder? Würdest du das trennen?
Boah, das ist das ist natürlich ziemlich spezifisch jetzt ne, also wenn das Feature also betrifft, das Refactoring gleichzeitig das Feature wieder, dann ja, weil warum sollte ich es dann nochmal trennen? Wenn ich aber einfach irgendwelche Punkte festgestellt habe, die reflektiert werden können, dann würde ich es einzeln machen. Ja, tatsächlich klingt auf jeden Fall logisch.
Also ich hab zum Beispiel, ich denke gerade daran, wenn man keine Ahnung, weiß ich auch öfter mal erlebt habe, ist du, du arbeitest irgendwo an, keine Ahnung irgendwie am Frontend.
Entwickelst ne Page und siehst aber gleichzeitig in diesem Zuge. Wenn du da vielleicht dir von anderen Komponenten ne von anderen teilen, die schon existieren, vielleicht ein Styling n bisschen abguckst ne und aber auch gleichzeitig verändert, aber dann siehst OK warte mal, da muss ich vom Styling her auch nochmal an der Komponente was ändern, dann hatte ich auch schon erlebt, dass man, dass es dann die eine Person gibt, die sagt, Ja komm,
hau alles zusammen rein und ne wir fokussieren uns auf das neue Feature oder auf den neuen. Auf das neu, also den neuen Punkt, den wir gerade betrachten. Und wir hauen sozusagen das Styling von irgendwas, was eigentlich gar nicht dazu gehört, auch mit rein.
Andere sagen wieder OK. Wir sollten das unbedingt trennen, dass man halt sagt, das neue Feature oder was auch immer wird einzeln committed und der sozusagen, der das Styling von irgendwas anderes eigentlich nicht zum Feature gehört, wird auch noch mal einen committed und ich finde auf jeden Fall prinzipiell die Idee dahinter nicht schlecht, weil es ja einfach angenommen du bist n, du bist jetzt ein Entwickler von von diesem Code und möchtest dir einen bestimmten Stand angucken
und du sagst ey, guck mal hier, da ist das Feature XY. Reingekommen. Dann willst, dann willst du dich ja nicht durch irgendeinen quälen, du dir nochmal Anguckst, der eigentlich gar nicht zugehört und von daher ist es aus dieser Perspektive schon sinnvoll.
Einen Punkt dazu noch. Es ist natürlich auch immer die Möglichkeit, dass ein Fehler in die Software kommt und jetzt hast du einen Commit und weißt OK, mit diesem Commit ist n Fehler reingekommen, so OK ja gut das neues Feature reingekommen, OK das schauen wir uns das Feature also wenn du jetzt aber das Refactoring da auch drin hast ist es ja auch nicht. Denkbar, dass durch das Refactoring dieser Fehler entstanden ist.
Und dann nimmst du dir im Vorfeld schon die Möglichkeit auszusieben, ob es das Refactoring war oder das neue Feature. Weil hättest du jetzt einzelne commits, könntest du die Stände einzeln wiederherstellen und gucken, ob der Fehler drin ist. Das ist halt auch eine enorme Zeitersparnis hinten raus. Ja, auf jeden Fall. Also das ist auf jeden Fall ein guter Punkt, und da sind wir eigentlich schon wieder n bisschen bei dem, was wir in der, glaube ich, in der einer der letzten Folgen.
Gesagt hatten, wenn es nicht sogar die letzte war. Einfach mal ein bisschen auch darüber nachdenken, ne, also dass man zum Beispiel sagt, OK, welche Commit Message vergebe ich? Ne ja, also mal bisschen. Bisschen nachdenken. Code.
Einfach mal nachdenken. Nein, aber also wirklich mal vielleicht so eine Minute länger nehmen, um zu sagen, OK, wie lautet die Commit Message und vielleicht auch sagen, OK, was verpack ich in dieser in diesem Commit, das ist halt durchaus ratsam, dass man sozusagen gesagt, OK, ich arbeite ja auch nicht alleine im Normalfall an diesem Code, wenn das so ist. OK, also ich hab auch schon. Private Repos gehabt, wo ich dann einfach gesagt hab, so komm mit und der kommt. Message war. Stuff klar.
Ich dachte Scheiße drauf. Ist jetzt egal. Das ist halt genau das Thema. Die Verlockung ist einfach so groß, dass ganz schnell einfach du denkst, du, ich will jetzt
einfach nur mit. Ja, ich hab jetzt so viel gemacht und wer kennt das nicht, du hast dir so ein Thema vorgenommen, ne willst du ein Feature implementieren ist nur was kleines und dann irgendwas unterwegs und du denkst AOK ich mach ganz schnell und dann machst du das noch und hier noch einmal hast du 1000 Änderungen da obwohl du nur 2 Pfeile sag ich mal ändern möchtest. Und ja gut jetzt komm bitte ja.
Willst du das jetzt alles einzeln kommen oder denkst du dir ach komm, ich arbeite doch eigentlich fast alleine da dran? Ja genau kommt Message Stuff fertig, rein damit und. Das ist, das ist halt genau der Punkt, da kann man auf jeden Fall ganz gut unterscheiden, dass man sagt, OK, in welchem Kontext bin ich denn gerade unterwegs, ne, also wenn ich in einem großen Team bin und das wirklich n Projekt ist, was wo wo viele Leute dran arbeiten, dann ist es durchaus sinnvoll
quasi auch. Sag ich mal die den Code und die Commit pro, also die Code pro Commit gut dem Team zu präsentieren. Ja, dass man das halt eben auch nicht irgendwie wie Kraut und Rüben handhabt. Ja, guter Punkt, genau also. Ein Punkt würde ich noch. Ach so wolltest du noch. Sorry, ich wollte dich nicht unterbrechen, Entschuldigung. Na ja, also was mir gerade noch einfällt, ist der Punkt, dass es ja durchaus vorkommen kann.
Weil wir zum Beispiel, du hattest es vorhin angesprochen, du meintest, wenn man jetzt zum Beispiel lokal irgendwas hat oder eine, also einen eine Code Basis, wo also 2 Leute dran arbeiten, ne, dann ist es natürlich durchaus schwierig, wahrscheinlich wenn man am gleichen Pfeil arbeitet, ne, wie ist denn das jetzt beispielsweise wenn wir jetzt auf so einer Versionierung arbeiten, also beispielsweise in Git, wie funktioniert das also angenommen, es gibt jetzt einen
Pfeil. Ne, das heißt Coding bodies Code Punkt, was auch immer Java. Ja. Und das liegt jetzt irgendwo Remote auf einem Repo von uns und du arbeitest daran und arbeitest an der Funktion. Coding Buddies machen Sachen und ich arbeite auch an der Funktion. Was passiert dann? Naja, also grundsätzlich ist es ja erstmal so. Wer als erstes seine Änderung eincheckt. Damit erstmal kein Trouble ne, also von einem was der hat
gewonnen gewonnen. Du springst ja von der gleichen Code Basis ab, das heißt Wir ziehen uns jetzt quasi beide den Stand a sag ich mal a ist die Ausgangsbasis. Und wir entwickeln jetzt beide an den Funktionen rum. Dann würdest du jetzt quasi deine Änderungen committen. Und dafür sorgen, dass sie verfügbar ist.
Ne, also im Prinzip in Baguette wäre es du push, das dann halt auf den Server ne Mhm, dann ist das für dich fein, da wirst du gar keine Probleme mit haben, weil du bist ja quasi vom letzten Punkt abgesprungen und hast eine Änderung gemacht. Also ich hab jetzt quasi ich hab meine Änderungen gemacht, das liegt jetzt auf dem Server und du hast deine lokale, dein lokale Änderungen noch bei dir und auf dem Server. Wurde mein Ich bin noch am entwickeln.
Ich bin noch nicht fertig, du warst schneller und hast gewonnen, quasi. So und wenn ich dann jetzt meine Änderungen auch quasi hochladen möchte und versionieren möchte, dann wird der Server zurückmelden.
Ah nee, ist nicht, es gibt Änderungen auf dem Server, die muss ich mir erst ziehen in dem Moment, wenn ich versuche mir diese Änderung zu ziehen wird geht mailen, dass Konflikte gibt, weil einfach meine Änderungen mit der Akte mit dem aktuellen Stand vom Server überschrieben werden würden, ja.
So ist die Ausgangslage und das Problem, also das heißt, ich kann mir den neuesten Stand nicht ziehen, weil ich selbst Änderungen da drauf habe, muss mir aber den neuesten Stand ziehen, damit ich das einchecken kann, weil es ja n fortläuft figer also n Verlauf ist halt ne.
Also ich kann nicht einfach irgendwo mittendrin was rein kommen sag ich mal so und dafür gibt es dann halt das sogenannte Git merge, das heißt du musst jetzt die Änderungen die auf dem Server liegen zusammenfügen mit deinen Änderungen dadurch wieder eine Code Basis. Schaffen die dann kommen kannst ich hoffe, das war halbwegs verständlich.
Das heißt, ich habe deine Änderungen b und meine Änderung a und muss jetzt beide zusammenfügen, dass ne quasi ein Stern C rauskommt, der dann wieder auf dem Server geladen werden kann. Genau, und das kann er ja, sorry. Ja, ja, da gibt es verschiedene
Möglichkeiten. Also über Strategien würde ich jetzt nicht so ins Detail eingehen, kann man auch nochmal drüber sprechen, aber im Endeffekt sagt hast du 3 Möglichkeiten benutzt deine Version benutzt die Version vom Server. Oder füge sie zusammen und dann, ganz wichtig, immer sagen, benutzt meine Versionen.
Push Force ne, aber das Ding ist das Ding ist, also hast du auf jeden Fall supergeil erklärt und also was mir noch so ein bisschen fehlt ist oder was ich vielleicht einfach nicht gehört habe rausgehört habe ist das ist ein manueller Schritt, ne also der wird nicht irgendwie automatisch passieren, sondern muss halt ja. Ja, gut war. Es gibt verschiedene Strategien, aber von dem, was du gerade. Scheint also, oder was ich sag mal so, also. Geht, geht, macht das schon ziemlich geil mit dem Auto.
Das heißt stimmt, wenn Sachen aufgelöst werden können, weil zum Beispiel hast am Anfang der Funktion 2 Zeilen eingefügt und nicht am Ende 2 Zeilen, dann kriegt das komplett alleine hin, beide Einzuflechten. Es fragt dich halt nochmal wenn es potentielle Gefahren dabei gibt, aber es kann auch ganz oft sein, dass Sachen automatisch gemeldet werden, was eine riesen
Erleichterung ist. Aber ich glaube worauf du hinaus wolltest ist natürlich wenn du jetzt exakt an den gleichen Code Zeilen. Schreib ne, dann weiß geht natürlich nicht welche jetzt gültig ist oder wie die die Vereinigung beider Änderungen aussieht und das ist ein manueller Schritt. Ja, ich war. Voll in meinem Beispiel gefangen. Weißt du, dass wir beide einen der Funktion Coding Buddy. Story ich bei dir immer mit rum schreibe. Ich habe dann irgendwann Fehler rein und die musst du dann
wieder raus machen. Ja ne, aber sehr gut erklärt. Auf jeden Fall cooles Beispiel, weil das ist finde ich so n bisschen ne gewisse. Also in gewisse Kernaktivität, die so eigentlich finde ich, dass ja schwierigste in Anführungsstrichen ist. Bei auf jeden Fall, wenn
mitgearbeitet. Ja allgemein ne, das ist jetzt nicht nur du hast halt immer dieses Problem, dass Konflikte auftreten können, definitiv, aber damit und ohne Daten kann man geht sogar ich bin voll der Verfechter, aber das geht halt echt von Vorteil, weil du einfach die lokale Kopie hast. Das heißt du kannst das lokal mergen. Und wenn es nicht klappt, dann setzt es zurück und mach das einfach nochmal. Wenn du Fehler gemacht hast.
Also ist keiner davon betroffen, solange es alles lokal bei dir passiert, was ne riesen Vorteil ist in meinen Augen. Ja, das stimmt, das stimmt. Du kannst einfach den ganzen Scheinwerfer werfen. Ja, das ist ein guter Punkt, noch OK, möchtest du noch mal n bisschen zusammenfassen?
Ich weiß gar nicht, ob wir jetzt alles so schon mal über dieses Thema, weil wir ja noch eine Frage, wollte ich dir am Ende auch noch stellen, ja, aber so n bisschen zusammenfassend so, weil wir ja gerade gesagt haben, warum es geht, wichtig, so was sind jetzt die wichtigen Punkte, warum benutzt? Man. Gerade so. Ich muss nochmal kurz nochmal allgemeiner machen, nicht nur. Also ja klar, klar sorry Fällung von uns und ich glaube der Branchen Standard mittlerweile. Aber was?
Warum ist es wichtig, sobald man in einem Team arbeitet, im größeren Team und das ganze Skalieren muss?
Ist es, geht es nicht ohne Versions Kontrolle, wenn eine Dokumentation vorlegen muss, wenn du nachweisen willst was sich verändert hat an deinen Code ganz wichtiger Punkt, dann geht es auch nicht ohne weil wie gesagt was ich am Anfang meinte mit Ordner erstellen auf dem USB Stick und da die Version rein laden und am besten Textdateien mit einer änderungs Historie oder so, dass das wird langfristig nicht funktionieren,
ne? Zugriffskontrolle ist noch ein wichtiger Punkt. Das heißt, wenn du zum Beispiel Remote arbeitest, also die ganzen Entwickler sitzen meinetwegen auf der Welt verteilt oder einfach nur in der Nachbarstadt, dann wird es schwierig mit dem USB Stick austauschen. Ne, das heißt du kannst über. Kannst du mal vorbeibringen. Ich muss wieder hast. Da können wir ja gleich ne aus der Uni erzählen.
Also das ist nicht so, nicht so unwahrscheinlich, dass man arbeitet, auf jeden Fall, was ich sagen wollte ist genau du kannst halt gerade in Kombination mit Plattform wie Git Hub auch eine Zukunft Kontrolle umsetzen, das heißt nicht jeder kann an den Code ran und du kannst nur mit gewissen Leuten daran arbeiten, was sehr vorteilhaft ist. Was hatten wir noch für Prozess Themen ist es sehr oft wichtig wo ich meinte es gibt halt auch andere Tools.
Durchgesetzt wird aber geht das genauso umsetzen kann und ach so einen Punkt haben wir tatsächlich vergessen. Du kannst mit so versionierungs Tools natürlich auch Releases erzeugen von beispielsweise, was ja eigentlich jeder Coder kennen sollte, von Libraries oder Packages, die dann zum Beispiel
auf github gehostet sind. Ja, da kommt mir sofort so NPMN Kopf. Also das war halt zum Beispiel sagt so ne, du hast irgendwie diversion, weiß nicht 2.1.3 von einer bestimmten Lip von NPM die du dann. In dafür. Gibt es ja die, die die Git tags, also tags im Prinzip die versions Nummer reinschreiben
kannst. Und dann kriegst du auch genau diesen Stand, also diesen Comic wie wir s ja so schön gesagt haben, der dann dieses Release widerspiegelt, im Endeffekt auch ne super Sache auf jeden Fall. Genau auf jeden Fall auch ein großes Thema, wenn es generell darum geht, dass irgendwie bestimmte Versionen manchmal n Code auch zusammen passen müssen in Sachen Versionierung. Das ist auf jeden Fall vielleicht noch ein interessantes Thema. Und Kopfschmerzen. Manchmal witzig, aber.
Was du gerade meintest, so der Anekdote aus der Uni, ich glaube, wenn ich jetzt nicht ganz irre, meinst du, dass wir damals in dem Roboter Projekt, was wir irgendwann mal erwähnt haben, ganz genau das unseren Code, den wir da geschrieben haben, wo haben wir ihn verwaltet? Sag? Es in einer wunderbaren Dropbox. Ich denke Dropbox ist auch immer noch ein Begriff für unsere Zuhörerinnen und Zuhörer. Ich hoffe es. Geiles Tool. Ist in gewissermaßen ja. Für Team arbeiten nicht so geeignet.
Also du kannst natürlich, im Prinzip ist ein Datenaustausch am Ende ne, also du hast sozusagen Cloud Speicher und kannst den Verwalten und ja. Mit mehreren Leuten Leuten nutzen wie zum Beispiel Google Drive. So aber diese ganze versionierungs Geschichte, committen, Historie, Widerstände herstellen, das ist natürlich alles da jetzt nicht so gegeben für die Softwareentwicklung und da hatten wir natürlich extrem das Problem, wir waren 4 Leute, also eigentlich nur 4 Leute. Ja.
Und hatten eine Code Basis, die in der Dropbox lag. Und jetzt haben wir da zusammen entwickelt. Ja. Es ist sehr schwierig, genau was passiert, nämlich wenn wir, wenn ihr 2 Leute an irgendeinem Teil arbeiten und der erste speichert und der zweite speichert auch, was passiert dann? Ja, du hast halt die genau diese Konflikte, die wir besprochen haben, werden halt einfach über gebügelt. Genau also der letzte ich.
Also wenn ich das richtig im Kopf, ich glaube der speichert, der hat halt in dem Falle gewonnen und sagt Halt so, OK, das ist jetzt meine Änderung und damit wird ja alles was vorher gemacht wurde verworfen und damit hast du ja einen riesengroßen Overhead, weil du mal sagen musst Tino, arbeitest
du gerade an dem Pfeil? Nee, ja gut, was ich Alex, arbeitest du gerade an dem Pfeil ne ich nicht gut Benny arbeitest du den ich nicht weißt, dann ist also im Endeffekt ist ja so, dass du dann wahrscheinlich Kopien warst.
Also diese klassischen Backup Dateien, dass du sagen kannst, OK, ich arbeite jetzt erstmal auf der Datei CD an und dann tausche ich irgendwann und so Jungs alle alle cool, da wird OK ich werde es jetzt tun, so weißt du und das hat einfach schon gezeigt und man muss natürlich sagen, zu dem Zeitpunkt gab es einfach versionierungs Tools. Genau. Und jetzt möchte ich auf deine Frage nochmal eingehen.
Damals habe ich nicht die Notwendigkeit gesehen beziehungsweise wir alle ja nicht, sonst hätte irgendwer gesagt, Ey Jungs, wollen wir nicht mal ein Repository aussetzen dafür? Nein, das war Dropbox, wir hatten diese Dropbox bei uns im Freundeskreis, weil wir ja auch keine Ahnung Uni unterlagen ausgetauscht haben, keine Übungsergebnisse an dieser Stelle auf keinen Fall waren das übrigens Ergebnisse oder Lösung sowas sowas macht man nicht nein
jeder übt für sich selbst. Und deswegen haben wir natürlich die weiter dafür genutzt. Aber man hätte damals einfach schon Repository aufsetzen sollen und deswegen auf deine Frage sollte man das auch alleine nutzen, würde ich heutzutage sagen, ja, erstens du weißt nie ob dein System irgendwie kaputt geht, dein Laptop so blöd es klingt kannst du s. Wer macht heutzutage wirklich noch auf USB Stick irgendwelche Kopien regelmäßig? Also ich mache es nicht. Nicht?
Auch nicht. Irgendwelche Datensicherung, weil ich vertraue da eher zum Beispiel github. Einfach ein Profil anlegen, das kostet nichts. Wenn man das jetzt nicht quasi kommerziell nutzt oder in größeren Teams, wird sich einfach privates Repository anlegen und da sein South Code verwalten. Hast ne coole Sache, weil es ist einfach Industriestandard sich damit auszukennen und das heißt spätestens wenn du in die Arbeitswelt kommst sollte man sich gut mit Geld auskennen.
Ich wollt Grad sagen, das ist halt wichtig, ne, du musst halt diese Erfahrung machen und diese diese einfach die also die Erfahrungen sammeln, wie man mit diesem Tool oder mit solchen Tools. Also man kann sich auch mit verschiedenen Tools ausprobieren. Github können wir also gut können. Wir empfehlen mit beispielsweise github, aber halt auch anderen, ist Scheiß egal, aber man sollte glaube ich in der Lage sein einfach mit zu arbeiten. Genau.
Also du kannst natürlich jetzt nicht irgendwie Fälle erzeugen, dass du Riesen merge Konflikte kriegst oder so wie auch du bist du alleine da dran, ne, also könntest du jetzt irgendwie keine Ahnung 2 Profile machen und dann die gegenseitig darauf rumgeritten, aber darum geht es ja gar nicht, aber einfach mit den Grund Mechaniken von Git. Dazu kommen, das ist schon viel wert, weil ich die Erfahrung gemacht habe, im meinem bisherigen Berufsleben, das auch einige Leute damit keine
Erfahrung haben oder hatten, anfangs und dann auch Schwierigkeiten damit hatten. Und ich finde, gerade das kann man einfach dann, wenn man sich schnell damit beschäftigt oder frühzeitig quasi entgegenwirken und einfach schon mal wissen, was ist denn, was ist denn mit wann push, wann pullig, was ist denn Fetsch zum Beispiel, ne, nur um die ganzen Fachbegriffe jetzt nochmal. In den Raum zu werfen.
Was macht man stash? Genau o stash, das machen auch weniger auch n cooles Feature eigentlich aber gut, aber. Ich sage, was ich noch hab. Ja, was ich noch ganz kurz sagen wollte ist also weil du meintest so OK, man kann sich auch bei github repo anlegen und so weiter und sofort ne auf jeden Fall ist auch ratsam auch damit zu arbeiten und einfach mal Erfahrungen damit zu machen. Was ich aber zum Beispiel auch weil im Sinne von alleine mit Git arbeiten.
Wenn ich anfange, irgendwas Kleines aufzusetzen, irgendwo mit anzufangen, mich mal auszuprobieren und einen Stand erreicht, wo ich sage, ey, das ist jetzt irgendwie, das funktioniert erstmal soweit, wie ich wollte und bevor ich jetzt meine nächste Änderung mache, die quasi vielleicht in eine ganz andere Richtung geht, vielleicht das Ganze kaputt macht, weil ich noch ein bisschen am ausprobieren bin, aber erstmal ein Stand erreicht, wo ich sage, der funktioniert,
das weiß ich so und ich will jetzt einfach nur mal ein bisschen wirklich den Code eskalieren. Lassen. Dann fange ich zum Beispiel an und setze mir einfach lokalen Git auf. Also ich mach einfach quasi sozusagen git init, dann habe ich n git, also n repo lokal nur bei mir und Committee das ich muss das natürlich nicht irgendwo remote hin pushen, das bleibt einfach bei mir. Richtig, ja.
Der Vorteil dabei ist aber, dass wenn ich danach nach einem Stand, wo ich weiß, das funktioniert jetzt also das, was ich ausprobieren wollte, ist, passt. Und ich möchte jetzt sozusagen das nächste oben draufsetzen, dann sehe ich, welche Änderungen ich im Verhältnis zu vorher gemacht habe. Das heißt, ich erstell mir einfach lokal. Meine Kleine geht Historie und damit kann ich einfach selber ganz gut sagen.
OK, welche Änderungen habe ich denn gerade gemacht, weil ganz ehrlich, ich hab das auch schon voll oft gesehen, dass man dann irgendwie arbeitet, arbeitet, arbeitet ne und dann hab ich am Anfang auch gemacht und dann Störung z immer wieder zurück was hab ich denn jetzt gemacht hab und dann hast du 5 Files und weiß gar nicht mehr welche Störungen z. Wie oft musst du das drücken damit deine falls wieder synchron sind damit du vielleicht wieder überhaupt an
Punkt kommst wo du sagst. Das funktioniert erstmal wieder. Das ist der Stand, wo es funktioniert hat, gerade wenn man neue Sachen ausprobiert und das ist wichtig in der Softwareentwicklung neue Sachen auszuprobieren.
Ja genau, nee. Also das ist auf jeden Fall ein sehr guter Punkt. Genau, also du kannst halt dich selbst versionieren sozusagen und sagen kannst halt sagen, OK, oh nee, das war das ging jetzt in die falsche Richtung, einmal bitte einmal zurücksetzen so, und das kannst du nicht, wenn du keine Verwaltung dahinter hast. Ne, genau. Ja, ein sehr guter Punkt. Auf jeden Fall spricht auch dafür, rechtzeitig damit anzufangen, auf jeden Fall. Haben wir viel zu spät gemacht. Ja genau, also wie.
Ich hab halt wirklich erst in meinem Praktikum, da hatten wir drüber gesprochen und da hatte ich das erste Mal erst mit Git Berührungspunkte. Das heißt ja, da hab ich schon 33 Jahre studiert als Praktikum, war am Ende vom Bachelor ja
schon recht spät. Also ich hab sämtliche Software Projekte oder Programme die wir schreiben mussten, so in Übungen immer einfach nur lokal gehabt, als also ohne irgendwas und da hatte ich auch das Problem, dass du gesagt hast, das ist nicht die Lösung, hier ändern, da mal ändern. Oh mein Gott, jetzt alles jetzt alles kaputt von vorne alles weg so weißt du das ist scheiße, ja, aber ansonsten würde ich sagen. Wir haben es jetzt ausführlich besprochen, wir 1.
Folge war nochmal kurz die Anmerkung. Sollte es fragen zu dem ganzen Thema, speziell zu Geld geben, liebe Zuhörerinnen, liebe Zuhörer, wenn es Unklarheiten gibt oder vielleicht der Bedarf da ist, da man Tutorial zuzumachen, machen wir das gerne. Wir können auch gerne mal ein Video dazu machen, wir einfach
mal erklären. Wie geht funktioniert, wie man es anwenden kann, können auch ein paar Beispiele konstruieren, wie Fabi und ich verschiedene Code Änderungen machen und euch dann auch mal das Märchen zum Beispiel zeigen. Immer raus damit, meldet euch bei uns wär auf jeden Fall cool das zu machen, hätten wir auch Bock drauf oder was meinst? Du interaktiven Repo aufsetzen, ja. Genau. Und dann können wir auch mal austoben oder? Das wär aber OK.
Zurück zu Punkt, wenn die Folge gefallen hat, lasst doch gerne mal ein Like da, die Links findest du. Show Notes also wie gesagt, meld dich bei uns, wenn der Bedarf besteht. Ansonsten wie gesagt ABONNIERT den Podcast, würde uns freuen und bis zum nächsten Mal. Eure Coding Bodies gemeinsam besser.