[0:01] Herzlich Willkommen zum Anwendungsentwickler-Podcast, den Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:10] In dieser Episode gibt es eine Einführung in die Versionsverwaltungssoftware Git. Viel Spaß dabei!

[0:20] Hallo und herzlich Willkommen zur 76. Episode des Anwendungsentwickler-Podcasts.

[0:26] Mein Name ist Stefan Macke und heute mache ich mal was Neues, was ich bislang noch nicht gemacht habe hier im Podcast.

[0:33] Ich habe nämlich mal mir ein fachliches Thema vorgenommen und zwar Git, die Versionsverwaltungssoftware Git, die du vielleicht sogar schon kennst oder ich hoffe es mal, ist ja sehr verbreitet heutzutage.

[0:41] Und ich habe mir mal so ein paar Fragen dazu aufgeschrieben, die ich vor ein, zwei Wochen meinem aktuellen Azubi mitgegeben habe,

[0:48] damit er sich mal mit einem Tutorial, was ich ihm gleich mitgeschickt habe, so ein bisschen darauf vorbereitet, quasi selbst so ein bisschen recherchiert, ausprobiert, das Ding abarbeitet und dann mir die Fragen beantwortet.

[0:59] Und diese Fragen habe ich auch zum Download auf meinem Blog zur Verfügung gestellt.

[1:03] Wenn du sie dir runterladen willst, musst du dich allerdings für mein Newsletter anmelden unter www.anwendungsentwickler-podcast.de slash Newsletter kannst du das tun.

[1:11] Wenn du schon angemeldet bist, noch besser, kannst du natürlich auch runterladen, dann kennst du den Link schon oder du hast ihn jetzt auch im aktuellen Newsletter nochmal von mir zugeschickt bekommen.

[1:19] Du kannst aber auch einfach auf die Website so gehen, auf die Shownotes zu dieser Episode unter www.anwendungsentwickler-podcast.de slash 76, also die 76 für die heutige 76. Episode.

[1:30] Und da findest du die Fragen auch nochmal. Du kannst sie dir aber auch im Markdown-Format zum selber ändern, ausdrucken, wie auch immer, runterladen, wie gesagt, wenn du bei meinem Newsletter angemeldet bist.

[1:39] Die Fragen habe ich mal zusammengestellt. Das sind so meiner Meinung nach so erstmal so ein paar zentrale Sachen, die man wissen muss, wenn man mit Git arbeiten will.

[1:46] Und ich habe eben einfach mal die Aufgabe gegeben, hier guck dir mal das Tutorial an, such mal ein bisschen im Internet, arbeite mal so ein paar Antworten aus für die Fragen.

[1:53] Und wir haben uns die dann im Anschluss gemeinsam angeguckt und so eine kleine Lernzielkontrolle daraus gemacht.

[1:57] Und das Ganze packe ich jetzt mal hier in den Podcast, weil ich finde, dass Git ein sehr wichtiges Werkzeug ist.

[2:03] Nicht unbedingt ganz konkret jetzt Git, aber eine Versionsverwaltung allgemein, sage ich mal.

[2:07] Nur wenn man heute mit irgendwas anfängt, dann würde ich doch ganz stark Git empfehlen, weil es einfach so dominant ist und so verbreitet.

[2:13] Also ich kenne fast niemanden, der nicht mit Git arbeitet, nur noch mit irgendwelchen anderen Systemen, außer vielleicht im .NET-Umfeld.

[2:19] Wenn man jetzt wirklich hardcore Microsoft-Sachen macht, da ist es dann vielleicht eher der Team Foundation Server, wo nochmal Versionskontrolle drin ist.

[2:25] Einige Leute benutzen auch noch Subversion, einfach weil es etabliert ist und weil es seit Jahren zum Beispiel im Einsatz ist.

[2:29] Aber wenn ich jetzt irgendwelche neuen Sachen starte und auch gerade ich persönlich, ich benutze für alles eigentlich nur noch Git.

[2:35] Und auch auf der Arbeit haben wir eigentlich Git für alle unsere Repos im Einsatz.

[2:39] Außer noch so ein paar ganz alte SVN-Sachen, die der Fachbereich benutzen soll, weil Git zugegebenermaßen, wenn man damit einsteigt, nicht das einfachste Tool ist.

[2:47] Ist ein bisschen, ja man könnte schon fast sagen, ein bisschen kompliziert am Anfang.

[2:50] Deswegen auch genau diese Episode, um mal so ein paar Grundsatzfragen zu klären, damit man eben mit Git vielleicht arbeiten kann.

[2:57] Und vielleicht auch dieses Thema, was auch durchaus relevant ist für die Prüfung, dann irgendwie mal angehen kann.

[3:03] Ich hoffe, es ist ein bisschen was für dich dabei.

[3:05] Vielleicht kennst du Git schon, dann ist es vielleicht so eine kleine Wiederholung oder Vertiefung.

[3:08] Vielleicht kennst du noch nicht alle Begriffe, die wir heute durchgehen.

[3:10] Wenn du Git noch nicht kennst, nimm das als Ansatz, um es dir dringend mal anzuschauen.

[3:14] Ich habe auch in den Shownotes und auch in den Fragenlisten, die man runterladen kann, wie gerade erwähnt, auch noch ein paar kostenfreie Ressourcen hinzugefügt.

[3:22] Also gerade zu einem Tutorial, was ich auch benutzt habe, was mein Azubi sich durchlesen sollte.

[3:27] Das ist von Java Code Geeks.

[3:29] Vielleicht kennst du die Seite auch schon.

[3:31] Das ist eine tolle Seite mit ganz vielen coolen Ressourcen rund um die Java-Entwicklung.

[3:35] In diesem Fall gibt es auch ähnlich noch für andere Sprachen.

[3:38] Aber ich habe das Ding auf jeden Fall abonniert.

[3:40] Und da habe ich dieses Git-Tutorial halt gefunden.

[3:42] Das ist ein kostenfreies E-Book um die 40 Seiten.

[3:44] Und es sind alle wichtigen Sachen drin erklärt.

[3:46] Und man kann es auch gleich direkt mitmachen, sage ich mal.

[3:48] Von daher habe ich Ihnen das jetzt mal empfohlen.

[3:50] Und das hat meiner Meinung nach jetzt erstmal ganz gut geklappt.

[3:52] Die Leerzieh-Kontrolle hat ganz gut funktioniert.

[3:54] Und die meisten Sachen konnte er gut beantworten.

[3:56] Von daher habe ich das einfach in die Shownotes reingepackt.

[3:59] Ja doch, in den Shownotes auch.

[4:01] Da kannst du auch direkt auf die Links gehen und dir die Sachen angucken.

[4:03] Oder dir halt die Liste darunter laden.

[4:05] Da sind auf jeden Fall die Links auch noch drin.

[4:07] Zusätzlich habe ich natürlich auch noch das super Buch überhaupt dazu.

[4:10] Nämlich quasi vom Erfinder, kann man nicht sagen.

[4:13] Aber von einem Git-Benutzer oder Entwickler der ersten Stunde.

[4:17] Von Scott Chacon spricht man ihn glaube ich aus.

[4:20] Das Pro-Git gibt es als kostenfreie E-Book-Variante zum Download.

[4:24] Gibt es aber auch als gedruckte Variante.

[4:26] Ich habe beides auf jeden Fall in den Shownotes verlinkt.

[4:28] Und wenn du bei Pluralsight zum Beispiel unterwegs bist, gibt es da auch super coole Git-Kurse.

[4:32] Ich habe mal so einen Einstiegskurs verlinkt, direkt in den Shownotes.

[4:35] Es gibt aber auch noch einen, der jetzt 2016 erst rausgekommen ist.

[4:38] Den konnte ich noch nicht verlinken.

[4:40] Der behandelt, sage ich mal, richtig die Interna von Git.

