[0:01] Herzlich Willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker

[0:09] für Anwendungsentwicklung. In dieser Episode geht es weiter mit der Einführung in Git. Viel Spaß dabei!

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

[0:27] Mein Name ist Stefan Macke und heute geht es weiter mit meiner Einführung in Git.

[0:32] Wir hatten letzte Woche schon die ersten 10 Fragen rund um die Versionsverwaltung und Git im Speziellen behandelt.

[0:39] Und heute geht es weiter mit den restlichen Fragen. Und ich halte mich ran, um meine halbe Stunde einzuhalten.

[0:45] Deswegen legen wir direkt los. Letzte Woche sind wir aufgehört mit der Frage, was ist ein Commit?

[0:50] Und um nochmal kurz wieder reinzukommen, ein Commit ist also das, was bei Git alles enthält zu einer Version.

[0:56] Also zum Beispiel eine Nachricht, die Dateien, die verändert wurden, das Datum, der Autor, die Dateien natürlich dazugehören und so weiter.

[1:03] Und wir wollen uns jetzt heute mal damit befassen, wie wir so einen Commit erzeugen und was man alles vielleicht tun sollte, bevor man das tut.

[1:10] Und das ist jetzt die erste Frage heute und die 11. auf meiner Liste. Und zwar, welche Befehle musst du ausführen,

[1:17] um dir die aktuellen Änderungen in deiner Arbeitskopie anzuschauen? Warum ist das wichtig?

[1:22] Ja, einfach deswegen, weil das, was wir da jetzt geändert haben, ja Teil unseres Commits werden soll.

[1:27] Wir fangen irgendwie an, was zu entwickeln, ganz egal, ob wir neu anfangen oder bei einem bestehenden Projekt weitermachen.

[1:32] Irgendwann ist es Zeit und wir sagen, jetzt bin ich fertig mit dem, was ich machen wollte und ich möchte daraus einen Commit machen.

[1:38] Und dazu möchte ich mir vielleicht erst nochmal einmal angucken, was habe ich denn jetzt überhaupt geändert?

[1:42] Vielleicht habe ich jetzt ja drei Stunden lang da irgendwas vor mich hin entwickelt und hier ausprobiert und da wieder, keine Ahnung,

[1:47] was rückgängig gemacht und hier wieder was rein und hin und her. Und um jetzt wirklich zu gucken, was habe ich denn jetzt konkret geändert?

[1:52] Was wäre jetzt der Inhalt meines nächsten Commits? Dafür kann ich einen netten kleinen Befehl benutzen bei Git.

[1:59] Und dieser Befehl heißt Diff, D-I-F-F, also nicht zu verwechseln mit dem Diff aus HTML mit D-I-V,

[2:06] sondern hier geht es um das Diff, die Differenz zwischen der Arbeitskopie und dem, was im letzten Commit drin ist.

[2:13] Das heißt, ich möchte mir jetzt angucken, was habe ich in der Arbeitskopie geändert im Vergleich zum letzten Commit.

[2:20] Das Git Diff zeigt mir wirklich die Unterschiede der einzelnen Dateien an.

[2:25] Das heißt, wenn ich Dateien angelegt habe, verändert habe, gelöscht habe und so weiter,

[2:28] dann kann ich auf der Konsole wirklich Zeile für Zeile sehen, was hat sich verändert im Vergleich zur vorherigen Version.

[2:34] Da wird dann auch mit Rot und Grün schon dargestellt, ob was dazugekommen ist, was verändert wurde, was gelöscht wurde und so weiter.

[2:40] Und ich kann wirklich auf Inhaltsebene gucken, ist das denn jetzt alles richtig, was ich da gemacht habe.

[2:44] Ich kann also, ich sehe auch wirklich nur das, was ich verändert habe, nicht nochmal alle Dateien komplett,

[2:49] sondern es werden mir die Highlights, also die Highlights nicht, sondern das, was ich verändert habe, wird hervorgehoben,

[2:53] aber auch mit einem gewissen Kontext drumherum, sodass ich das also auch einordnen kann, was jetzt davor und danach steht.

[2:58] So zwei, drei Zeilen, das kann man zum Beispiel auch in Git konfigurieren, wie viele der anzeigen soll.

[3:02] Standardmäßig sind es, glaube ich, drei und ich kann also auch sehen, in welchem Kontext da irgendwas passiert ist.

[3:07] Das heißt, ich kann jetzt nochmal kontrollieren, sind die Inhalte denn jetzt richtig,

[3:10] habe ich da vielleicht irgendwo noch einen Rechtschreibfehler drin oder habe ich die Einrückung falsch oder wie auch immer.

[3:14] Das kann ich nochmal eben schnell auf der Konsole kontrollieren, bevor ich das jetzt gleich zu einem Commit mache.

[3:19] Und ein anderer Befehl, den man auch noch schön nutzen kann, der einem nur die Übersicht zeigt, welche Dateien sich verändert haben,

[3:24] aber nicht die Inhalte dieser Dateien.

[3:26] Also beispielsweise wird mir aufgelistet, Datei abc.txt wurde verändert, aber nicht, was verändert wurde.

[3:32] Das ist der Befehl Status.

[3:34] Also mit Git Status, S-T-A-T-U-S, Status, kann ich mir anzeigen, welche Dateien verändert wurden.

[3:40] Und mit Git Diff, D-I-F-F, kann ich mir wirklich auch die Inhalte dieser Dateien anschauen und gucken,

[3:46] was sich im Vergleich zum letzten Commit verändert hat.

[3:49] Und das sind eigentlich zwei Befehle, die ich eigentlich immer ausführe, bevor ich ein Commit mache,

[3:53] weil ich immer nicht genau weiß, ob da noch vielleicht was dazugekommen ist, was ich gar nicht committen will usw.

[3:57] Das heißt, ich hab's quasi wirklich schon so im Muscle Memory, in der Muskelerinnerung,

[4:02] bevor ich ein Git Commit mache, mach ich immer Git Status, bzw. ich hab mir einen Shortcut dafür angelegt,

[4:07] Git S-T einfach nur, Git S-T, kann man schon da tippen.

[4:10] Dann zeigt die man, welche Dateien sich verändert haben, dann weiß ich schon mal, ob das passt oder nicht.

[4:13] Und sofort danach mach ich eigentlich ein Git Diff, um zu gucken, was die Inhalte angeht, ob das auch korrekt ist.

[4:19] Und wenn das dann beides korrekt ist, dann geht's los mit dem nächsten Schritt,

[4:22] nämlich mach meinen Commit bitte aus meinen Änderungen.

[4:25] Und das ist jetzt auch genau die nächste Frage, Nummer 12 auf der Liste.

[4:28] Welche Befehle musst du ausführen, um deine Änderungen zu committen?

[4:32] Und das ist jetzt bei Git relativ einfach, das heißt nämlich einfach Commit.

[4:35] Also Git, Commit und dann war's das.

[4:37] Und dann packt der alles, was, jetzt ist die große Frage, was in der Arbeitskopie ist, in den Commit.

[4:43] Nein, leider nicht, das wäre ja viel zu einfach, wenn er das machen würde.

[4:47] Deswegen müssen wir uns vorher noch etwas anderes anschauen, nämlich den sogenannten Index.

