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.