[4:44] Wie das ganz konkret auf Dateisystem-Ebene funktioniert und wie diese Hashes berechnet werden.

[4:48] Und also wirklich die krassen Interna von Git.

[4:50] Das fand ich sehr, sehr, sehr interessant.

[4:52] Also wenn du da zufällig schon Abonnent bist, guck da unbedingt mal rein.

[4:55] Da gibt es echt super gute Videos zum Thema.

[4:58] Okay, wir fangen einfach mal an mit den Fragen, die ich mir jetzt zu der Einführung in Git ausgedacht habe.

[5:03] Also wie gesagt, ich nehme das jetzt dann in Zukunft für meine nächsten Azubis.

[5:06] Gebe denen die Liste und die sollen selber recherchieren und das bearbeiten.

[5:09] Ich glaube, dann hat man erstmal einen ganz guten Einstieg in Git.

[5:12] Und ich habe das jetzt mal so ein bisschen aufgeteilt in zwei Bereiche.

[5:14] In einen großen allgemeinen Bereich rund um Git und die Versionsverwaltung.

[5:18] Und dann habe ich noch ein paar Fragen zusätzlich dazu, die für das Unternehmen interessant sind.

[5:22] Denn nur weil man jetzt Git anwenden kann, heißt das noch lange nicht, dass ich Git auch in meinem Unternehmen anwenden kann.

[5:27] Denn es gibt vielleicht noch mal so ein paar Konventionen oder Sachen, die man einfach wissen muss,

[5:30] um dann auch im eigenen Unternehmen mit Git oder einer anderen Versionsverwaltung vernünftig arbeiten zu können.

[5:34] Und die Fragen gehen wir dann am Ende auch noch mal kurz durch.

[5:37] Okay, ich beantworte die Fragen jetzt mal nicht super, mega detailliert.

[5:42] Denn ich versuche mal wieder, mich an die halbe Stunde zu halten.

[5:44] Gucken wir mal, ob ich das hinkriege.

[5:46] Und es soll halt keine riesen Leerzickertrolle werden,

[5:48] sondern die Idee dahinter ist ja eigentlich, dass man sich selber mit dem Thema auseinandersetzt.

[5:51] Und wenn du das vielleicht tun willst und dich erstmal selber damit beschäftigen willst,

[5:55] dann kannst du gerne die Episode hier mal kurz pausieren.

[5:58] Schaust dir das Tutorial an, bearbeitest das mal und kommst dann vielleicht wieder

[6:02] und hörst dir meine Antworten auf die Fragen an.

[6:04] Dann weißt du auch gleich, ob du es richtig verstanden hast oder nicht.

[6:07] Wäre eine Möglichkeit, wenn du das machen möchtest.

[6:09] Drück einfach jetzt auf Pause.

[6:11] Ansonsten fangen wir jetzt an mit den Fragen.

[6:14] Nummer eins auf meiner Liste.

[6:15] Wofür braucht man überhaupt eine Versionsverwaltungssoftware?

[6:18] Es gibt verschiedene Software da draußen, die Versionsverwaltung anbietet.

[6:22] Ich habe schon gesagt Git.

[6:23] Es gibt Subversion SVN abgekürzt.

[6:26] Es gibt den Team Foundation Server.

[6:27] Es gibt den Vorgänger von SVN, das CVS.

[6:30] Es gibt Mercurial, das so ähnlich ist wie Git und so weiter.

[6:33] Es gibt ganz verschiedene Möglichkeiten, wie man Versionsverwaltung betreiben kann.

[6:37] Die zentrale Frage ist, wofür brauche ich das überhaupt?

[6:39] Eigentlich ist es ganz egal, was für ein Tool man benutzt.

[6:42] Ich glaube, als Softwareentwickler kommt man nicht drum herum,

[6:44] unbedingt Versionsverwaltung zu benutzen.

[6:46] Die Frage ist jetzt aber, warum?

[6:48] Warum ist das so wichtig?

[6:49] Also eine Versionsverwaltungssoftware, wie der Name eigentlich schon sagt,

[6:51] verwaltet Versionen von irgendwelchen Dateien.

[6:54] Als Entwickler sind das halt meistens Source-Code-Dateien.

[6:57] Das muss aber nicht so sein.

[6:58] Ich kann auch andere Textdateien, was weiß ich, meine Word-Dokumente,

[7:01] meine Bilder, wie auch immer.

[7:03] Alles, wovon es vielleicht in Zukunft mehrere Versionen geben wird,

[7:06] kann ich damit verwalten.

[7:08] Mehr oder weniger gut.

[7:09] Am besten ist es natürlich für Textdateien geeignet,

[7:12] denn dann kann die Versionsverwaltungssoftware zum Beispiel

[7:14] nur die Differenzen, also das DIV oder die DELTAS,

[7:17] zwischen den einzelnen Versionen speichern.

[7:19] Und das kostet natürlich deutlich weniger Speicherplatz,

[7:21] als wenn er immer eine komplette neue Version,

[7:23] zum Beispiel eines JPEG-Bildes, anlegen muss.

[7:26] Da kann man halt schlechten DELTA machen.

[7:27] Dann muss er vielleicht die gesamte Datei nochmal kopieren

[7:30] und abspeichern.

[7:31] Dann habe ich natürlich bei zwei Versionen

[7:33] automatisch einen doppelten Speicherverbrauch.

[7:35] Bei Textdateien in GIT zum Beispiel ist es so,

[7:37] dass er nur die DELTAS, also die zusätzlichen Zeilen,

[7:39] zum Beispiel speichert.

[7:40] Und das ist natürlich kaum ein größerer Speicherverbrauch,

[7:43] als wenn ich die Datei einfach selber ablege.

[7:45] Von daher, man muss jetzt so ein bisschen schauen,

[7:47] was will ich denn überhaupt mit der Versionsverwaltung verwalten.

[7:49] Binäre Dateien bieten sich da nicht so an.

[7:51] Alles, was im Textformat vorliegt, ist eigentlich optimal zu versionieren.

[7:55] Und was bringt mir das jetzt?

[7:56] Ich kann also jederzeit sagen,

[7:57] ich erstelle jetzt eine neue Version meiner Dateien,

[8:00] speichere die ab meinetwegen und mache die so wiederherstellbar.

[8:04] Ich kann mir jederzeit angucken, wann habe ich was verändert?

[8:07] Wer hat das überhaupt geändert?

[8:08] Und wenn man eine vernünftige Commit-Nachricht,

[8:10] gucken wir uns mal an, was das ist, angibt,

[8:12] kann man auch sogar sehen, warum etwas verändert wurde.

[8:14] Also ich kann wirklich eine komplette Historie

[8:16] meiner Entwicklung bei einem Programm zum Beispiel mir anschauen.

[8:19] Oder wenn ich meinetwegen einen Text von meinem Azubi lese,

[8:22] dann kann ich den zum Beispiel Rechtscheidprüfung unterziehen,

[8:25] oder ich korrigiere da was rein oder schreibe da To-Do-Text rein.

[8:28] Und wenn dann der Azubi das Ding wieder aktualisiert,

[8:31] kann er genau die Unterschiede anschauen, die ich dort eingebaut habe.

[8:34] Und er muss halt nicht die 37 Seiten durchgucken,

[8:36] wo sich denn was geändert haben könnte,

[8:38] sondern die Software kann das direkt anzeigen.

[8:40] Ich habe also eine supergute Nachverfolgbarkeit

[8:42] und ich habe vor allem auch eine gewisse Persistenz.

[8:44] Wenn ich Sachen einmal gespeichert habe,

[8:46] dann sind sie auch gespeichert

[8:47] und die können mir auch nicht mehr verloren gehen.

[8:49] Also auch so ein bisschen Sicherung meiner Arbeit,

[8:53] wenn ich mehrere Stunden irgendwas programmiert habe,