[4:51] Bei Subversion wären wir jetzt tatsächlich fertig.

[4:53] Wenn ich ein Commit mache bei Subversion, wird einfach alles, was sich in der Arbeitskopie verändert hat, auf den Server übertragen.

[4:59] Bei Git gibt es noch so eine Art Zwischenschritt, eine Art Zwischenebene oder auch Stage genannt, und zwar den Index.

[5:06] Der Index, das, was da drin ist, das wird in den nächsten Commit gepackt.

[5:10] Also es gibt bei Git im Prinzip ein dreistufiges Konzept.

[5:13] Es gibt einmal meine Arbeitskopie, das ist das, was wirklich in dem Ordner auf der Festplatte liegt.

[5:18] Dann gibt es den Index, da kann ich selektiv Sachen aus der Arbeitskopie reinpacken, die dann committet werden.

[5:25] Und dann gibt es als letztes das Repository, wo halt meine fixen Commits, die ich schon erledigt habe, drin sind.

[5:32] Und ganz wichtig bei Git ist jetzt, dass nur das, was im Index ist, in den nächsten Commit kommt.

[5:37] Nicht automatisch alles, was in der Arbeitskopie ist.

[5:40] Was hat das für einen Vorteil?

[5:42] Ganz einfach, bei Subversion zum Beispiel konnte ich nur sagen, ich möchte die Änderung an dieser Datei komplett committen oder gar nicht.

[5:49] Wenn ich jetzt aber zum Beispiel drei, vier Stunden lang irgendwas entwickelt habe und bin endlich fertig,

[5:53] habe aber in diesen drei, vier Stunden leider zwei Features implementiert und nicht nur eins.

[5:58] Und ich möchte jetzt tatsächlich für das erste Feature nur die Sachen committen, die zu dem Feature dazugehören.

[6:03] Und nicht alle anderen auch, die zufällig in der gleichen Datei mit drin sind für Feature 2.

[6:07] Dann geht das bei Subversion nicht.

[6:09] Bei Git kann ich jetzt sagen, ich möchte gern aus der Datei nur die Zeilen, was weiß ich, 10 bis 20 in den Index packen.

[6:15] Und dann wird auch nur das committet und nicht alles, was in der Datei drin steht.

[6:19] Und das kann man auch auf Dateiebene machen, das heißt, ich kann in den Index eine Datei reinpacken, aber die andere nicht.

[6:23] Und ich kann also wirklich sehr selektiv sagen, was committet werden soll und was nicht.

[6:27] Ist übrigens auch eine ganz gute Idee, bei Git und bei jeder Versionsverwaltungssoftware so kleine Commits wie möglich machen.

[6:33] Also ein paar Zeilen reichen eigentlich schon.

[6:35] Das ist dann viel, viel einfacher zu beschreiben, was ich da eigentlich gemacht habe und warum.

[6:38] Und vor allem, da kommen wir dann später noch zu, wenn wir unsere Inhalte später mit den Änderungen anderer Entwickler zusammenbringen möchten,

[6:45] also die mergen möchten, dann ist es viel, viel einfacher, wenn ich nur kleine Änderungen habe,

[6:49] als wenn ich einen Commit gemacht habe, in dem ich 1000 Dateien geändert habe und 100.000 Zeilen dazukommen.

[6:54] Da blickt natürlich danach ja kein Mensch mehr durch.

[6:56] Deswegen kleine, feine Commits machen.

[6:59] Und deswegen ist es schon durchaus sinnvoll, dass man auch mal einzelne Zeilen aus einer Datei nur committet und nicht halt alles, was da drin ist.

[7:06] Weil es einfach zum Beispiel zu unterschiedlichen Features gehört.

[7:09] So, jetzt natürlich die zentrale Frage, wie kriege ich denn meine Inhalte in diesen Index rein?

[7:13] Und das ist bei Git der Befehl add.

[7:16] Also das wie addieren, hinzufügen, add.

[7:20] Das fügt jetzt bestimmte Änderungen in den Index ein.

[7:23] Wenn ich einfach alles hinzufügen will, was sehr oft der Fall ist, wenn ich vernünftig entwickle,

[7:27] mache ich einfach git add.

[7:30] Punkt für das aktuelle Verzeichnis auf Windows und Linux identisch.

[7:33] Und wenn ich auch Sachen hinzufügen will, die ich zum Beispiel gelöscht habe,

[7:37] dann bei add könnte man denken, dass er nur Sachen hinzufügt, was auch richtig ist.

[7:41] Wenn ich aber Dateien jetzt gelöscht habe, dann wird mir das add das nicht hinzufügen.

[7:44] Deswegen mache ich meistens noch einen Kommandozeilenparameter all dahinter.

[7:48] Und dann sieht die komplette Zeile so aus.

[7:50] Git add Punkt minus minus all.

[7:53] Und dann packt er alles, was sich verändert hat, egal ob gelöscht, manipuliert, hinzugefügt, wie auch immer, in diesen Index rein.

[7:59] Und als nächstes kann ich dann mit git commit meinen Commit abschicken und dann bin ich fertig.

[8:04] Beim Commit aber noch eine ganz wichtige Sache.

[8:06] Denn jeder Commit benötigt eine Commit-Nachricht.

[8:09] Ich muss als Entwickler da reinschreiben, warum habe ich diesen Commit gemacht.

[8:14] Ich muss in den Commit nicht reinschreiben, was ich gemacht habe, denn das speichert Git.

[8:17] Ich kann in Git einfach nachvollziehen, welche Dateien wurden verändert, was wurde genau geändert,

[8:21] wann wurde das geändert, wie hat es geändert.

[8:23] Das kann ich alles nachvollziehen, aber nicht, warum es geändert wurde.

[8:26] Und deswegen muss ich unbedingt als Mensch einmal eingreifen und aufschreiben, warum habe ich jetzt diesen Commit gemacht.

[8:32] Also eine fachliche Begründung im Prinzip abliefern.

[8:35] Und das passiert bei Git automatisch.

[8:37] Wenn ich git commit mache und nichts weiter angebe, dann geht der Texteditor meines Systems auf.

[8:42] In 99% der Fälle der VI übrigens.

[8:45] Eine ganz tolle Sache, wenn man sich nicht mit VI auskennt, kann man gar nicht committen,

[8:48] weil man gar nicht weiß, wie man die Datei verlässt.

[8:50] Aber das sind andere Probleme.

[8:53] Wenn ich diesen Editor nicht benutzen möchte, kann ich einfach machen git commit und dann "-m",

[8:57] m für message, und dahinter dann in Anführungszeichen meine Commit-Nachricht eingeben.

[9:01] Und dann bin ich eigentlich sofort fertig.

[9:03] Also wenn ich was committe und ich weiß schon, was ich committen will und warum,

[9:06] dann mache ich einfach git commit "-m", das ist mein toller Commit, und dann bin ich fertig.

[9:11] Er macht sofort den Commit, ohne den Editor aufzumachen, und dann bin ich damit durch.

[9:15] So, die nächste Frage habe ich quasi gerade schon angerissen.

[9:18] Das ist auf meiner Liste die Nummer 14.

[9:21] Wie ist eine sinnvolle Commit-Nachricht aufgebaut?

[9:24] Und da gibt es jetzt verschiedene Möglichkeiten, wie man das tun kann.

[9:28] Ich habe auch schon mal vor einiger Zeit einiges im Blog verlinkt zu einer guten Commit-Nachricht.

[9:33] Da schaust du am besten mal rein, das brauchen wir hier nicht im Detail durchkauen.

[9:36] Wichtig ist nur eigentlich das, was ich gerade gesagt habe.

[9:39] Es muss drinstehen, warum ich etwas gemacht habe.

[9:42] Was ist die Begründung dafür und nicht, wie ich etwas gemacht habe.

[9:45] Denn das kann ich halt in der Visionsverwaltungssoftware viel besser nachvollziehen.

[9:48] Ich kann einen Diff machen, und er zeigt mir genau die Zeilen an, die sich verändert haben.

[9:51] Das sagt mir aber nicht, warum ich das getan habe.

[9:54] Wollte der Fachbereich das anders haben, oder war da ein Bug, den ich fixen musste, oder, oder, oder.

[9:58] Also was ist die Anforderung, warum habe ich etwas getan?

[10:01] Das ist im Prinzip das, was mir das Versionsverwaltungssystem nicht beantworten kann.

[10:04] Das kann nur der Mensch, und deswegen müssen wir das in diese Commit-Nachricht reinschreiben.

[10:09] Wie man die jetzt genau aufbauen sollte, wie das Wording ist, oder wie man die Sätze strukturiert,

[10:13] und Zeilen und Buch und hin und her, das gehe ich jetzt nicht im Detail durch.

[10:16] Das haben andere schon besser gemacht, habe ich in den Shownotes verlinkt.

[10:19] Übrigens unter www.anwendungsentwicklerpodcast.de-77 für die 77. heutige Episode hier.

[10:25] Würde ich mir unbedingt mal angucken, da gibt es ein paar schöne Regeln, die man einhalten kann,

[10:29] und dann freuen sich auch die Kollegen, weil sie gut verstehen, was du mit der Message aussagen möchtest.

[10:34] So, jetzt haben wir einen tollen Commit gemacht und stellen fest,

[10:37] oh, ich habe etwas vergessen, oder ich habe etwas falsch geschrieben.

[10:40] Eine Commit-Nachricht, zum Beispiel Rechtschreibfehler drin, oder wie auch immer.

[10:43] Dann können wir jetzt einen der Vorteile von Git ausspielen, nämlich die Historie verändern.

[10:48] Wir können den letzten Commit, wenn wir ihn noch nicht in das Remote Repository übertragen haben,

[10:52] noch jederzeit anpassen und korrigieren.

[10:54] Das ist ein ganz tolles Feature von Git und das würde ich auch deswegen unbedingt hier heute mal durchsprechen.

[10:59] Und der Befehl dafür ist relativ einfach.

[11:02] Wenn ich jetzt einen Commit abgesetzt habe, ich habe noch nichts weiter wieder verändert,

[11:05] also ich bin jetzt nicht schon wieder angefangen und habe 37 andere Sachen weiter programmiert,

[11:08] sondern mir fällt das jetzt direkt auf und ich habe meine Arbeitskopie quasi auf dem Stand des letzten Commits.

[11:13] Ohne zusätzliche Änderungen kann ich relativ einfach mit dem Befehl

[11:17] Git Commit – Amend, A-M-E-N-D, den Inhalt des letzten Commits bearbeiten.

[11:23] Wenn ich das einfach nur so eingebe, dann geht ein Editor auf, wieder mal der VI meistens,

[11:28] und ich kann zum Beispiel meine Commit-Nachricht bearbeiten

[11:31] oder ich kann auch Dateien ein- und ausschließen aus dem Commit und so weiter.

[11:35] Das ist ein sehr einfacher Befehl und häufig, wenn ich mir einfach nur vertippt habe,

[11:39] dann ist das relativ schnell gemacht.

[11:40] Ich kann das ganz einfach korrigieren mit dem Git Commit – Amend.

[11:45] Wenn wir jetzt aber tatsächlich fertig sind und wir haben auch keinen Fehler gemacht

[11:48] und wir sind uns sicher, jetzt kann das Zeug auch meinen Entwicklerkollegen bereitgestellt werden

[11:52] und ich möchte das auf das Remote Repository übertragen,

[11:55] dann ist jetzt Frage 16, welche Befehle muss man denn dafür ausführen?

[11:59] Wie kriege ich meine Commits in das entfernte Repository?

[12:02] Und analog zu dem Git Pull, das wir schon kennengelernt haben,

[12:05] um Änderungen aus dem entfernten Repository herunterzuladen, ist das jetzt genau Git Push.

[12:11] Damit lade ich meine Sachen auf das Remote Repository hoch.

[12:15] Bei Git ist es jetzt so, es kann nicht nur ein Remote Repository geben, ich kann auch mehrere anlegen.

[12:19] Von daher wäre der komplette Befehl, den ich eigentlich ausführen müsste,

[12:23] um gegen das Standard Remote Repository zu pushen, Git Push Origin Master.

[12:29] Was das aber alles im Konkreten heißt, wollen wir jetzt hier gar nicht durchgehen.

[12:33] Wenn das Git vernünftig konfiguriert ist und du nur einen Remote Repository hast,

[12:37] reicht ein Git Push aus und dann packt er deine Änderungen, deine letzten Commits,

[12:42] die noch nicht übertragen wurden, automatisch in das Remote Repository.

[12:46] Jetzt ist es so, wenn du etwas in das Remote Repository übertragen möchtest,

[12:50] kann es ja durchaus sein, dass in der Zwischenzeit, wo du angefangen hast zu entwickeln und jetzt fertig bist,

[12:55] auch ein anderer Kollege weiterentwickelt hat und in das Remote Repository schon mal was reingepusht hat.

[13:00] Das ist durchaus normal, weil ihr da irgendwie gleichzeitig arbeitet.

[13:03] Und wenn man zum Beispiel mit 20 Kollegen in einem Projekt arbeitet,

[13:06] dann kann es einfach durchaus sein, dass jemand anderes auch mal was verändert hat und auch das schon gepusht hat.

[13:10] Deswegen ist es eigentlich sehr, sehr ratsam, vor jedem Push auch einen Pull zu machen,

[13:14] um sich alle Änderungen, die eventuell schon remote im Repository drin sind,

[13:18] nochmal auf die Festplatte zu übertragen.

[13:20] Das musst du nicht tun.

[13:22] Aber wenn du zum Beispiel pushst und jemand anders hat vor dir schon was Neues gepusht,

[13:27] dann wird Git dir erst mal sagen, Moment mal, geht nicht.

[13:29] Es gibt im Remote Repository noch Änderungen, die du lokal bei dir noch nicht kennst.

[13:33] Du kannst jetzt nicht pushen.

[13:35] Das heißt, du musst sowieso in diesem Fall dann immer einen Pull machen.

[13:38] Wenn du jetzt also mit dem Repo arbeitest, wo zum Beispiel du alleine drauf bist oder es einfach nicht so viele Pushes gibt,

[13:43] kannst du auch einfach direkt einen Git-Push machen.

[13:45] Ich habe es mir inzwischen schon angewöhnt, vor jedem Push automatisch immer einen Pull zu machen,