[8:55] dann stelle ich das mal in die Versionsverwaltungssoftware ein

[8:57] und dann weiß ich sicher,

[8:59] dass ich jederzeit auf diesen Stand zurück kann.

[9:01] Wenn ich also irgendwas kaputt mache,

[9:02] zum Beispiel ich lösche aus Versehen eine Datei oder wie auch immer,

[9:05] dann kann ich über die Versionsverwaltung

[9:06] alles wieder herstellen, wie es mal war.

[9:08] Und das sind eigentlich unschlagbare Vorteile.

[9:10] Das brauche ich eigentlich unbedingt bei der Entwicklung,

[9:12] gerade wenn ich was Neues mal ausprobieren will.

[9:14] Ich will, was weiß ich,

[9:15] wenn es auch nur eine Methode umbenennen ist oder sowas.

[9:17] Und dabei geht mir irgendwas kaputt,

[9:19] dann habe ich über die Versionsverwaltungssoftware

[9:21] immer die Möglichkeit, das mit wenigen Befehlen,

[9:23] manchmal sogar mit wenigen Klicks,

[9:25] wenn ich so einen grafischen Editor dafür habe,

[9:27] das alles wieder herzustellen.

[9:28] Und wenn ich zum Beispiel auch irgendwo einen Bug gefunden habe

[9:30] in der Software,

[9:31] dann kann ich mit einer schönen Versionsverwaltung

[9:33] auch direkt sagen,

[9:34] wer hat denn diese Zeile in dieser Klasse

[9:36] zum Beispiel als letztes geändert.

[9:38] Und dann zeigt mir die Versionsverwaltung

[9:40] die gesamte Historie an,

[9:41] wer hat wann was geändert und warum

[9:43] und auch einen Kontext drumherum und alles.

[9:45] Also eine wirklich schöne Nachverfolgbarkeit,

[9:47] wenn es mal Fehler gibt oder ähnliches.

[9:49] Also das sind alles Vorteile,

[9:51] die so eine Versionsverwaltungssoftware hat.

[9:53] Das wäre auch gleich dann die nächste Frage,

[9:55] was sind denn die Vorteile einer Versionsverwaltungssoftware?

[9:57] Das ist im Prinzip das,

[9:58] was ich gerade alles beschrieben habe.

[10:00] Also das kann ich mit meinem Windows Explorer

[10:04] zum Beispiel nicht machen.

[10:05] Wenn ich jetzt Änderungen an einem von seines mache,

[10:07] klar, dann kann ich das kopieren

[10:08] und V1 und V2 und V3 dahinter schreiben,

[10:10] das ist alles toll.

[10:11] Wenn ich dann aber genau wissen will,

[10:13] wer hat wann was wie geändert,

[10:14] dann geht das natürlich damit nicht.

[10:16] Das heißt auch,

[10:17] ich glaube das hat auch so einen witzigen Namen,

[10:18] irgendwie sowas wie Zip-Versionsverwaltung oder sowas.

[10:22] Da wird einfach nach bestimmten Ständen der Ordner gesippt

[10:24] und irgendwie mit V1, V2, V3 umbenannt

[10:26] und dann habe ich da auch meine Versionsverwaltung.

[10:28] Bringt mir aber nichts,

[10:29] weil ich mir zum Beispiel auch gar nicht

[10:30] die Unterschiede angucken kann zwischen den Versionen.

[10:32] Ich kann halt nicht sehen, wer es gemacht hat,

[10:35] warum irgendwas gemacht wurde und so weiter.

[10:37] Es geht alles nicht

[10:38] und genau dafür brauche ich eine Versionsverwaltung.

[10:41] Die meisten Versionsverwaltungssoftware

[10:43] kann man halt auch mit irgendeiner Form von Web-Oberfläche

[10:45] zum Beispiel anbinden,

[10:46] dass ich also einfach im Browser

[10:47] durch die Sourcen durchklicken kann

[10:49] und ich kann mir highlighten,

[10:50] was sich da halt geändert hat.

[10:51] Ich werde irgendwie mit Grün und Rot darauf hingewiesen,

[10:54] ob Zeilen entfernt oder hinzugefügt wurden und so weiter.

[10:57] Das sind alles sehr, sehr wertvolle Geschichten,

[11:00] gerade wenn ich nach einem Fehler suche

[11:02] oder warum irgendwas auf einmal nicht mehr funktioniert,

[11:04] dann kann ich das über diese Historie,

[11:06] die ich da habe, jederzeit nachvollziehen.

[11:09] Gut, die dritte Frage ist,

[11:11] was ist SVN oder Subversion?

[11:13] Also SVN ist einfach nur die Abkürzung dafür.

[11:15] Das hat keine besondere Bedeutung.

[11:17] Und Subversion ist eine, ich sage mal,

[11:19] jetzt heutzutage schon recht alte Versionsverwaltung,

[11:22] die darauf basiert,

[11:24] dass sie immer mit einem Server kommunizieren muss.

[11:26] Das ist also eine zentrale Versionsverwaltungssoftware.

[11:29] Das bedeutet, ich arbeite auf meinem lokalen Client

[11:32] und programmiere da zum Beispiel in meinen Java-Sourcen

[11:34] oder C-Sharp oder Ruby-Sourcen, was auch immer, rum.

[11:37] Und wenn ich dann sage,

[11:38] so, jetzt habe ich eine wichtige Änderung fertig,

[11:40] dann kann ich das auf den Server übertragen.

[11:43] Der Server erstellt mir dann so eine neue Version

[11:46] und merkt sich dann, dass ich das war,

[11:48] wann ich das gemacht habe

[11:49] und auch noch eine Nachricht, die ich dazu angeben kann.

[11:52] Und der Nachteil dabei ist,

[11:53] dass ich immer mit diesem Server sprechen muss.

[11:55] Wenn der Server nicht erreichbar ist,

[11:56] dann habe ich ein Problem.

[11:58] Und das ist jetzt genau das, was Git besser macht.

[12:01] Das ist jetzt die Frage 4.

[12:02] Was ist jetzt Git?

[12:03] Git ist auch eine Versionsverwaltungssoftware,

[12:05] allerdings eine dezentrale Versionsverwaltungssoftware.

[12:08] Das bedeutet,

[12:09] ich muss nicht immer zwingend einen Server im Hintergrund haben,

[12:11] mit dem ich kommuniziere und wo ich meine Sachen hin kopiere,

[12:14] sondern ich habe alles bei mir auf der Festplatte liegen.

[12:16] Die gesamte Historie meines Projekts liegt auf meiner Festplatte.

[12:20] Das bedeutet auch,

[12:21] wenn ich keinen Server habe, mit dem ich reden kann,

[12:24] Beispiel immer so cool für Entwickler,

[12:26] die ständig auf irgendwelchen Konferenzen sind

[12:27] und im Flugzeug sitzen,

[12:28] dann können die auch,

[12:29] während sie kein WLAN oder UMTS oder LTE

[12:32] oder was auch immer hoffentlich haben im Flugzeug,

[12:34] ja, muss man den Flugzeugmodus anschalten,

[12:36] können sie trotzdem entwickeln und fleißig neue Versionen erzeugen,

[12:39] denn sie müssen halt nicht mit einem Server reden.

[12:41] Also diese, wie soll man sagen,

[12:43] so dass die lokale Entwicklung kann stattfinden,

[12:47] ohne dass ich mit irgendwem im Netzwerk sprechen muss.

[12:50] Das ist ein großer Vorteil von Git,

[12:52] der das System auch so erfolgreich gemacht hat,

[12:55] weil das halt wirklich ein Novum war.

[12:56] Alle mussten bei SVN immer auf den Server warten

[12:59] und dann ist das langsam und das Netzwerk hängt

[13:01] und bei Git kann ich eben zack, zack, zack alles lokal machen.