[13:50] weil das sowieso ganz häufig jedenfalls bei den Repos, mit denen ich arbeite, vorkommt,

[13:53] weil halt ständig Kollegen damit arbeiten und alles.

[13:55] Und dieses Pushen, das dauert auch einen kleinen Moment.

[13:59] Und dann kriege ich als Fehlermeldung, ah, da hat schon jemand anders gepusht.

[14:02] Von daher, diese Zeit kann ich mir sparen.

[14:04] Ich mache sofort einen Git-Pull und sofort danach einen Push und dann habe ich alles übertragen.

[14:08] Und weil ich das so häufig mache, habe ich mir dafür sogar ein Alias angelegt.

[14:11] Mit Git-PP für Push-Pull, beziehungsweise umgekehrt Pull-Push, macht Git genau das.

[14:16] Erst einen Pull und dann einen Push und so kann ich auf jeden Fall meine Sachen relativ einfach übertragen,

[14:20] ohne viel Text eingeben zu müssen.

[14:22] Wie man ein Alias definiert, das ist jetzt hier nicht Thema im Podcast, das erkläre ich auch nicht,

[14:26] aber das findest du sicherlich mit einer Google-Suche ganz einfach raus.

[14:28] Das ist ein kleiner Eintrag in einer Config-Datei und dann kannst du dir deine eigenen Alias-Befehle anlegen.

[14:33] Okay, jetzt haben wir schon fleißig unsere Änderungen committed und gepusht.

[14:37] Das heißt, wir haben uns jetzt auch mit dem Remote Repository abgeglichen.

[14:40] Wir haben vielleicht auch gerade einen Pull gemacht und Änderungen von Kollegen heruntergeladen.

[14:44] Und jetzt möchte ich einfach mal gucken, was wurde denn eigentlich in unserem Repository so in letzter Zeit geändert?

[14:49] Also wie kann ich mir jetzt tatsächlich die Historie meines Repos anschauen?

[14:52] Und das ist ein relativ einfacher Befehl, Git-Log.

[14:55] Und zwar L-O-G, also wie Log-Einträge in einem Logbuch.

[15:00] Und damit zeigt mir Git jetzt einfach alle Commits der letzten Zeit an, und zwar historisch absteigen.

[15:07] Das heißt, die neuesten sind dann oben.

[15:08] Und ich kann dann einfach durchscrollen im Prinzip und mir genau angucken, wer hat was wann verändert.

[15:14] Und am besten auch warum, denn das steht ja in der Commit-Nachricht drin.

[15:17] Also Git zeigt mir dann eine schöne, lesbare Variante an.

[15:20] Und ich kann halt schnell herausfinden, was dann in letzter Zeit so passiert ist.

[15:24] Wenn ich jetzt zum Beispiel feststelle, da ist ein interessanter Commit drin, da würde ich mir jetzt gerne mal was angucken.

[15:30] Den möchte ich mir jetzt mal anschauen, den möchte ich auschecken, sage ich mal.

[15:33] Also meine Arbeitskopie auf diesen einen Stand des Commits einfach zurücksetzen, um da drin jetzt mal was auszuprobieren oder sowas.

[15:39] Angenommen, ich habe eine alte Version, ich möchte jetzt da irgendwas drin patchen oder wie auch immer.

[15:43] Wie kriege ich jetzt meine Arbeitskopie auf diesen alten Stand eines Commits zurückgesetzt?

[15:48] Und das ist jetzt genau die nächste Frage, die Nummer 18 auf meiner Liste.

[15:52] Welchen Befehl muss man ausführen, um den Inhalt der Arbeitskopie auf einen alten Commit-Stand zurückzusetzen?

[15:58] Das ist jetzt eine Frage, da kann man alleine, glaube ich, eine halbe Stunde darüber reden.

[16:02] Weil Git so viele verschiedene Möglichkeiten hat, Sachen quasi auszuchecken, aber den Index nicht zurückzusetzen

[16:08] oder doch oder Arbeitskopie auf Index und hin und her.

[16:11] Es gibt so viele verschiedene Kombinationen.

[16:13] Ich nehme jetzt mal nur einen Befehl, der auf jeden Fall funktioniert und in den meisten Fällen das tut, was er soll,

[16:18] nämlich dir die Arbeitskopie auf einen alten Commit-Stand zurückzusetzen.

[16:22] Vorausgesetzt, du hast aktuell keine Änderungen in deiner Arbeitskopie, die du noch nicht committet hast.

[16:28] Das nennt man übrigens auch eine saubere Arbeitskopie.

[16:31] Wenn alles, was in deiner Arbeitskopie drin ist, auch in einem Commit ist und du also keine Änderungen mehr hast, die nicht committet wurden,

[16:37] dann hast du eine saubere Arbeitskopie und dann kannst du alle Befehle auch anwenden, um deinen Stand zurückzusetzen.

[16:43] Wenn du noch Dateien geändert hast in deiner Arbeitskopie, dann wird Git dir viele Befehle einfach nicht erlauben,

[16:48] weil er nämlich sagt, hey, wenn ich jetzt die Arbeitskopie zurücksetze, du hast aber noch Änderungen da drin,

[16:52] dann sind die Änderungen ja futsch.

[16:54] Und das möchte Git eigentlich immer verhindern.

[16:56] Also du musst ihn schon dazu zwingen, dir Sachen kaputt zu machen.

[17:00] Das ist eigentlich eine ganz tolle Sache.

[17:01] Du kannst eigentlich nur mit Aufwand die Sachen tatsächlich zerstören.

[17:05] Aber die Standardbefehle, die berücksichtigen das immer und die sagen ja immer,

[17:10] nö, mach ich nicht, du hast noch Änderungen.

[17:11] Sieh zu, dass du die committest oder selber zurücknimmst oder wie auch immer.

[17:14] Aber ich ändere hier nicht einfach deine Arbeitskopie und mach deine Arbeit kaputt.

[17:18] Da kann eigentlich bei Git relativ wenig schief gehen.

[17:21] Und der Befehl, mit dem man das jetzt recht einfach machen kann, ist tatsächlich git checkout.

[17:26] Mit git checkout kann man einen bestimmten Commit auschecken.

[17:31] So heißt es zum Beispiel auch bei Subversion.

[17:33] Bei Subversion ist aber etwas anderes damit gemeint.

[17:35] Bei Checkout bei Subversion bedeutet nämlich, dass du einen Repository klonst im Prinzip.

[17:41] Nur klonen gibt es ja bei Subversion nicht.

[17:43] Du hast das ganze Repo ja nicht auf der Festplatte, sondern nur die letzte Version.

[17:45] Deswegen heißt es bei Subversion einfach nur Checkout.

[17:48] Du holst dir also eine bestimmte Version aus deinem Subversion-Server herunter.

[17:55] Und bei Git heißt das halt klonen.

[17:57] Dafür heißt bei Git eben Checkout, dass du auf einen bestimmten Stand in deiner Arbeitskopie zurücksetzt.

[18:03] Das bedeutet also, dass er quasi in dein lokales Repository reingeht.

[18:06] Bei Git ist ja alles lokal.

[18:08] Er holt sich dann die Dateien, wie sie im Stand dieses Commits waren und packt die in deine Arbeitskopie.

[18:14] Und dann ist quasi dein Festplattenordner auf dem Stand dieses alten Commits.

[18:19] Und du kannst jetzt da drin machen, was du willst.

[18:21] Um den Stand jetzt auszuchecken, musst du dir aber noch sagen, welchen Commit du haben willst.

[18:25] Und das machst du über den Hash.

[18:27] Das heißt, am besten kannst du dir mit Git Log vorher angucken, welche Hashes gibt es denn da so.

[18:31] Dann kopierst du dir den Hash raus oder du tippst ihn ab, je nachdem, wie du Lust hast.

[18:35] Und sagst dann einfach Git Checkout und dann der Hash.

[18:38] Da der Hash jetzt aber eine sehr lange Hexadezimalzahl ist, ist es sehr ungünstig, das immer einzutippen.

[18:43] Und Git ist sehr intelligent.

[18:45] Der stellt nämlich fest, wann diese Hashes eindeutig sind.

[18:48] Die Hashes sind immer so unterschiedlich, dass es eigentlich reicht, die ersten paar Ziffern des Hashes einzugeben.

[18:54] Und je nachdem, welche dafür aussagekräftig genug sind, dann hört er auch auf und zeigt danach auch nicht mehr weitere Stellen an.

[19:01] Das heißt, du könntest auch ein Git Checkout und dann, ich sag mal, sechs bis sieben Ziffern eingeben.

[19:05] Das reicht in den meisten Fällen schon.

[19:07] Du musst nie diesen, ich glaube, es sind 40 Stellen langen Hash da eingeben.

[19:10] Die ersten paar reichen eigentlich schon aus, sofern die dann halt eben eindeutig sind über das gesamte Repository.

[19:17] Gut, damit können wir uns jetzt auch alte Sachen wieder angucken.

[19:20] Wunderbar, mit dem gleichen Befehl kann ich jetzt auch wieder zurück auf den letzten Commit gehen.

[19:24] Ja, also ich kann wunderbar damit hin und her springen und dann einfach weiterarbeiten.

[19:27] Und jetzt kommen wir noch zu so ein paar Begriffen, die eigentlich relativ wichtig sind.

[19:30] Auch bei jeder Versionsverwaltung, die gibt es auch fast überall.

[19:33] Und die gucken wir uns mal in Bezug auf Git an.

[19:35] Und zwar die Frage 19. Was ist ein Branch?

[19:38] Ein Branch, das englische Wort für Zweig, ist wie bei einem Baum tatsächlich.

[19:42] Ein Zweig, der von dem Stamm des Baums irgendwie zur Seite abweicht.

[19:46] Wenn man sich bei der Versionsverwaltung mal vorstellt, ich habe einen Strang meiner Versionen, die immer aufeinander aufbauen.

[19:52] Die bilden quasi den Stamm meines Programms meinetwegen.

[19:56] Und der wird immer weiterentwickelt und wird immer höher, dieser Baum im Prinzip.

[20:00] Ich kann jetzt aber zu einem beliebigen Zeitpunkt auch von diesem Stamm abweichen, quasi nach

[20:05] links oder nach rechts mal so einen Schlenker machen und einfach weiterentwickeln parallel

[20:09] zu der Weiterentwicklung des Stamms.

[20:11] Ich kann mir jetzt also so etwas vorstellen wie, ich habe meine Software, die wird immer

[20:15] fleißig weiterentwickelt, aber an einem bestimmten Zeitpunkt überlege ich mir jetzt, ich will

[20:18] mal ein neues Feature ausprobieren, ohne dass ich ständig an diesem Hauptstamm weiterarbeiten

[20:24] will.

[20:25] Ich zweige jetzt einfach mal ab in meinen ganz eigenen Branch, bastel da drin mal ein

[20:28] paar Sachen, mach mal 1, 2, 3, 4 Commits und wenn ich dann fertig bin damit, dann sage

[20:32] ich, okay, ich möchte das entweder wegschmeißen, weil es doof ist, oder ich will es übernehmen

[20:36] in den Stamm.

[20:37] Also mein Feature, was jetzt fertig ist, das packe ich jetzt wirklich zurück in das Hauptprogramm

[20:41] und dann wird quasi dieser abgezweigte, ja, Zweig wieder zurück in den Stamm überführt

[20:48] und kann dann also auch, dann kann ich dieses Feature, was ich da entwickelt habe, auch

[20:51] in dem Hauptstamm meines Programms dann benutzen.

[20:55] Und diese Branches, das ist ein tolles Feature in Git, weil die so leichtgewichtig sind.

[20:59] In Subversion heißt ein Branch die komplette Kopie des Repositories quasi anlegen und nochmal

[21:05] eins zu eins alle Sourcen neu in einen Commit reinzupacken, um dann weiterzuarbeiten.

[21:11] Das heißt, es ist enorm teuer.

[21:12] Wenn ich jetzt also auch diese Branches zum Beispiel wechseln will, dauert das ewig, weil

[21:16] er alle Dateien quasi hin und her kopieren muss.

[21:18] Bei Git ist das relativ simpel, das ist nämlich einfach nur so eine Art Zeiger auf einen bestimmten

[21:23] Commit und wir haben schon gelernt, dass Git sich bei jedem Commit immer merkt, was denn

[21:27] der Parent Commit ist.

[21:29] Und wenn ich jetzt einen Branch anlege, dann habe ich eigentlich nur einen neuen Commit,

[21:33] der auf den gleichen Parent zeigt wie irgendein anderer Commit, der in diesem Stamm läuft.

[21:38] Aber das interessiert diesen neuen Branch gar nicht, der muss dann nicht alles hin

[21:41] und her kopieren oder sonst was, der hat sich einfach nur gemerkt, woher komme ich denn.

[21:45] Und deswegen ist das auch super schnell gemacht.

[21:47] Wenn ich den Befehl eingebe git branch –b und dann gebe ich da irgendwie Namen ein zum

[21:51] Beispiel, dann habe ich diesen Branch angelegt und kann einfach weiterentwickeln.

[21:55] Das dauert nicht mal eine Sekunde, dann ist der fertig.

[21:57] Das ist also sehr, sehr einfach, diese Branches anzulegen und auch die Branches nachher wieder

[22:01] zurück in den Hauptstamm zu bekommen.

[22:04] Dieser Vorgang nennt sich dann übrigens Merge.

[22:07] Das ist dann gleich die nächste Frage auf meiner Liste.

[22:10] Also, wenn ich einen Zweig quasi angelegt habe und ich möchte den zurück in meinen

[22:14] Stamm bringen, dann nennt sich das Merge.

[22:17] Und der Commit, der dabei entsteht, ist auch ein Merge-Commit.

[22:20] Der hat nämlich dann zwei Parent-Commits.

[22:22] Wie sieht das aus?

[22:23] Stell dir mal vor, du hast so einen Stamm, das ist dein Hauptentwicklungszweig und irgendwann

[22:28] zweigst du dann halt ab, sag ich mal, nach rechts, wie so eine Bahnschiene, die nach

[22:32] rechts dann halt mal so eine Weiche hat und dann geht dann halt die zweite Bahnschiene

[22:35] weiter und dann hast du da Commit, Commit, Commit, Commit und irgendwann gehst du dann