[13:04] Das heißt, es ist super schnell im Vergleich zu SVN auch

[13:07] und ich habe halt alles, was ich machen will,

[13:09] bei mir lokal liegen

[13:10] und ich kann wirklich alle Vorteile,

[13:12] die mir die Versionsverwaltungssoftware bietet, nutzen,

[13:14] auch wenn ich zum Beispiel nicht im Netzwerk hänge.

[13:16] Das sind auch jetzt genau die Vorteile von Git gegenüber SVN.

[13:19] Das ist nämlich jetzt meine fünfte Frage.

[13:21] Was sind jetzt die Vorteile?

[13:22] Und der zentrale Vorteil ist eben,

[13:24] dass es dezentral ist,

[13:25] dass ich also keinen Server brauche,

[13:27] denn dadurch habe ich ganz konkrete Vorteile.

[13:29] Es ist einfach schneller,

[13:30] als wenn ich immer mit dem Server reden muss

[13:32] und ich kann halt auch offline arbeiten im Prinzip.

[13:35] Und das macht sich ganz schnell bemerkbar.

[13:37] Wenn ich mir zum Beispiel

[13:38] so eine Historie angucke von meinen Commits,

[13:40] dann dauert das bei Git irgendwie eine Sekunde

[13:42] und dann ist das alles da.

[13:43] Wenn ich mir das alles erst vom Server holen muss,

[13:45] dann warte ich da wirklich mehrere Sekunden teilweise,

[13:47] wenn ich einen langsamen Server habe

[13:49] oder ein großes Repo auch ein paar Minuten,

[13:51] bis er dann mal die Historie abgerufen hat.

[13:53] Und bei jeder kleinen Fitzelaktion

[13:55] muss ich mit dem Server reden.

[13:56] Das heißt, wenn ich einen Diff mache,

[13:57] ein Diff ist also der Unterschied zwischen zwei Dateien,

[13:59] zum Beispiel in Version 1 und 2,

[14:01] dann geht er dafür auf den Server

[14:02] und guckt sich an, was hat sich denn da geändert.

[14:04] Das muss er alles hin und her transportieren.

[14:06] Es geht alles übers Netzwerk

[14:07] und das ist halt super lahmarschig.

[14:10] Zweiter Nachteil,

[14:11] wenn ich alles mit dem Server regeln muss, ist,

[14:13] dass wenn ich einmal mit dem Server Sachen abgeglichen habe,

[14:15] ich keine Möglichkeit mehr habe,

[14:16] das irgendwie rückgängig zu machen.

[14:18] Das heißt, wenn ich eine neue Version im Server erstellt habe,

[14:21] dann ist die fix

[14:22] und dann kann ich auch nicht mehr sagen,

[14:23] oh, ich habe noch was vergessen,

[14:24] ich habe irgendwie was falsch benannt

[14:26] oder ich habe noch eine Datei aus Versehen gelöscht

[14:28] oder was auch immer.

[14:29] Das kann ich alles nicht mehr ändern.

[14:30] Die Version ist festgeschrieben.

[14:32] Und wenn ich Git arbeite

[14:33] und ich habe eine neue Version erzeugt,

[14:35] die ich aber mit noch niemandem geteilt habe,

[14:37] also noch nie irgendwo auf dem Server

[14:38] oder sonst wo hingepackt habe,

[14:39] dann kann ich die immer noch komplett ändern.

[14:41] Weil alles auf meiner Festplatte liegt,

[14:43] habe ich jederzeit noch die Hoheit darüber

[14:45] und wenn ich irgendwas vergessen habe,

[14:46] irgendwas falsch gemacht habe,

[14:47] dann kann ich das noch korrigieren,

[14:49] bevor ich es dann vielleicht hochlade

[14:51] und mit meinen Arbeitskollegen teile.

[14:54] Und das ist auch ein wichtiger Vorteil,

[14:55] denn man glaubt gar nicht,

[14:56] wie oft sowas vorkommt,

[14:57] dass man dann tatsächlich mal irgendwie was vergessen hat.

[14:59] Dann hat man doch irgendwie eine Datei zu wenig eingecheckt

[15:01] und man wundert sich,

[15:02] warum geht es denn nicht mehr?

[15:03] Und das stellt man leider zu spät fest

[15:05] und muss es dann nochmal korrigieren.

[15:06] Und bei Subversion oder CVS oder so

[15:08] wäre das halt dann eben nicht mehr möglich.

[15:10] Und das ist immer eine ganz gute Idee,

[15:12] dass man, wenn man so eine Version erzeugt,

[15:14] immer nur eine lauffähige Version erzeugt

[15:16] und nicht irgendwas kaputtes eincheckt.

[15:18] Denn wenn jetzt zum Beispiel ein Arbeitskollege

[15:20] diese Version jetzt auscheckt aus der Versionsverwaltung,

[15:22] dann hat er erstmal ein nicht lauffähiges Programm zum Beispiel,

[15:25] weil irgendwelche Compile-Fehler meinetwegen noch drin sind.

[15:28] Und das wollen wir natürlich auf keinen Fall haben.

[15:30] Also eine ganz wichtige Richtlinie ist eigentlich bei diesen Versionen,

[15:33] die müssen immer lauffähig sein.

[15:35] Man darf also eigentlich auf keinen Fall

[15:37] irgendwas in die Versionsverwaltung reinpacken,

[15:39] was irgendwie Fehler enthält.

[15:40] Denn das macht dann,

[15:41] wenn quasi die ganze Abteilung einmal so ein Update macht

[15:44] und sich die neueste Version holt

[15:45] und bei keinem läuft das Programm mehr

[15:47] und alle regen sich tierisch auf,

[15:49] das wollen wir nicht haben.

[15:51] Deswegen am besten immer darauf achten,

[15:53] das muss auf jeden Fall lauffähig,

[15:55] zumindest baubar,

[15:56] also zumindest kompilierbar sein,

[15:58] was man da in die Versionsverwaltung packt.

[16:01] Okay, also Vorteile haben wir geklärt.

[16:03] Es ist eigentlich rattenschnell im Vergleich zu SVN,

[16:05] weil wir einfach keinen Server brauchen

[16:07] und wir können lokal arbeiten ohne irgendeine Netzwerkverbindung.

[16:10] Also ganz klasse.

[16:11] Okay, jetzt kommen wir mal so ein bisschen in Richtung der Fachbegriffe.

[16:14] Die Frage 6 auf meiner Liste ist,

[16:16] was ist ein Repository?

[16:18] Ein Repository, das ist ein toller englischer Begriff.

[16:21] Ich kürze das auch immer gerne mit Repo ab,

[16:23] weil Repository einfach so lang ist.

[16:25] Aber ein Repo, das ist quasi meine Datenbank der ganzen Versionen,

[16:30] die meine Versionsverwaltungssoftware so enthält.

[16:32] Bei Subversion und bei Git gibt es jeweils auch Repositories,

[16:36] die heißen auch wirklich so dann, ja, Repository.

[16:38] Bei Subversion liegt das Repository auf dem Server,

[16:41] bei Git liegt das Repository auf der lokalen Festplatte.

[16:44] Das hatte ich gerade halt schon erwähnt.

[16:46] Wenn ich irgendwas aus der Historie haben will,

[16:49] dann muss ich bei Subversion mit dem Server sprechen,

[16:51] weil nur der Server in seinem Repository

[16:54] diese ganzen Versionen hat.

[16:56] Bei Git ist es so, dass in dem lokalen Repository auf der Festplatte

[17:00] alle Informationen über die ganzen verschiedenen Versionen vorhanden sind.

[17:05] Ich kann deswegen lokal arbeiten.

[17:07] Es gibt bei Git durchaus aber die Möglichkeit,

[17:09] sich auch mit einem entfernten Remote-Repository abzugleichen.

[17:13] Das ist überhaupt kein Problem.

[17:14] Das wollen wir auch sogar haben.

[17:15] Ich will meine ganzen Sourcen gar nicht nur auf meiner Maschine haben,

[17:18] denn wenn die mal abbraucht, dann haben wir ein Riesenproblem.

[17:20] Aber es gibt halt eben nicht die Pflicht,

[17:22] die Sachen immer automatisch mit dem Server abzugleichen.

[17:25] Ich kann halt noch eine gewisse Zeit warten.

[17:27] Ich kann noch etwas optimieren, Fehler korrigieren,

[17:29] habe ich gerade gesagt.

[17:30] Alte Versionen, sage ich mal, korrigieren,

[17:32] bevor ich die dann mit den anderen teile und so weiter.

[17:34] Das geht bei Subversion nicht.

[17:36] Sobald ich eine Version erzeugt habe im Repository,

[17:39] dann ist die halt fix.

[17:41] Gut, das ist also das Repository, kann man sich so vorstellen,

[17:44] wie eine Art Datenbank.

[17:45] Bei Subversion und bei Git ist es allerdings so gelöst,

[17:48] dass da, ja doch, bei Subversion gibt es sogar die Möglichkeit,

[17:50] das auch in der Datenbank abzulegen.

[17:52] Aber der Standard ist, dass es einfach im Dateisystem liegt.

[17:54] Und bei Subversion und bei Git ist es sehr ähnlich.

[17:56] In neueren Versionen von Subversion gibt es einfach einen Ordner,

[17:59] der heißt .svn und bei Git heißt der Ordner .git.

[18:02] Und da drin liegt dieses Repository.

[18:05] Jetzt sind die beiden versionsweiten Systeme relativ unterschiedlich,

[18:08] wie sie ihre Dateien strukturieren.

[18:10] Aber im Prinzip kann man sich so vorstellen,

[18:12] dass für jede Version, die es da gibt,

[18:15] im Prinzip irgendwo ein Unterordner angelegt wird.

[18:17] Und da sind dann halt die Dateien drin in der jeweiligen Version,

[18:20] wie sie halt zu dieser Version gehören.

[18:22] Ganz so einfach ist es natürlich nicht.

[18:24] Ich habe gerade schon gesagt, die Versionsverwaltungssysteme,

[18:26] die speichern nicht unbedingt die ganzen Dateien,

[18:28] sondern teilweise auch nur die Deltas,

[18:29] was ja auch sinnvoll ist, um Platz zu sparen.

[18:31] Von daher, man kann es sich so grob so vorstellen, dass das so ist.

[18:34] Für jede Version gibt es einen Ordner,

[18:36] aber im Detail sieht es dann schon noch ein bisschen anders aus.

[18:39] Aber es ist jetzt so, wenn ich diesen .svn oder .git-Ordner löschen würde

[18:43] in meinem lokalen Arbeitsordner,

[18:47] dann wäre halt dieses Repository, diese Versionsinformationen verloren.

[18:51] Also gut aufpassen, diese Verzeichnisse müssen da sein.

[18:54] Die fangen standardmäßig immer mit einem Punkt an.

[18:56] Das weißt du vielleicht von Linux-Systemen.

[18:58] Da ist es so, dass Ordner, die mit einem Punkt beginnen,

[19:01] quasi standardmäßig unsichtbar sind, also nicht angezeigt werden.

[19:04] So eine Art versteckte Dateien ist das.

[19:06] Und das ist auch sinnvoll,

[19:07] denn ich will diesen Ordner am besten gar nicht anpacken.

[19:09] Ich sollte da auf keinen Fall selber drin rumwurschteln,

[19:11] denn dann mache ich vielleicht meine gesamte Versionsverwaltung kaputt.

[19:14] Also den Ordner am besten versteckt lassen oder ausblenden oder einfach ignorieren.

[19:19] Nicht reingehen und drin rum vorwirkeln, außer du weißt genau, was du tust.

[19:22] Sonst kann es sein, dass deine Versionsverwaltung nachher kaputt ist.

[19:25] Aber nur, dass du schon mal verstehst, wie es funktioniert.

[19:28] In deinem lokalen Arbeitsordner gibt es halt so einen Unterordner

[19:31] und da drin wird diese Versionsinformationen gespeichert.

[19:35] Bei Subversion nur quasi die aktuelle Version,

[19:38] bei Git das gesamte Repository, also alle Versionen, die es jemals gab zu diesem Ordner.

[19:44] So, jetzt stellen wir uns mal vor, es gibt tatsächlich schon irgendwo so einen Repository.

[19:48] Meinetwegen, du fängst jetzt in deinem Ausbildungsunternehmen an

[19:50] und sollst an irgendeinem Projekt mitarbeiten,

[19:52] dann gibt es das Projekt natürlich schon.

[19:54] Das heißt, irgendwo liegt so ein Repository rum

[19:56] und du musst dir jetzt quasi dieses Repository auf deine Festplatte kopieren,

[20:00] um dann damit arbeiten zu können, also zu programmieren zum Beispiel.

[20:03] Und da habe ich jetzt meine Frage 7 drauf ausgerichtet.

[20:06] Welche Befehle musst du ausführen, um dir einen Repository zu klonen?

[20:10] Ich habe jetzt schon genau den Sprachgebrauch von Git benutzt.

[20:13] Bislang habe ich auch so bei Subversion erzählt, wie das da funktioniert.

[20:16] Ich spare mir das jetzt mal für die nächsten paar Fragen.

[20:19] Denn Subversion, ja, wenn du es noch benutzt, kannst du dir sicherlich noch ein Tutorial dazu suchen.

[20:23] Ich will mich hier ja jetzt auf Git fokussieren.

[20:25] Also mache ich das jetzt mal nicht mehr so im Detail zu Subversion.

[20:28] Und bei Git heißt es halt klonen.

[20:31] Wenn ich mir ein entferntes Repository, also ein Remote-Repo herunterladen möchte

[20:36] und damit arbeiten möchte, dann heißt es klonen.

[20:39] Und dementsprechend heißt auch tatsächlich der Kommandozahlenbefehl von Git klonen.

[20:42] Ich gebe dann einfach ein git clone und dann die URL zu diesem Repository.

[20:47] Das kann irgendwo ein lokaler Pfad sein, das kann ein Letztlaufwerk sein, das kann eine HTTP, HTTPS-URL sein, das kann eine SSH-URL sein, Git unterstützt da ziemlich viele Protokolle und je nachdem, wie du Zugriff auf dieses Repo bekommst, sieht dann halt deine URL aus.

[21:03] Dazu habe ich nachher auch noch eine konkrete Frage, nämlich wie kommst du auf die Repos deines Ausbildungsbetriebs überhaupt? Das musst du natürlich dann in deinem Unternehmen klären, wie das überhaupt bei euch funktioniert.

[21:12] Ich gehe jetzt mal davon aus, dass wir die meisten Repos über HTTP erreichen, gerade wenn man sich so Plattformen wie GitHub zum Beispiel anschaut, die dominante Plattform für Git-Hosting im Internet und da läuft das alles über HTTP oder HTTPS und ich glaube, man kann es auch über SSH machen, aber ich sage jetzt einfach mal, der Standard, weil es so schön einfach ist und auch durch die meisten Firewalls durchgeht, ist es HTTP oder HTTPS.

[21:35] Dann sieht also der Befehl so aus, git clone und dann HTTP … mein tolles Repo .git zum Beispiel.

[21:42] Und das .git muss nicht dahinter stehen, weil es nur ein Beispiel, weil es häufig so ist, aber es ist einfach irgendeine URL zu diesem Pfad, wo das Repo liegt.

[21:50] Und was macht git dann? Klonen heißt wirklich, so wie das Klon Schaf, das heißt, man hat ein zweites Repository, was genau so aussieht wie das entfernte Repository, nur auf der lokalen Festplatte.