[22:39] wieder zurück in den Hauptzweig.

[22:41] Also du hast mal so einen kleinen Schlenker gemacht, wie so eine Art Kurve und der soll

[22:44] jetzt wieder in den Hauptstamm übertragen werden, dann wird dieser Commit, der jetzt

[22:48] erzeugt wird, zwei Parent-Commits haben, nämlich einmal den Commit aus dem Stamm, den er schon

[22:53] kennt und jetzt dazu auch noch deinen letzten Commit aus dem Branch, den du angelegt hast.

[22:59] Und beides zusammengeführt ergibt jetzt den neuen Stamm.

[23:02] Das heißt, du hast die gesamte Entwicklung, die auf dem Stamm stattgefunden hat, in diesem

[23:07] Commit drin und zusätzlich auch alle Commits, die in deinem Branch stattgefunden haben.

[23:11] Das heißt, du hast jetzt wirklich beide Entwicklungszweige wieder zusammengeführt

[23:16] und dabei kann natürlich auch ein bisschen was schiefgehen.

[23:18] Wenn du nämlich Dateien in deinem Branch bearbeitet hast, die auch jemand anderes in

[23:22] dem Stamm bearbeitet hat, dann gibt es vielleicht Konflikte, denn du hast, was weiß ich, eine

[23:27] Variable auf den Wert 5 gesetzt und der andere hat sie auf den Wert 6 gesetzt.

[23:30] Was soll denn jetzt gewinnen?

[23:31] Das heißt, in diesem Fall musst du jetzt als Mensch zum Beispiel hergehen und die Sachen

[23:36] so ein bisschen auseinanderfrickeln bzw. zusammenführen, wenn Git das nicht von alleine machen kann.

[23:41] Git ist sehr, sehr intelligent.

[23:43] Der kann sehr gut automatisch mergen.

[23:46] Wenn du zum Beispiel Dateien bearbeitest, die im Stamm gar nicht bearbeitet wurden,

[23:50] dann musst du nichts weiter tun beim Merge.

[23:52] Der macht das einfach automatisch und alles ist auf dem neuesten Stand.

[23:55] Wenn du eine Datei bearbeitest, die auch im Stamm bearbeitet wurde, aber an einer anderen

[23:59] Stelle der Datei, meinetwegen du hast den Header verändert und der andere hat den Footer

[24:03] verändert, dann erkennt Git das auch automatisch und mergt die beiden Sachen einfach zusammen.

[24:08] Es wird dann halt der neue Footer und der neue Header benutzt.

[24:11] Bei Git musst du eigentlich nur manuell eingreifen, wenn irgendwo in derselben Zeile etwas verändert wurde.

[24:17] Also wenn du in deinem Branch in einer Zeile was verändert hast und jemand anders hat

[24:22] in dem Stamm in derselben Zeile in der Datei auch was verändert, dann kann Git natürlich

[24:27] nicht entscheiden, was ist denn jetzt das Richtige.

[24:29] Und dann musst du als Mensch eingreifen und sagen, ich will das oder das oder ich will

[24:33] noch was Drittes, weil keins von beiden richtig ist.

[24:36] Aber insgesamt ist dieses Branching und Merging mit Git sehr, sehr einfach und sehr, sehr

[24:40] schnell und sehr fehlertolerant vor allem auch und das ist auch etwas, was Git wirklich

[24:43] auszeichnet.

[24:44] Branching und Merging ist mit Git super einfach und super gut unterstützt, also wenn du vielleicht

[24:49] schon andere Versionsverwaltungssoftware kennen, wie zum Beispiel Subversion, das tut überhaupt

[24:54] nicht weh, einen Branch anzulegen, im Gegenteil, das ist so schnell gemacht, dass es eigentlich

[24:58] schon der Standard ist heutzutage, wenn ich ein neues Feature anlege, da gibt es zum Beispiel

[25:02] eine Branching-Strategie, wo ich sage, für jedes Feature wird ein Branch angelegt und

[25:07] am Ende wird das halt gemerged.

[25:08] Und da gibt es die wildesten Sachen, wie man so ein Branching machen kann, da gibt es auch

[25:12] gleich noch eine extra Frage zu, aber merkt ihr erstmal, das ist sehr, sehr billig, Git

[25:17] kann das super schnell und ich kann jederzeit auch die Sachen wieder zurücknehmen und so

[25:20] weiter, also da kann so gut wie nie was kaputt gehen, von daher ein zentrales Feature von

[25:25] Git ist dieses Branching und Merging.

[25:28] So, eine letzte Frage noch dazu, wie heißt denn jetzt der Standard-Branch in Git?

[25:32] Ja, das muss ich irgendwie unterscheiden können, wenn ich jetzt für jedes Feature einen einzelnen

[25:35] Branch habe und ich will das wieder in den Stamm zurückbringen, wie heißt denn jetzt

[25:39] der Branch für den Stamm?

[25:40] Und in Git heißt dieser Standard-Branch Master, das heißt, wenn du das mal irgendwo liest,

[25:45] das ist quasi der Stamm deiner Entwicklung, dein zentraler Branch, auf dem gearbeitet wird.

[25:50] Bei Subversion heißt der anders, da heißt der tatsächlich Trunk, also wirklich wie

[25:53] bei einem Baum, der Trunk, das ist der Stamm, das ist das englische Wort dafür und bei

[25:57] Git haben sie den Wortlaut nicht übernommen, ich weiß nicht warum, da heißt er jetzt

[26:01] einfach Master, bei Subversion heißt er halt Trunk.

[26:03] Okay, und letzte Frage zu Git, Nummer 22 auf der Liste, was ist ein Tag?

[26:09] Einen Tag, das kennst du bestimmt, das ist so ein Schlagwort, das kann man zum Beispiel

[26:12] Blockartikeln wunderbar hinterlegen, mache ich auch mal bei meinen Blockartikeln, so

[26:15] ein Schlagwort halt einfach vergeben und das Ganze kann man auch bei Git machen.

[26:19] Was ist jetzt ein Tag bei Git?

[26:21] Gibt es aber auch in anderen Versionsverwaltungssystemen wie Subversion.

[26:23] Ein Tag, das ist einfach nur ein Zeiger auf einen ganz speziellen Commit, dem man einen

[26:28] schönen Namen geben kann.

[26:29] Als Beispiel, du hast deine Software fertig und machst jetzt das Release, Version 1.0,

[26:34] dann kannst du den Commit, der alles das enthält für diese Version 1.0, den kannst du mit

[26:39] einem Tag versehen, zum Beispiel v1.0 und dann kannst du jederzeit später einfach auf

[26:45] diesen Stand zurück, du kannst nämlich diesen Tag-Namen zum Beispiel beim Checkout benutzen,

[26:49] du kannst einfach sagen Git-Checkout v1.0 und musst dir dann nicht immer diese kryptischen

[26:53] Hash-Namen merken.

[26:54] Das heißt, es ist auch ganz oft so, dass bestimmte Commits wirklich auch einen Tag

[26:58] bekommen, einen Namen, weil man sich diese Hashes halt einfach überhaupt nicht merken

[27:01] kann.

[27:02] Bei Subversion weiß ich vielleicht, achso, ja, Version 1.0, das war Revision 273, bei

[27:07] Git ist es dann Revision a1bcfa und du weißt, worauf ich hinaus will, das kann sich kein

[27:13] Mensch merken, von daher kann man mit einem Befehl Git Tag und dann den Namen, diesem

[27:17] Commit einen Namen geben, der erscheint dann zum Beispiel auch in der Log-Ausgabe und

[27:21] du kannst dann damit einen Checkout machen und was du sonst auch immer machen willst

[27:25] mit Git, überall kannst du das halt benutzen und eben sprechende Befehle benutzen.

[27:29] Okay, das soll es jetzt erstmal zu Git gewesen sein, ich habe eine ganze Menge hier jetzt

[27:34] schon behandelt in der fast einen Stunde, die ich jetzt rum habe insgesamt.

[27:37] Ich könnte noch viel, viel mehr erzählen, es gibt noch so viele Begriffe und Befehle,

[27:41] die man mit Git mitmachen kann und so weiter, aber es ist sinnvoll erstmal selber damit

[27:45] anzufangen.

[27:46] Ich kann nur kurz sagen, mit Git kannst du noch die wildesten Dinge tun, die du dir jetzt

[27:49] noch gar nicht vorstellen kannst, warum du es überhaupt brauchen solltest, ja.

[27:52] Es ist mit Git wirklich fast alles möglich, ist ein ganz, ganz tolles Tool, aber irgendwo

[27:56] mache ich jetzt hier mal Schluss und das ist jetzt hier erreicht.

[27:59] Ich glaube, wenn man die paar Sachen, diese insgesamt 22 Fragen beantworten kann, dann

[28:02] kann man schon mal, so sage ich mal, bei der Arbeit das Git vernünftig nutzen, man weiß

[28:07] die wichtigsten Sachen, wie ich Sachen einchecken kann, auschecken kann und so weiter und alles,

[28:11] was jetzt noch oben drauf kommt, kannst du dir gerne angucken und solltest du auch, für

[28:15] mich ist Git ein ganz, ganz wichtiges Werkzeug und das sollte man auch meistern tatsächlich

[28:19] als Softwareentwickler, weil es einfach so toll bei der Entwicklung einen unterstützt.

[28:23] Aber irgendwo muss ich mal aufhören, deswegen ist hier jetzt Feierabend, aber ich habe zum

[28:27] Abschluss der Episode noch fünf zusätzliche Fragen, die du dir unbedingt stellen solltest,

[28:32] wenn du in deinem Betrieb, also in deinem Ausbildungsbetrieb oder Unternehmen Git einsetzen

[28:36] solltest oder auch irgendeine andere Visumsverwaltungssoftware, ist ganz egal, aber das musst du unbedingt klären,

[28:42] du vernünftig damit arbeiten kannst und die gehen wir jetzt noch mal kurz durch.

[28:46] Meine fünf Fragen zum Ausbildungsbetrieb und das ist die Nummer eins auf meiner Liste.

[28:51] Wie gesagt, ich habe diese Liste meinem eigenen Azubi gegeben, er sollte das mal klären und

[28:55] die Idee dahinter war, dass er jetzt auch mal mit ein paar anderen Kollegen ins Gespräch kommt und

[28:59] mal fragt, sag mal, was machen wir denn mit Git und so weiter. Einfach mit den Leuten mal so ein

[29:02] bisschen ins Gespräch kommt, denn diese Sachen kann man natürlich nicht im Internet recherchieren,

[29:06] die kann nur dein Unternehmen dir beantworten. Das ist jetzt auch genau der Sinn hinter diesen

[29:11] Fragen. Und Nummer eins auf dieser Liste ist, wofür setzt dein Unternehmen überhaupt Git oder

[29:15] Subversion ein? Wird das überhaupt schon eingesetzt und wenn ja, wofür? Was macht ihr damit? Bei uns

[29:20] ist es zum Beispiel so, dass sogar der Fachbereich Subversion einsetzt, um Dokumente zu versionieren,

[29:25] meinetwegen Druckstücke von irgendwelchen Tarifen, dass man sich die Unterschiede noch

[29:29] mal angucken kann oder eine Version von 1998 noch mal aufmachen kann und so weiter. Git setzen wir

[29:34] für so ziemlich alles andere ein, Sourcecode, Textdokumente, LaTeX kann man damit versionieren

[29:39] und so weiter. Und das ist eine wichtige Frage, wo wird das überhaupt schon eingesetzt bzw. was

[29:44] für Software setzt ihr sonst ein? Setzt ihr vielleicht Team Foundation Server ein oder

[29:47] Mercurial oder was auch immer? Das ist erstmal Punkt Nummer eins auf der Liste. Darfst du es

[29:51] überhaupt benutzen oder benutzt ihr zum Beispiel was ganz anderes? Dann die zweite Frage, ganz

[29:56] konkret, war jetzt auch mit so einem kleinen Arbeitsauftrag verbunden. Was musst du tun,

[30:00] um Git an deinem eigenen Arbeitsplatz nutzen zu können? Ist das zum Beispiel schon vorinstalliert?

[30:05] Habt ihr vielleicht eine Softwareverteilung, die das automatisch macht? Musst du das erstmal

[30:08] runterladen, konfigurieren, einstellen, bla und blub? Oder gibt es da irgendwas Fertiges,

[30:12] wo du noch auf den Knopf drücken musst? Das ist eine konkrete Frage, die du für dich klären musst,

[30:15] am besten mit deinem entsprechenden Admin-Kollegen oder Ausbilder oder Arbeitsplatznachbarn oder was

[30:20] auch immer. Was ist notwendig, damit du in deinem Unternehmen überhaupt diese Versionsverwaltungssoftware

[30:25] nutzen kannst? Bei uns ist es zum Beispiel so, für Subversion haben wir einen grafischen

[30:31] Client, nämlich Tortis SVN. Das ist so der Standard-Client, den man erstmal installiert

[30:34] haben muss. Git benutzen wir als Kommando-Zahlen-Werkzeug. Das muss man auch über

[30:38] eine Softwareverteilung erstmal installieren und so weiter. Das heißt, das musst du für dich

[30:41] konkret klären. Was sind die Schritte, damit du auf deinem Arbeitsplatz überhaupt mit Git in diesem

[30:46] Fall arbeiten kannst? Dann die dritte Frage. Du hast jetzt Git installiert, weißt jetzt auch,

[30:51] wofür es benutzt wird. Das ist toll, aber was gibt es denn jetzt zum Beispiel für Repositories in

[30:55] deinem Unternehmen, mit denen du arbeiten kannst oder auch darfst? Gibt es da vielleicht eine

[30:59] rechte Verwaltung oder sonst was? Und die zentrale Frage ist, wo findest du denn diese Repositories?

[31:04] Muss man die auswendig kennen, weil das jeder so einfach weiß, der in diesem Unternehmen arbeitet?

[31:08] Oder gibt es vielleicht einfach eine Web-Oberfläche, wo du dir die Repos anschauen kannst? Bei uns ist

[31:12] es zum Beispiel so, dass wir eine Java-Software im Einsatz haben, die so ein bisschen als Hosting

[31:16] für die Git-Repos dient. Und da kann ich mich einfach anmelden mit meinen Windows-Benutzerdaten,