[22:01] Und das habe ich jetzt gerade gemacht. Das heißt, bei einem Klon erzeugt git wirklich eine komplette Kopie des entfernten Repositories bei mir auf der Festplatte.

[22:09] Und ich habe dann die komplette Historie aller Versionen, die es jemals gab und die in diesem Repo drin sind, bei mir auf der Platte.

[22:16] Deswegen kann das auch ein Momentchen dauern, wenn das Repo mal ein bisschen größer ist.

[22:19] Unser zentrales Repo, an dem alle unsere Entwickler zum Beispiel arbeiten, hat glaube ich inzwischen 10.000 Versionen.

[22:27] Und wir haben um die 20.000 oder 30.000 Module da drin, also einzelne Dateien da drin.

[22:32] Und bis man das geklont hat, da kann dann schon mal so ein bisschen Zeit vergehen.

[22:36] Das ist einfach so, weil einfach eine enorme Datenmenge über die Leitung muss.

[22:39] Allerdings macht git das schon sehr, sehr gut.

[22:41] Im Gegensatz zu Subversion, wo man teilweise die einzelnen Versionen mitzählen könnte, macht git das eigentlich ganz gut.

[22:48] Das ist also sehr stark optimiert und alles komprimiert und so weiter.

[22:52] Also es funktioniert relativ schnell und relativ gut, sich so ein Repo zu klonen.

[22:56] Man muss nicht allzu lange warten im Vergleich zu Subversion.

[22:59] Gut, also was mache ich jetzt?

[23:01] Git klonen und dann habe ich das komplette Repo bei mir auf der Festplatte und dann könnte ich loslegen.

[23:06] Aber mir fehlt noch ein ganz wichtiger Begriff und das ist jetzt die nächste Frage, die Frage 8.

[23:10] Was ist eine Arbeitskopie?

[23:12] Es ist ja ganz toll, wenn ich das Repository jetzt auf meiner Platte habe, aber mit dem Repository kann ich als Entwickler zum Beispiel eigentlich nichts anfangen.

[23:18] Wie gesagt, das ist wie so eine Art Datenbank, wo die ganzen alten Stände drin sind.

[23:22] Das ist auch eine tolle Sache, aber was ich ja brauche, ist der aktuellste Stand.

[23:26] Und zwar will ich meine Sourcen oder meine Textdateien oder was auch immer ja auch aufmachen können und bearbeiten können.

[23:30] Und wenn ich dafür jetzt immer in so eine Datenbank, in Anführungszeichen, reingehen müsste, wäre das vielleicht ein bisschen schwierig.

[23:35] Ich brauche natürlich irgendwo Dateien, die auf meiner Festplatte liegen.

[23:38] Und hier kommt genau das nächste ins Spiel, nämlich die Arbeitskopie.

[23:41] Was git jetzt zum Beispiel bei einem Klon automatisch macht?

[23:46] Ich weiß, also alles, was ich hier erzähle, muss man eigentlich immer mit einem kleinen Sternchen versehen.

[23:51] So im Normalfall ist das so, weil man bei git glaube ich auch so ziemlich alles, was git irgendwie kann, mit 37 Parametern so konfigurieren kann, dass das ganz anders macht, als erwartet.

[24:00] Aber im Normalfall ist es so, dass git bei einem Klon automatisch auch eine Arbeitskopie davon anlegt.

[24:06] Was heißt das?

[24:07] Git nimmt die letzte Version aus dem Repository und checkt das aus.

[24:11] So kann man das auch nennen und packt das in ein Verzeichnis, eben in diese Arbeitskopie, sodass du quasi im Hintergrund das Repository hast, in diesem Punkt Git-Ordner und die ganzen Versionen auch dir anschauen könntest.

[24:23] Aber die letzte, die neueste, die aktuellste Version, die liegt wirklich auch ausgecheckt in Sourceform auf der Festplatte und du kannst damit direkt arbeiten, als wenn du ja das Projekt gerade selber angelegt hättest.

[24:36] Das ist diese Arbeitskopie und das darf man jetzt nicht durcheinander bringen.

[24:39] Die Arbeitskopie, das ist ein Verzeichnis, wo nur die aktuellste Version drin liegt, beziehungsweise es kann auch eine alte sein, ich kann auch alte Versionen auschecken, aber eine konkrete Version liegt da drin und in meinem Repository liegen halt alle Versionen.

[24:51] Also das ist quasi die Datenbank im Hintergrund.

[24:54] Und bei Git kann ich jetzt ganz einfach sowas machen wie, check mir doch mal die Version XY aus, dann gebe ich so eine Nummer an und dann geht der in das Repository rein, holt mir alle Dateien raus zu der jeweiligen Version und packt die in meine Arbeitskopie.

[25:06] Und so könnte ich zum Beispiel auch auf einem alten Stand meines Projekts arbeiten, was ausprobieren, ein Patch einspielen, was auch immer.

[25:13] Das kann ich also jederzeit machen. Normalerweise, sage ich mal 90% der Zeit, will ich ja weiterentwickeln.

[25:18] Das heißt, ich bleibe auf der neuesten Version, entwickle dann weiter und erzeuge halt neue Versionen obendrauf und pack die wieder in das Repository rein.

[25:26] Ich muss aber immer explizit diesen Schritt gehen.

[25:29] Wenn ich fertig bin mit der Entwicklung, muss ich die aktuelle Version wieder in das Repository reinbekommen.

[25:34] Dazu muss ich auch einen expliziten Befehl gleich ausführen, den gehen wir auch gleich durch.

[25:40] Das ist dann die übernächste Frage.

[25:42] Doch bis wir dahin gehen, vielleicht nochmal eine weitere Sache.

[25:45] Angenommen, ich würde jetzt nicht weiterentwickeln, sondern ich warte einfach darauf, dass meine Kollegen irgendwie noch an dem Projekt weiterentwickeln.

[25:52] Und ich möchte jetzt einfach die aktuellste Version von einem Remote Repository haben, weil meine Kollegen da schon irgendwas reingepackt haben.

[25:59] Also ich habe jetzt in der Zwischenzeit nichts gemacht, aber meine Kollegen haben fleißig weiterentwickelt und haben ihre neuen Versionen auch schon quasi hochgeladen.

[26:06] Dann möchte ich jetzt diese neuen Versionen auch auf meiner lokalen Festplatte haben, in meiner Arbeitskopie, damit ich halt eben nicht auf einem alten Stand arbeite, sondern auf dem neuesten.

[26:14] Und in diese Richtung geht jetzt meine Frage 9.

[26:17] Welche Befehle musst du ausführen, um deine Arbeitskopie aus einem entfernten Repository zu aktualisieren?

[26:22] Die Frage ist eigentlich so ein bisschen unscharf.

[26:25] Eigentlich aktualisiere ich nicht meine Arbeitskopie, sondern ich aktualisiere mein lokales Repository und hole mir alle Versionen aus dem entfernten Repository in mein lokales Repository.

[26:36] Und dann kann ich sagen, aktualisieren wir bitte meine Arbeitskopie auf die letzte Version.

[26:41] Aber da Git das genau so macht mit einem einzigen Befehl im Standard, ist die Frage jetzt so ein bisschen, wie kriege ich jetzt die neueste Version in meine Arbeitskopie?

[26:51] Und das mache ich mit einem simplen Befehl in Git, und zwar Git Pull.

[26:55] Pull im Gegensatz zu Push, das ist eigentlich ganz gut benannt.

[26:59] Ein Pull ist nämlich, ich hole mir etwas von einem Remote Repository, also ich ziehe das zu mir runter im Prinzip.

[27:06] Und ein Push ist das Gegenteil.

[27:08] Ich schiebe es in das Remote Repository rein, also ich lade es hoch auf einen Server zum Beispiel.