[31:20] ist ansat-d integriert und da kann ich alle Repos sehen, die es bei uns gibt. Und dann weiß ich

[31:24] halt, ich kann da drin suchen, ich kann sortieren, ich kann mir die letzten Commits angucken, die

[31:30] DIVs sogar und so weiter. Das ist eine schöne Web-Plattform für die Verwaltung von Git-Repos.

[31:34] Und wenn ich gar nicht weiß, dass es die gibt, ja, dann finde ich auch kein Repo bei uns im

[31:39] Unternehmen. Das fällt einem ja nicht automatisch ein. Und deswegen unbedingt nachfragen, wo kann

[31:43] man sich so eine Liste angucken? Oder wo ist das definiert? Wo sind die Rechte definiert? Wo kann

[31:48] man sich so etwas anschauen bei euch im Unternehmen? Dann die Frage 4 zielt ab auf die guten

[31:53] Commit-Nachrichten, die ich schon angesprochen habe. Gibt es bei euch im Unternehmen Regeln

[31:58] für Commit-Nachrichten, an die du dich halten musst? Ist das zum Beispiel alles auf Englisch

[32:01] zu formulieren oder auf Deutsch? Ist das eher aktiv oder passiv oder gibt es da irgendwelche

[32:06] Regeln, an die du dich halten musst? Bei uns im Unternehmen ist es zum Beispiel so, dass wir für

[32:10] bestimmte Repositories die Regel haben, dass es keine Commit-Nachricht ohne eine Ticket-Nummer gibt.

[32:15] Bei uns müssen alle Änderungen an der Software in einer Ticket-Software, also in einem Bug-Tracker

[32:21] quasi nachvollzogen werden können. Und das heißt, es ist Pflicht in jedem Commit eine

[32:26] Ticket-Nummer anzugeben. Wenn die nicht da drin ist, dann haben wir das technisch sogar so gelöst,

[32:30] dass du gar nicht committen kannst, weil ein Skript prüft, ob eine gültige Ticket-Nummer

[32:34] angegeben wurde. Und wenn es bei dir auch entsprechende Regeln gibt und du kennst die

[32:37] nicht, ja, dann hast du vielleicht toll gearbeitet, kriegst es aber gar nicht ins Repo rein, weil

[32:41] irgendein Skript sagt, hey, du hast da Müll angegeben. Also unbedingt mal klären, gibt es

[32:46] bei dir konkrete Regeln für Commit-Nachrichten? Und die letzte Frage Nummer 5 auf meiner Liste

[32:52] für den Ausbildungsbetrieb ist, welche Branching-Strategie verfolgt dein Unternehmen? Denn ich

[32:58] hatte schon angesprochen, es gibt relativ viele unterschiedliche Branching-Strategien, die sich

[33:02] auch sehr stark unterscheiden in der kompletten Arbeitsweise. Also es gibt Leute, die halt für

[33:06] jedes kleine Feature ein Branch aufmachen, dann gibt es auch sowas wie, wir arbeiten nur im Stamm,

[33:10] es gibt gar keine Branches, ja. Und das hat alles aber seine Vor- und Nachteile. Man kann nicht sagen,

[33:14] das eine ist richtig, das andere ist falsch, es kommt immer aufs Unternehmen an. Und bevor du dir

[33:18] jetzt an irgendeinem Podcast meinetwegen anhörst, es ist supergeil, Feature-Branches zu benutzen und

[33:23] in deinem Unternehmen wird das aber gar nicht so gemacht, dann kannst du ganz schnell mit deinen

[33:26] Kollegen dir in die Quere kommen und eventuell sogar was kaputt machen. Also bevor du irgendwas

[33:31] committest, frag unbedingt nach, wie das mit den Branches aussieht. Musst du Branches benutzen? Wenn

[33:36] ja, wie müssen die heißen? Gibt es da eine bestimmte Vorgabe und so weiter? Und das solltest

[33:40] du unbedingt mit deinen Kollegen klären, bevor du irgendwie anfängst und im Repository rumdokterst.

[33:46] Das ist keine gute Idee, würde ich unbedingt vermeiden wollen. Okay, ja, die Fragen habe ich meinem

[33:53] Azubi auch mitgegeben und ich denke, wenn man die alle geklärt hat und auch mit Git schon mal

[33:56] gearbeitet hat, vielleicht das Tutorial durchgearbeitet hat, dann ist man sehr gut aufgestellt

[34:00] und kann wenigstens schon mal anfangen. Und der Rest, habe ich schon gesagt, das kommt dann beim

[34:04] Doing, wenn ich dann eine ganz konkrete Anforderung habe, so, oh, ich habe in dem Commit vor drei

[34:09] Commits irgendwie eine Datei vergessen, die muss jetzt aber noch da rein und auch in alle Folge

[34:13] Commits kann man alles mit Git machen, will ich aber hier nicht im Detail besprechen. Ich sage nur,

[34:18] das Ding ist wirklich super, super mächtig und man kann Monate oder auch Jahre damit verbringen,

[34:24] dieses Tool zu meistern. Also fang früh damit an, dann unterstützt es dich auf jeden Fall auch bei

[34:28] der Entwicklung. Ja, damit bin ich für die Einführung in Git jetzt fertig. Ich hoffe, es sind die

[34:34] wichtigsten Sachen so ein bisschen rübergekommen. Ich werde auf jeden Fall die beiden Episoden jetzt

[34:38] letzte Woche und diese Woche auch in Zukunft meinen Azubis und Studenten empfehlen, damit ich

[34:42] nicht immer wieder das Gleiche erzählen muss. Wenn ich noch mal irgendwas zu ergänzen habe,

[34:45] gibt es vielleicht noch mal eine dritte Episode, aber für mich ist das jetzt erst mal abgehakt,

[34:49] das Thema Git und von daher, ich hoffe, es war für dich ein bisschen was Sinnvolles, was

[34:53] Lehrreiches dabei. Wenn du irgendwas zu ergänzen hast, schreib mir gerne einen Kommentar zur Episode

[34:58] oder schreib mir eine Mail, kannst mich auf tausend verschiedene Arten erreichen, kannst einfach mal

[35:02] auf der Website vorbeischauen. Nochmal der Hinweis, die Shownotes zur Episode findest du unter

[35:07] anmeldungsentwicklerpodcast.de slash 77 für die heutige Episode 77 und wenn du dich für mein

[35:13] Newsletter anmeldest unter anmeldungsentwicklerpodcast.de slash Newsletter, dann kannst du dir auch die

[35:18] gesamten Fragen, die ich hier und heute und letzte Woche gestellt habe als Markdown-Datei runterladen

[35:24] und die zum Beispiel, was weiß ich, mit deinem eigenen Azubi durchgehen, wenn du Ausbilder bist

[35:28] oder wie gesagt selber, während du das Tutorial abarbeitest, versuchen die Fragen zu klären und

[35:34] danach nochmal die Episoden anhören, um zu gucken, ob du es richtig verstanden hast. Das sind so

[35:37] Möglichkeiten, die man vielleicht damit umsetzen kann. Okay, ansonsten sage ich für diese Episode

[35:44] heute vielen, vielen Dank fürs Zuhören und bis zum nächsten Mal. Tschüss!