[27:14] Und mit diesem Pull, da macht Git jetzt folgendes, geht auf das Remote Repo, zieht sich alle Versionen, die er selber noch nicht hat in seinem lokalen Repo, kopiert die in das lokale Repo rein.

[27:23] Sodass danach das entfernte und das lokale Repository im gleichen Zustand sind, alle Versionen identisch haben.

[27:29] Und dann nimmt er die letzte Version aus dem lokalen Repo und packt die dann in die Arbeitskopie.

[27:35] Und als Ergebnis ist es dann halt so, dass ich auf dem letzten Stand des Repositories weiterarbeiten kann und habe jetzt halt eben alle Änderungen, die seit dem letzten Pull oder seit dem letzten Clone passiert sind und die ich bislang noch nicht mitbekommen habe.

[27:49] Okay, ich schaue mal auf die Uhr, stelle fest, es sind schon fast 30 Minuten wieder rum, aber eine letzte Frage behandle ich noch, und das ist auch eine sehr wichtige Frage.

[27:57] Nummer 10, was ist ein Commit?

[28:00] Ich habe bislang immer nur von Versionen gesprochen, und das ist auch grundsätzlich okay, wenn man über Versionsverwaltungssoftware spricht.

[28:07] Aber die unterschiedlichen Versionsverwaltungssysteme haben durchaus auch einen speziellen Namen für so eine Version.

[28:13] Und bei Git heißt das Commit. Ein Commit, das ist so eine Version, die ich angelegt habe.

[28:19] Bei Subversion heißen diese Versionen Revisions.

[28:22] Das ist auch eher so ein Begriff, den man mit Version in Verbindung bringt. Ja, Revision und Version ist schon sehr ähnlich.

[28:29] Und Revision auf Englisch, so heißt halt so eine Version bei Subversion.

[28:33] Und bei Subversion haben diese Versionen auch schöne Nummern, die kann man sich als Mensch sogar fast merken.

[28:38] Die sind nämlich einfach aufsteigend.

[28:39] Bei Subversion ist es immer so, dass die Revisions einfach durchnummeriert werden.

[28:43] Die erste Revision kriegt die Nummer 1, die zweite die 2, 3, 4 und so weiter.

[28:47] Das heißt, man kann anhand der Revision schon ganz gut sehen, auf welchem Stand ich gerade bin.

[28:51] Und wenn ich bei Revision 7000 irgendwas bin, dann weiß ich, oh Mensch, es gibt 7000 Versionen.

[28:56] Bei Git ist das ein bisschen anders. Bei Git wird nicht hochgezählt.

[28:59] Bei Git werden diese Commits nämlich mit einem Hash versehen.

[29:03] Und dieser Hash ist quasi dann der Name oder der Schlüssel, die ID für diesen Commit.

[29:09] Was wird da für ein Hash benutzt?

[29:11] Ein Hash übrigens, falls du es nicht genau weißt, ist eine mathematische Einwegfunktion,

[29:15] die aus einem Text variabler Länge eine Zeichenkette fixer Länge macht.

[29:23] Was bringt das?

[29:25] Man kann das auch übersetzen mit Prüfsumme.

[29:27] Ein Hash-Verfahren kann man wunderbar benutzen, um zum Beispiel bei E-Mails zu prüfen,

[29:31] ob die E-Mail auf dem Weg vom Sender zum Empfänger verändert wurde.

[29:35] Wenn der Sender einen Hash über die E-Mail baut, dann ist das quasi eine Prüfsumme.

[29:40] Und wenn der Empfänger auch den Hash noch mal erzeugt und er hat die gleiche Prüfsumme,

[29:44] dann weiß man, aha, diese E-Mail wurde nicht verändert.

[29:46] Und im Prinzip ist das das Gleiche hier bei Git.

[29:48] Hier geht es eigentlich nicht darum, zu gucken, ob irgendwas verändert wurde,

[29:51] wobei doch auch beim Diff und so wird das auch dafür benutzt.

[29:54] Aber es ist im Prinzip einfach eine Möglichkeit, die Commits durchzunummerieren,

[29:59] wobei sie halt nicht nummeriert werden, sondern mit diesen Hashes versehen werden als ID.

[30:04] Die Hashes sind nicht allzu menschenlesbar.

[30:06] Das Hashverfahren, was bei Git benutzt wird, ist SHA256.

[30:09] Das erzeugt einen ziemlich langen Hash, wie du dir wahrscheinlich denken kannst, genau 256 Bit lang.

[30:15] Und das wird dann als Hexadezimalzahl abgelegt.

[30:18] Und das ist halt irgendeine wilde Kombination aus den Hexadezimalzeichen.

[30:23] Und das ist nicht unbedingt wunderbar gut zu merken für Menschen.

[30:26] Aber darüber brauchen wir uns gar nicht lange aufregen.

[30:28] So ist das einfach bei Git. Damit muss man leben.

[30:31] Also überall, wo du so einen Hash siehst, weißt du eigentlich, aha, das ist eigentlich eine Versionsnummer.

[30:36] Das Doofe bei diesen Hashes ist, dass sie nicht aufsteigend sind.

[30:39] Die Hashes, wenn die berechnet werden, die folgen keinem besonderen Muster,

[30:43] dass ich sagen kann, der eine Hash ist größer als der andere.

[30:45] Das wäre nämlich doof.

[30:46] Dann könnte man nämlich einen Rückschluss auf die Daten, die da reingegangen sind, ziehen.

[30:50] Und das soll bei Hashverfahren eigentlich grundsätzlich nicht möglich sein.

[30:53] Im Gegenteil, wenn ich eine Kleinigkeit verändere, ist es bei einem guten Hashverfahren sogar so,

[30:57] dass sich der komplette Hash verändert.

[30:59] Also wenn ich beispielsweise einen Hash bilde über eine E-Mail, die ich geschrieben habe,

[31:04] und ich verändere nur ein kleines Bit, dann sollte sich der Hash über diese kleine veränderte Mail komplett ändern,

[31:09] damit ich sofort erkennen kann, dass sich was verändert hat.

[31:12] Das ist eine ganz wichtige Eigenschaft eines guten Hashverfahrens.

[31:15] Denn wenn sich zum Beispiel bei einem Hash dann nur die 37. Stelle ändert,

[31:18] dann sieht der Mensch gar nicht mehr sofort, dass da irgendwo was manipuliert wurde.

[31:21] Deswegen ist es sogar sinnvoll, dass sich Hashes sehr stark unterscheiden,

[31:25] auch wenn sich nur Kleinigkeiten bei den Eingangsdaten verändert haben.

[31:28] Und das führt jetzt dazu, dass die Hashes halt eben nicht alle schön aufsteigend sind,

[31:32] sondern dass die einfach wild durch die Gegend springen im Prinzip.

[31:35] Also man kann nicht anhand einer Commit-ID, anhand dieser Hash-Summe herausfinden,

[31:40] ob es jetzt ein alter oder ein neuer oder ein mittlerer Commit ist.

[31:42] Im Gegenteil, die sagt einfach gar nichts aus.

[31:45] Um jetzt aber nochmal zurück auf die Frage zu kommen, was ist denn jetzt ein Commit?

[31:48] Also ein Commit bei Git ist jetzt halt so eine Version und Git zählt einiges zu dieser Version dazu.

[31:54] Bei Git zählt zum Beispiel der Autor, der Zeitpunkt des Erstellens dieser Version,

[31:59] dann der Inhalt natürlich der Arbeitskopie zu diesem Zeitpunkt dazu.

[32:03] Dann kann man eine Commit-Nachricht angeben, die der Autor verfassen kann,

[32:07] da werden wir noch drauf eingehen, die zählt mit zu dem Commit dazu.

[32:10] Und es zählt insbesondere auch dazu der Parent-Commit, also quasi der Eltern-Commit,

[32:15] also dass es der Commit, von dem der aktuelle Commit abstammt.

[32:19] Wenn ich zum Beispiel bei Subversion meine Version 2 angelegt habe

[32:22] und ich erzeuge einen neuen Commit, dann habe ich danach die Version 3.

[32:25] Das heißt, die Version 3 basiert auf meiner Version 2.

[32:28] Und so ist es bei Git auch, nur dass ich halt keine schönen aufsteigenden IDs habe.

[32:32] Deswegen muss ich mir irgendwie anders merken, was ist denn jetzt der Vorgänger-Commit quasi.

[32:37] Und das heißt bei Git halt eben Parent-Commit.

[32:39] Es kann auch durchaus zwei Parent-Commits geben, es muss nicht nur einen geben.

[32:42] Warum und was das bringt, das werden wir noch kennenlernen.

[32:45] Auf jeden Fall gehört das auch definitiv mit zu diesem Commit dazu.

[32:49] Und alle diese Informationen, Autor, Uhrzeit, Parent und alles, was ich gerade gesagt habe,

[32:53] die werden jetzt quasi zusammengenommen auf eine bestimmte Art und Weise und darüber wird der Hash gebildet.

[32:59] Und dieser Hash wird dann der Schlüssel dieses Commits, also quasi die Commit-ID

[33:05] und damit wird dann auch dieser Commit im Repository abgelegt.

[33:09] Wenn du einmal einen Commit erstellt hast mit Git, dann kannst du immer darauf wieder zugreifen.

[33:14] Der kann also nicht mehr verloren gehen, der ist jetzt in dieser Datenbank persistiert

[33:18] und ich kann jederzeit mit bestimmten Git-Mitteln wieder darauf zurückgehen

[33:23] und mir das anzeigen, anschauen, was sich geändert hat und so weiter.

[33:26] Also wenn ich irgendwie in Git etwas festschreiben will, wenn ich mir eine Version erzeugen will,

[33:31] dann erstelle ich einen Commit, kriege so eine Hash-Nummer, die dann der Schlüssel dieses Commits wird

[33:37] und da drin sind dann alle Informationen gespeichert, die ich gerade aufgezählt habe,

[33:41] um halt genau nachverfolgen zu können, was wurde denn da geändert und wann und so weiter.

[33:45] Okay, so, dann haben wir schon mal das Wichtigste für heute geklärt, was ist ein Commit

[33:49] und wir können jetzt hier an der Stelle mal einen kurzen Break machen

[33:52] und machen dann nächste Woche weiter mit der Git-Einführung.

[33:55] Zehn Fragen schon mal geschafft.

[33:57] Ich hätte deutlich mehr erwartet, aber ich quatsche immer viel zu viel.

[34:00] Okay, aber ich will das Thema ja auch ein bisschen intensiver behandeln,

[34:03] möchte ganz gern diese Podcast-Folgen auch in Zukunft meinen Azubis oder auch meinen Studenten,

[34:07] die das auch jedes Jahr immer wieder lernen müssen.

[34:10] Also nicht immer wieder jedes Jahr neu, aber jeder neue Jahrgang muss wieder Git lernen,

[34:14] um bei mir in der Vorlesung mitarbeiten zu können.

[34:16] Deswegen möchte ich denen das auch bereitstellen und von daher ist es für mich auch okay,

[34:19] wenn ich es ein bisschen ausführlicher mache.

[34:21] Ich spalte das aber mal auf, weil die Zeit jetzt schon deutlich über 30 Minuten liegt,

[34:24] deswegen machen wir nächste Woche dann weiter mit den nächsten Fragen.

[34:28] Die kannst du dir gerne auch schon mal runterladen.

[34:30] Wie gesagt, melde dich für Newsletter an und dann gehst du auf die Seite und kriegst alle Fragen.

[34:34] Dann kannst du vielleicht sogar bis nächste Woche das Tutorial schon durcharbeiten

[34:37] und wenn du dann dich selber prüfen willst, ob du es richtig verstanden hast,

[34:40] hörst du die nächste Episode an und vergleichst dann mal deine Antworten mit meinen.

[34:45] Die ersten 10 Fragen kannst du dir aber noch mal nachlesen

[34:48] und auch das Tutorial habe ich ja auch schon verlinkt, wie gesagt, in den Shownotes

[34:52] unter anmeldungsentwicklerpodcast.de.

[34:55] Wie schon gesagt für die 76. Episode.

[34:58] Wenn du da gerade schon unterwegs bist auf der Website,

[35:02] dann schau doch mal in meine Links der Woche vom letzten Mal.

[35:05] Da habe ich nämlich einen schönen Podcast für dich als Empfehlung bereitgestellt.

[35:09] Der heißt Together We Make IT.

[35:11] Und das ist so ein, wie der Name schon sagt, ein IT-Podcast,

[35:14] der erklärt sehr gut verständlich so grundsätzliche Begriffe aus der IT,

[35:19] wie zum Beispiel Firewall und Netzwerk und Cloud Computing war letztens Thema usw.

[35:24] Und das habe ich auch schon meinen eigenen Azubis empfohlen.

[35:27] Gerade für so grundsätzliche Sachen, die eigentlich jeder ITler kennen muss,

[35:30] ist es halt eine schöne Möglichkeit, sich in kurzen knappen Häppchen,

[35:33] ich glaube es sind meist so um die 20, 30 Minuten pro Episode,

[35:36] mal so ein paar grundlegende Sachen anzuschauen.

[35:38] Wenn du dir noch nicht zum Beispiel das Handbuch für Fachinformatiker angeguckt hast,

[35:41] wo das natürlich auch alles drin steht und du bist vielleicht eher der Audio-Mensch,

[35:45] so wie ich zum Beispiel, ich höre ja auch ständig irgendwelche Podcasts,

[35:48] dann kann ich dir den Podcast sehr empfehlen.

[35:50] Sind gute Sachen drin, die man auf jeden Fall auch für die Abschlussprüfungen benutzen kann.

[35:55] Viele gute Definitionen auch so von so Netzwerkthemen usw.

[35:58] Kannst dir mal reinhören, vielleicht ist das ja was für dich.

[36:01] Ansonsten hoffe ich, dass heute vielleicht ein bisschen was Spannendes dabei war.

[36:04] Ich finde Git ist ein ganz ganz wichtiges Thema.

[36:06] Jeder Softwareentwickler muss das Ding einfach beherrschen.

[36:08] Wenn man heutzutage irgendwo, was weiß ich, bei Open Source oder so mitarbeiten will,

[36:12] die arbeiten ja fast alle nur noch mit Git.

[36:14] Von daher guck dir das Ding unbedingt an und natürlich auch für dich selber.

[36:17] Sobald du eigentlich irgendwie was schreibst, wovon es mehr als eine Version geben wird,

[36:22] sei es ein Programm, ein Text, ein Blogartikel, was auch immer,

[36:25] das geht so einfach mit Git, das Zeug zu versionieren.

[36:28] Wenn du das installiert hast, kommen wir auch noch in einer der nächsten Fragen dazu.

[36:32] Man kann eigentlich gar nicht mehr ohne.

[36:35] Zumindest ich, ich versioniere alles, was ich irgendwie zeuge,

[36:38] was ich auch sichern will zum Beispiel, das mache ich alles mit Git,

[36:41] weil es halt so schön einfach ist, wenn man sich mal einmal damit beschäftigt hat.

[36:44] Und ich hoffe, wir konnten heute schon mal ein paar Sachen klären.

[36:46] Nächste Woche geht es dann noch ein bisschen weiter und geht noch ein bisschen in die Tiefe.

[36:49] Ich hoffe, das Thema bleibt dann spannend für dich

[36:52] und ich würde mich freuen, wenn du nächste Woche wieder reinhörst.

[36:55] Bis dahin sage ich erstmal für heute vielen, vielen Dank fürs Zuhören und bis zum nächsten Mal. Tschüss!