 Herzlich willkommen hier im Open Hub, im ZKM. Wer von euch hat denn schon mal mit Git gearbeitet? Ich würde mal sagen, da seid ihr hier richtig. So Jee war, gerade habe ich es richtig hingekriegt. So Jee war ein Vijayakumaran und wird euch jetzt ein bisschen was über seine Erfahrungen mit Git und wie man es nicht verwendet, erzählen und viel Spaß. Ja, erst mal danke, dass so viele gekommen sind, schon der Bedarf zu geben. Ich meine, eine Frage, ich meine, wir hatten ja gerade jetzt die Frage, wer nutzt Git? Ist denn hier jemand, der keinen Git nutzt? CVS? Genau, kurze... Erst noch zur Struktur des Vortrags. Was mache ich genau hier? Einmal so ein paar dämliche Ideen, wobei ich sagen muss, es ist nicht wirklich dämlich. Es ist mehr so, wenn man teilweise nicht so ganz weiß, wie Git funktioniert und wie das genau arbeitet, dann ist das manche ein bisschen dämlich. Manche Sachen sind auch so dämlich, auch wenn man weiß, wie es funktioniert. Und ich will ein bisschen mal so zeigen, wie das dann ist, was man so machen kann oder was man falsch machen kann und wie es dann richtig geht. Meistens sieht man irgendwelche Anleitungen von wegen, ah, ich habe hier was Schönes. Bevor ich das aber weitermache, komme ich kurz noch zu, wer bin ich überhaupt? Oder wer ist das mit diesem komischen Namen? Und zwar komme ich aus der schönen Rohmetropole Kastraprauksel. Einer lacht hier sehr gut. Ich habe ein Git-Buch geschrieben und ich mache häufiger Git-Workshops. Und da sehe ich immer sehr viele interessante Sachen, die Leute machen, vor allem halt Anfänger. Was man mir so zugehört hätte, dann halt nicht gemacht hätte. Was ich zum Beispiel gerne mache ist, wenn man Git konfiguriert, also gitconfig, user.name, schreibe ich in meinen Anleitungen immer schon meinen Namen hin. Schöner komplizierter Name, schreibt keiner hin. Stellt sich fest, doch. Und richtig geschrieben, das habe ich auch nicht so häufig. Da sind immer so manche Kleinigkeiten, die dann immer ein auffallen, wenn man, was soll Leute in Repositories tun? Oder auch außer von Repositories natürlich. Praktische Negativbeispiele ein paar. Paar sind schlimmer, Paar sind weniger schlimmer. Und wer jetzt viel schon Git kennt, der wird wahrscheinlich nicht so viel mitnehmen können. Für die, die jetzt nicht so gut, nicht so ganz so bekannt sind, ist das vielleicht ein bisschen was Interessantes bei, vielleicht auch nicht. Das kann ich schlecht sagen, kommt halt immer darauf an, wie er so tickt. Und halt so ein paar Doos und Downs. Letztendlich sind es so, ich glaube, 10, 12 verschiedene Sachen, die ich so vorstelle. Genau. Wer ist denn ja alles fit in Git? Und ja, die mit den Leuten, die stehen, einmal tauschen. Für die, die sich nicht gemeldet haben, für die habe ich immer dieses schöne XKCD. So, ich glaube, es hat jetzt jeder gelesen. Genau. Und vor dem Problem stehe ich ja auch häufiger. Einmal gibt es immer die Leute, die sagen, ah, dieses schöne Graphenmodell, aber dann versteht man das nicht. Und dann gibt es noch die Git.txt, wo meine Handynummer draufsteht. Das ist auch nicht so toll, weil manche aber auch andere Dinge tun. Und fangen wir mit den ersten Sachen an, nämlich Credentials. Wer hat schon mal Credentials in Genangitrepo gefunden? Ach. Und bei wem war das in der Public Repository? Und was habt ihr dann gemacht? Ja. So, und zwar das Problem mit Credentials ist, beziehungsweise generell mit der Versionskontrolle. In jeder Revision ist halt eben das Credential drin, sei es ein Passforce oder API-Key oder sowas. Und ganz allgemein, also seit der Einführung, ist es halt entsprechend in jeder Revision drin. Natürlich sollte man sie ändern. Und wenn man dann eben hingeht und alle Vorkommnisse von diesem Key raushaben will, dann muss man so ein Filterbond anwenden. Wer hat schon mal Filterbond angewendet? Ja, auch schon ein paar. Und zwar ist Filterbond eigentlich eine ganz schöne Sache. Und zwar kann man damit die Historie neu schreiben. Was es letztendlich macht, ist man kann zum Beispiel einen Treefilter machen. Zum Beispiel, wie hier, geht Filterbond Treefilter mit einem Befehl und das dann auf das Repository loslassen. Und in dem Fall wird er durch jeden Commit durchgehen und die Passwort INI-Datei zum Beispiel rauslöschen. Hat im Endeffekt den großen Nachteil in dem Sinne. Es ist eine komplett neue Repository, weil jeder Commit, bis dieser Datei hinzugefügt wurde, ist entsprechend verändert worden, neue Commits. Und man kann es nicht mal so einfach verwenden, weil dann eben die Historie nicht mal so ganz schrimmt. So, eine komplett neue Historie hat eben dazu den Fall, dass man ein Forcebush machen muss, um das eben auf dem Server zu veröffentlichen. Und hier haben wir ein paar Filterbond verwendet. Wer hat das dann danach gepusht und seinen Kollegen nicht Bescheid gesagt? Keiner, sehr gut. Dann kommen wir aus so einem Punkt, unnötiges Historieneustreiben mit Filterbond. Es gibt halt Cases, wo man das dann machen muss, wo irgendwelche Daten drin sind, die nicht veröffentlicht werden sollten. Ich beziehe mich so ein bisschen auf sowohl Open Source Projekte als auch Firmenterne Projekte. Und zwar wie gerade eben schon gesagt, fast jeder Commit wird angefasst, wo entsprechende Dateien, sowas drin war. Und wesentlicher Nachteil ist, jede Person muss das neu klonen. Und was ich schon mal gesehen habe, ist, irgend ein Open Source Projekt hat das mal gemacht. Die haben einen Filterbond schon angefindet, um eine Subdiroaktorie zu einem eigenen Repository zu machen. Also was dann häufig so ist, ich habe jetzt irgendwie so ein Library Ordner. Und diesen Library Ordner hat auch mal eigene Historie. Und man kann diese Historie von diesen Unterzeichnissen rausziehen und ein eigenes Reboot ausmachen. Das ist ein guter Use Case, weil dann hat man das halt extra und dann hat man zwei Repositories. Eventuell braucht man das, sondern ist es auch okay. Was man dann nicht machen sollte, ist ein Filterbond anwenden, um die ganze Historie von diesem Ordner zu entfernen. Das braucht man dann halt nicht. Das ist am meisten nicht so wirklich für Open Source Projekte geeignet, weil man dann eben komplett die Historie neu schreiben muss. Und nächste Punkt ist Force Push. Das F steht mir vorsichtig. Wobei ich sagen muss, habe ich vorhin beim Stand vom Backspace gehört. Das fand ich richtig witzig, habe ich direkt eingefügt. Wer hat schon mal Spaß mitgehabt, dass irgend ein Force Push gemacht hat, oder einen Force Push machen sollte? Wie erfreut wart ihr dann? Genau, Force Push. Einige sagen immer, ein Force Push sollte man nur auf Branche zu machen, wo man nur komplett alleine drauf arbeitet. Also zum Beispiel nur auf privaten Forks. Ich mache das ein bisschen. Ich sage das immer so, okay, man kann das auch auf Buschenboanche machen, wo andere lesen können, aber wo man in der Regel alleine drauf arbeitet. Das war mir häufig der Fall. Ich bin im Moment mehr im Sys-Open-Bereich. Und da mache ich mein Kram in irgendeinem Feature-Boanche. Und da mache ich dann einen schönen Rebase Force Push, so wie mir lustig ist. Weil ich gehe davon aus, niemand nutzt diesen Branche als Basis für seine Arbeit. Und wenn, dann ist er selbst schuld. Entsprechend einfach nur zu merken, nicht auf Branche zu machen, wo mehrere Personen daran arbeiten. Zum Beispiel so ein Master-Boanche sollte man in der Regel nicht machen. Das geht jetzt hauptsächlich natürlich auf Projekte, wo mehrere Personen daran arbeiten. Was man dann aber immer machen sollte, ist, wenn man zum Beispiel GitLab oder GitLab verwendet, kann man Protected Boanches einstellen und wo man zum Beispiel auf Master und Develop oder wie die entsprechenden langliebigen Boanches entsprechend heißen. Und da kann man in der Regel generell kein Force Push machen und dann hat man schon ein Problem weniger. So, ein Ding ist, was ich bei vielen Leuten sehe, ist ganz große Commits. Wenn man das verwendet, gibt es viele Leute Commit-A. Wer macht das denn hier? Wer traut sich jetzt, sich dichtzumelden? Sehr gut. Genau. Ich sage immer, niemand hat die Absicht, GitCommit-A auszuführen. Und zwar unter dem Grund, dass halt eben nie klar ist, was da jetzt genau drin ist. Weil, wenn er GitCommit-A macht, weiß man immer, okay, ich pack da irgendwie alles, was ich gerade verändert habe, rein. Und häufig sind da irgendwelche Sachen drin, wie ich A irgendwie nicht mehr so weiß, was ich getan habe oder warum ich das getan habe. Und dann kann ich natürlich auch keine ordentliche Commit-Message schreiben. Entsprechend sage ich immer, kein GitCommit-A verwenden, weil ihr sollt wissen, was ihr getan habt. Auch hinterher. Und die Kollegen natürlich. Und ganz allgemein dazu, Commits sollten möglichst klein sein. Und das ist eine Veränderung. Wenn ihr in einer Commit-Message zum Beispiel schon stehen habt, bla bla bla und dies und jenes, dann wisst ihr, okay, das könnte eventuell mal in mehrere Commits machen. Warum das Ganze? Gewährleistung der Nachvollziehbarkeit. Wer hat sich schon mal GitCommits angeschaut und konnte nicht nachvollziehen, was die Person gemacht hat. Genau. Und was mit dem Rest? Und bei wem war das der Fall, dass man sich eigene Commits angeschaut hat und nicht feststellen konnte, was man getan hat. Also, ich muss mich natürlich auch melden. Genau, weil was ich nämlich häufig mache, GitBlame, das finde ich ganz toll. Kennt jemand GitBlame nicht? Ein paar Leute kennen GitBlame nicht, GitBlame ist toll. GitBlame kann man auf eine Datei werfen, also GitBlame Dateinnahme und das sagt dann für jede Zeile, wer hat das zuletzt angefasst, welche Commit-ID hatte das, welches Datum-Zeitstempel und für jede Zeile halt entsprechend. Wenn man dann irgendwie so ein Einzahl hat, wo man merkt, okay, das macht keinen Sinn, gucke ich da mal drauf, okay, wir warten das, das macht überhaupt keinen Sinn. Guck drauf, oh Scheiße, das war ich. Und gucke dann in die Commit-Messe, denkst du, ich sag ja den Leuten immer, schreibt ordentliche Commit-Messages und dann steht da irgendwie FixedBuck. Wer kennt das nicht? Und dann weiß ich, okay, man sollte vielleicht bei sich selbst erst mal anfangen, bevor man andere anguckt. Deswegen GitBlame kann man helfen, nicht nur dazu. Mein Blame ist halt immer so negativ belastet, so ja, wer hat den Scheiß jetzt verbrochen, aber man kann ja generell mal gucken, unter welchem Gesichtspunkt hat jetzt die Person das gemacht, wann war das und so weiter. Wer kennt GitBysect? Nicht. Gut, das kennt die meisten nicht. GitBysect ist relativ toll, es ist letztendlich eine binäre Suche über Commits, das heißt, wenn ich jetzt Version 1.0 hab und Version 2.0 hab und man hat irgendeine Funktion oder irgendein Back drin, der in Version 1 hat es normal funktioniert und in Version 2 hat es nicht mehr funktioniert. Irgendwo in der Mitte ist dann, oder irgendwo dazwischen, ist dann halt ein Fehler aufgetaucht und wenn man das per D-Burken Partu nicht hinkriegt, dann muss man halt mal gucken, wie man weiter macht. Das Tolle bei GitBysect ist eben, da kann man halt eben sagen, der gute Startpunkt war Version 1 und Version 2 hat es nicht mehr funktioniert und das macht eine binäre Suche über jeden Commit, womit man dann nachgucken kann, hat das überhaupt funktioniert. Also dann eben, nimmt er sich den mittleren Commit, weiß, wenn das hat funktioniert oder nicht, dann muss ich jeweils noch die Hälfte machen, hat man relativ wenige Schritte, bis man dann sieht, was das Problem war. Und zwar bin ich halt so vorgegangen einmal, hatte ich ein Problem gehabt, das war irgendwie so ein C++-Grams, hab es gediebert, hab es nicht gefunden, dachte dann so, ich mach das mal händisch, weil ich kannte GitBysect nicht und bin halt händisch hingegangen, hab jeweils zwischen zwei Commits den mittleren Commit gesucht und dann halt händisch getestet alles und dann den nächsten Commit weitergesucht, bis ich dann den fehlerhaften Commit gefunden hab, wo dann halt, kommen wir wieder zu letzten Folie zurück, wo dann halt drin steht Fixed Performance und das war genau das Gegenteil. Also das kann hilfreich sein, weil man mal Part 2 nicht auf den Fehler kommt. Da ist es aber hilfreich, dass man halt Commits hat, die möglichst klein sind, aber auch irgendwie kompilierbar testbar sind. So, was hilft gegen große Commits? Weil was ich immer mache, ist GitStatus. Wer verwendet GitStatus täglich oder wer verwendet es nicht täglich? Okay, ein paar Leute trauen sich. Genau, GitStatus sage ich allen Leuten, vor allem Anfängern immer, tippt das ein, damit ihr wisst, was gerade los ist. Das mache ich immer, auch wenn ich gerade davor irgendwas gemacht hab und dann GitDiff um das Diff anzugucken, um damit nichts rausgefallen ist. Weil als ich zum Beispiel die Folien gemacht hab, in Latech im konkreten Fall, also vor so einer Stunde, ist mir plötzlich eine Folie abhanden gekommen und das habe ich nur gerade gesehen, weil ich vorher nochmal ein GitDiff angeguckt hab und mein Lieblingsfeature ist GitAd-P. Wer kennt das? Na, die Hälfte, okay. GitAd-P ist ein schönes Feature, weil wenn ihr in einer Datei mehrere Änderungen habt, also einmal was oben und dann mal was unten, dann könnt ihr relativ einfach selektieren, welche Sachen ihr haben wollt. Wenn ihr dann einfach GitAd Dateinahmen macht, dann sind ihr alles im Stating-Bereich drin und dann im nächsten Commit. Manche hat aber verschiedene Sachen, die man getrennt in der Commit haben möchte. Und da hilft dann GitAd-P weiter. Jetzt mal kurz. Ja, ich muss gerade nur einen Repo suchen, wo ich das machen kann. Wir machen hier. Hallo, GPN. Das ist auch egal. Tschüss. Auf wie immer, GitStatus. Heps. Noch keine Commits. Das ist ein schlechtes Beispiel. Verdammt, das ist auch Video, ne? Noch mal hier. Wie man sieht, habe ich hier zwei verschiedene Änderungen, einmal oben und einmal unten. Und mit GitAd-P kann ich dann schon so schön sagen, Moment, ich mach das mal anders. So, sehe ich jetzt einmal die obere Änderung. Drück jetzt hier auf Y für Yes. Und drück bei Tschüss. GPN auf N für Nein. Wenn ich jetzt mal GitStatus eintippe, dann sehe ich einmal die gleiche Datei sowohl verändert als auch gestatet und einmal nicht im Stating-Bereich. Und das ist dann recht hilfreich, weil dann kann ich zwei Commits machen mit derselben Änderung in derselben Datei. Wenn man sich das jetzt nochmal weiter anguckt, dann sieht man hier verschiedene Buchstaben. Ich kenne jetzt auch nicht alle auswindig. So, dass man, wenn man größere Änderungen hat, auch ein S machen kann für Split, um das Ganze ein bisschen aufzuteilen. Das Split sieht man jetzt im konkreten Beispiel jetzt nicht, weil es halt ein Zweizeiler ist oder ein Dreizeiler. Soweit klar, hoffe ich. Ja, so. Genau. Und dann geht Kommit entweder mit Minus M und der Commit-Message oder halt eben mit dem Editor der Wahl, den man halt eben aufmacht, um dann die Commit-Message einzutragen. Kommt mal zum nächsten unlesbare Commit-Message. Ich habe mal hier so ein paar mitgebracht. Und zwar, wer hat schon mal welche von denen hier gefunden? Hat sich jemand nicht gemeldet? Genau. Wer schreibt regelmäßig solche Commit-Messages bei Projekten, wo nicht nur man selbst arbeitet? Gut, schämt euch. Genau. Ja, ich glaube, da muss ich jetzt konkret nicht so viel sagen. Es meistens, sollte man schon beschreiben, was da drin ist. Was ich aber sagen kann, ist, ich habe zu der ganzen Sache, wie man nachvollziehbare Commits macht und einen eigenen Talk gemacht auf dem Chemnitzer Linux-Tagen. Gibt es einen Aufzeichnungen, kann man sich angucken. Ansonsten könnte ich hier drei Stunden referieren. Genau. Kommt mal zu Binär-Dateien. Wer hat schon mal Binär-Dateien im Repository gefunden? Okay, also gefühlt fast alle. Genau. So, dazu muss man wissen, dazu muss man wissen, wie geht, warum knistert das jetzt so? Wie geht Ihre Daten, die Dateien speichert und wie die Binär-Dateien entsprechend was und Probleme dazu da gibt. Und zwar, geht speichert immer eine Datei, die man in das Repository schiebt, komplett viele denken, ich habe ja nur einen Diff von, was ich gerade auch gemacht habe, von drei Zeilen. Also speichert dann nur dieses Diff, das ist ja so schön klein und dann zieht das ja nicht so viel Speicherplatz. Geht speichert einmal die komplette Datei, komprimiert die und speichert die intern ab. Macht aber bei jeder, bei jedem Vorgang eine neue Abspeicherung. Das heißt, wenn man hier zum Beispiel guckt, wir haben vier Dateien. Im ersten Komet, also im allerersten Komet, haben alle Version 1. Wenn wir aber die im zweiten Komet eine Datei anfassen, dann haben wir dann eine neue Version. Die anderen sind aber weitere die alte Version. Wenn man dann irgendwie eine Datei 2 verändert, dann hat man davon eine weitere Version, aber man muss nicht zwangsläufig die ganze Historie speichern. Weil, wäre jetzt einfach mal immer nur, theoretisch kann man auch hingehen, bei jedem Komet speichere ich das ganze Verzeichnis und speichere das irgendwo weg, aber das brauche ich ja nicht, weil dann würde ich ja dat einen doppelt speichern. Das Problem bei Binärdateien ist, je größer, je mehr man davon drin hat, desto größer wird das Repository. Wärt schon mal mit Gigabyte großen Repositories gearbeitet. Hat es Spaß gemacht. Kopf schütteln. Eine Lösung ist GitLFS für large file System, glaube ich. Und das ist meistens so bei GitHub und GitLab zum Beispiel, dass man Binärdateien nicht alles lokal herunter kopiert werden und dann dauert das GitClone nicht ganz so lange. Kommen wir zu dem Problem, dass man viel zu viele Dateien und viel zu viele Verzeichnisse hat. Und so habe ich hier ein konkretes Beispiel und das fand ich durchaus interessant. Und zwar, es gibt einen GitRepository, das wurde von der Firma, also von der Firma, die das hat, als das größte GitRepository in der Zeit betitelt. Es hat 3,5 Millionen Dateien. Es sind 300 Gigabyte Repository und da arbeiten 4.000 Leute ungefähr täglich dran. Welches Projekt ist das? Kennt ihr vielleicht? Und zwar sieht es da so aus, dass wenn man ein GitClone macht, dauert das da 12 Stunden, wenn es funktioniert. Also unter dem Link das kann lohnt sich anzugucken. Das ist ein Vortrag von Microsoft, von der Git-Konferenz von vor 2 Jahren, glaube ich. Da hat er da halt gezeigt, was für Probleme sie hatten von, ich glaube, Team-Formation-Serve auf Git zu migrieren und was das also für Probleme war. Und so ein GitCheckout von einem Boahansch, der dauert ja, wenn man das jetzt bei seinen Otto-Normal-Projekten, das halt macht, dauert das ja unwesentlich. Und da dauert ein GitCheckout 3 Stunden. Oder ein Git-Status, wo ich ja vorhin gesagt habe, der beständig dauert 8 Minuten. Und ein Git-Commit 30 Minuten. Dann macht man lieber größere Commits. Und um nachzuvollziehen, warum das Ganze so lange dauert, kommen wir jetzt auf das nächste, weil ich habe es gerade ja schon so ein bisschen erklärt, und zwar, wie Git intern die Dateien speichert. Und zwar hat Git 3 Objektiven-Typen, ein Git-Commit, ein Tree und ein Blob. Wenn ich in einem Repository, also wenn ich in einem Repository bin und Gitlock eintippe, dann sieht man ja erstmal ganz viele verschiedene Commits nach der Reihenfolge, wie sie erstellt wurden, also neuste zuerst und die Alteren weiter unten. Und da kann man mal reingucken. Zum Beispiel habe ich hier diesen Commit, einen Commit, schau da rein. Wenn ich reingucke, was steht in da drin. Dann sehe ich so unter anderem so Sachen wie Datum, wann und wer und welche Commit-Message und ein Tree-Objekt. Ein Tree, also ein Verzeichnisbaum. Und da kann ich reingucken und da ist eine Liste drin von Dateien, die in dem Repository drin sind. Da kommen wir zu der nächsten Stufe, nämlich ein Blob. Wenn wir genau eine Datei haben, die 1 heißt, dann ist das recht einfach. Und ein Tree enthält ein Blob und in dem Blob ist an der Inhalte der Datei drin. So, wenn wir jetzt einen zweiten Commit machen, dann sieht das Ganze so aus. Wir haben einen Commit, einen zweiten Commit, der hat eingetragen, welcher Vorgänger-Commit das ist und hat ein neues Tree-Objekt. In dem Tree-Objekt sind jetzt zwei Dateien drin. Nämlich einmal die alte Datei, die muss man ja nicht neu erzählen, und die zweite Datei, die ein neuer Blob ist. So ist es letztendlich, es geht ganz einfach implementiert. Und letztendlich ist es eine Verkettung von Commits. Ich meine, hier habe ich jetzt einfach nur ganz zwei Dateien, zwei Commits. Es ist relativ einfach, um jetzt wieder auf das Problem von dem Windows ein Git Repository anzuknüpfen. Und jetzt halt eben ein Commit und ein Tree-Objekt. Und in dem Tree-Objekt sind ganz viele Millionen an Tree-Objekten und Blobs drin. Und muss das weiter ganze nachhangeln und danach zu schauen, ist die Datei irgendwie verändert worden. Das heißt, bei 3,5 Millionen Dateien muss das nachgucken, wird die Datei irgendwie verändert oder nicht. Da arbeiten das meistens nicht ganz so schlimm, als mit vielen kleinen Dateien. Bei einem Git Start hast du zum Beispiel hin und guckt, welche Datei wurden jetzt angefasst. Bei 3,5 Millionen kann das ein bisschen dauern. Und was sich Microsoft im Konkreten ausgedacht hat, war das Git-Virtual-File-System. Das lädt dann ausgewählte Git-Files, also das im Punkt Git-Verzeichnis und die mahnt. Es ist dann nicht mehr komplett verteilt. Aber man will hier auch nicht 300 Gigabyte nur auf seinem Rechner haben. Und das lädt dann so und die mahnt halt eben die Dateien und dann können sie damit arbeiten. Weil, hatten auch gesagt, die haben sich Submodules angeguckt. Wer nutzt Git-Submodules? Wer hat Spaß damit? Einer, oder 3,4,5 Ja, Git-Submodules macht meistens keinen Spaß, vor allem wenn man ein Projekt hat, wo vieles ineinander greift und wenn man dann gleichzeitig andere Positories arbeiten muss, dann ist das nicht mal ganz so schön. Und deswegen war das auch zum Beispiel keine Lösung. So, der nächste Punkt, Git-GUI-Tools Vertrauen, Git-GUI-Tools zu nutzen, ist völlig okay. Aber darauf zu vertrauen, ist manchmal so eine Sache. Wer nutzt, oder wer nutzt fast ausschließlich nur Git-GUI-Tools? Ah, okay. Und was ich dazu immer sage, ist, Git-GUI-Tools ist ein Anfänger. Git ist ein Kommando-Zahlen-Tool und grafische Tools sind häufig nicht so klar, was da passiert. Deswegen mache ich vor allem bei Anfängern, wenn ich da mal so einen Workshop mache, mache ich dann relativ eigentlich nur Kommando-Zahlen-Tool, weil wenn man das verstanden hat, dann weiß man auch, was die Buttons auf der Oberfläche im grafischen Tool machen. Man weiß nicht, was das heißt, sondern da steht jetzt Merge, aber was heißt das überhaupt? Und irgendwelche Begriffe, die gar nicht gibt, zum Beispiel gibt es in Visual Studio Code zum Beispiel ein Sync-Button. Ich weiß nicht, was ein Sync-Button tut, weil im Git-Repose gibt es kein Sync, oder auch diverse Sachen wie Intaktivariebe ist, das fehlt häufig. Manche gehen es auch noch hin und benennen Funktionen, die es in Git gibt, anders in irgendwelchen GUI-Tools. Und das ist meistens ein bisschen verwirrend. Und wir kommen dann immer so Leute und sagen hier, ich verstehe nicht, was hier los ist und ich sage dann, gib mal erstmal Git-Status, weil dann weiß ich, wie der Stand ungefähr ist. Weil das Zeichen die GUI-Tools meistens nicht ganz so an. Zum Beispiel, wenn man in einem Rebase ist, dann zeigt das Git-Status recht einfach an, bei in einem GUI-Tool, dann halt eben nicht. Das gibt auf Deutsch. Es fangen jetzt schon Leute an zu lachen. Und genau, wer weiß, was Git auf Deutsch heißt, nämlich Idiot, Blödenmann, der weiß daneben, okay, da sind manchmal so Sachen. Ich meine, viele nutzen, glaube ich, auf Deutsch den, die Begriffe Buansch, Zweig für Buansch. Ich glaube, das war's. Ich hoffe, das kann man lesen. Das ist jetzt ein Screenshot aus Git, aus dem Tool Git-GUI, was an sich in Ordnung ist. Man sollte es noch nicht auf Deutsch verwenden. Und zwar, wenn man hier so guckt, ein Repository ist ein Projektarchiv. Ein Buansch ist ein Zweig, ein Commit ist eine Version. Und hier sind dann so Sachen wie Letzte Nachbessern, Abzeichnen und Eintragen oder ein Merch ist zusammenführen. Und hier sieht die englische Übersetzung aus. Eine Eintragung ist nämlich ein Commit. Da kam ich jetzt auch nicht drauf. Deswegen sage ich immer so, okay, besser auf Deutsch, auf Englisch verwenden. Wobei ich in einem konkreten Beispiel hatte ich mein Getrebe, wo der Vortrag drin liegt, hat ein Air drin, für dämliche Aktionen. Das ist auch schön. Es gibt ein Getrebe, nämlich ein Get auf Deutsch. Der hat dann so recht am Husont hingeschrieben, was man für Übersetzung geben könnte. Für z.B. Pull ist ein Ziehen, einen Push ist ein Drücken. Ein Merch ist ein Vereinigen. Das war auch mal witzig, weil bei meiner alten Arbeitsstelle, ich rede auf Deutsch, ich rede mal mit einem Kollegen so, ja hier können wir dies oder jenes merken. Sie fragt mir, was redet ihr eigentlich über das Merken? Er guckt auch ins Wörterbuch, hat sie nachgeguckt, iiii, sich vereinigen. Seitdem fand sie den Begriff immer schon sehr toll. Genau, und da sind letztendlich auch noch Alias drin, die man sich setzen kann, wenn man es unbedingt auf Deutsch verwenden will. Also, Falk auf Github oder nein, drücke das gleich zum Meister im Ursprung oder mach ein Ziehbegehen, wenn du mit der Vereinigung fertig bist. Also, das ist aus dem Getrepo, das habe ich mir nicht selbst ausgedacht, ich fand es nur großartig, als ich das gesehen hab. Github auf Sächsisch ist auch toll. Kann ich nicht nachmachen. Könnt ihr ja mal kurz drüberlesen? Vielleicht haben wir hier einen Sachsen, der das vormachen möchte. So, ich mach mal weiter. Noch halbe Stunde geht ja an. Genau, wer hat schon mal ein komplettes Repository weggelöscht, weil irgendwas kaputt war? Also, hat's danach geholfen? Der Frust war weg, aber habt ihr verstanden, was kaputt war? Genau, also ich bin ja mal ein Fan davon, dass wenn man Probleme hat, dann geht man zum Arzt. Nein, dann guckt man eben, dass man das eben verstanden hat, was das Problem ist. Bei meinen eigenen Repositories habe ich das natürlich sehr, sehr lange her, dass ich das gemacht habe. Bei anderen Leuten mache ich das trotzdem manchmal, oder die machen das schneller, als ich sagen kann, tue es nicht. Und zwar wahrscheinlich irgendwie so ein Getriebeis, interaktiveriebeis, sondern ist irgendwie was kaputt gegangen und da habt ihr nicht mal weiter gewusst, oder? Ich sehe gar nicken, also okay. Und zwar, da hilft immer Getrefflog. Getrefflog ist immer recht schön, weil viele Leute sagen, ich hab noch nix getan, ich hab's immer wie immer gemacht, was dann aber nicht der Fall war. Und das hilft dann halt eben dagegen. Wenn man eben reinguckt, dann sieht man alles, was man lokal gemacht hat in diesen Repository. Wenn man irgendwelche Commits gedroppt hat, irgendwas gemirkt hat, dann kann man sehr einfach, ohne die Bash-Historie zu lesen, nachvollziehen, was denn da jetzt genau passiert ist. Und da kann man zum Beispiel verlorene Commits wiederfinden. Und was ich dann eben mache, wenn Leute zu mir kommen und sagen, ich hab irgendwie was kaputt gemacht, dann gebt mir bitte Getrefflog ein, weil da sehe ich dann immer, was haben die Leute denn gemacht und kann dann noch was wiederholen. Einmal war das so, ja, ich hab hier einen neuen Orange gemacht und einen Merch-Request gemacht, aber da sind keine Änderungen drin. Dann macht man Getrefflog und da waren keine Commits da. Und das ist immer recht hilfreich. Ich meine, ich kann ja mal, hier war es ein relativ einfaches Repository, da arbeite ich nur selbst, da sieht man dann halt Commits, ist recht langweilig. Ich hab jetzt keine Arbeitsrepository, ist hier drauf, wo ich mehr tue, deswegen ist das relativ langweilig zu zeigen. Das fand ich auch spannend. Nämlich, diese, vor ein paar Tagen gab es, diese Wandsomware-Angriffe auf GitRepository, die irgendwie auf GitHub oder GitLab da waren. Und vor allem, wenn das Open Source, ich hab schon diese ganz genau verfolgt, aber wer gibt es zumindest ein bisschen verstanden hat, sollte verstehen, dass das ein verteiltes Versionsverwaltungssystem ist. Zumindest sag ich das immer den Leuten. Und wer da zahlt, ist halt blöd. Und genau, um was man da eigentlich nur tun muss, einmal den Board schon mal neu pushen und dann ist alles in Ordnung. Zumindest, wenn das ein Public-Open-Source-Repository ist, wenn das jetzt irgendwas viel im Internist ist, dann hat es ja nochmal andere Bedeutungen, weil irgendwer Zugang zum Code hatte, das kann ich jetzt nicht beeinflussen oder beurteilen, aber zumindest ist es relativ, ja, wer sollte das schon bezahlen? Weil man hatte historiale da, irgendwer hat zwar schon noch auf dem Rechner. So, wer hat da schon mal den Spaß, dass verschiedene Line-Endungen in derselben Datei, okay, das ist mehr als die Hälfte, hatte ich auch. Da habe ich auch so eine nette Anekdote, das war mal ein Uniprojekt vor so 2, 3 Jahren. Da hat er dann einer an der Datei angefasst, der hat natürlich nicht geguckt, was er verändert hat. Das sag ich da auch immer, immer schön gucken, was man verändert hat, wie man ja vorhin gelernt hat. Und er hatte dann eben komplett alle Datei-Zeilenenden verdreht und hat es dann einfach gepusht und es war halt alles kaputt. Irgendwie von Windows auf Linux gibt es aber recht einfache Methode, um das zu verhindern. Dafür muss man das entweder lokal machen, da kann man eben Auto CLF auf true setzen und dann macht er die Umwandlung automatisch. Das heißt, unter Windows macht er den automatisch beim Einchecken dann eben ein Line-Feed draus und beim Auschecken halt wieder umgekehrt. Und das Ganze ist aber halt durf, weil ich glaube jetzt viele werden hier wahrscheinlich Mac oder Linux nutzen oder sowas und eher in kleinen Tallwindows und dass man dann zu jedem Person hingehen muss und dass man eintippen muss. Bei meistens machen die Leute die Fehler, die es irgendwie nicht so gut kennen. Was man aber auch machen kann, ist ein Git Attributes File anlegen und da diese Zeile einfügen, das muss man in jedem Repository machen, dann sorgt das automatisch dafür, dass es halt richtig umgewandelt wird. Das macht das Ganze ein bisschen einfacher. Zumindest nachdem ich das umgestellt habe, hatte ich damit keine Probleme mehr. Und das ist dann eigentlich recht angenehm. So, weitere blöde Ideen, damit sind wir auch schon fast am Ende. Das habe ich auch mal gesehen, Remote Bunches genauso benennen wie lokale Bunches. Also wenn man jetzt irgendwie Origin Slash Master hat, dass man einen lokalen Bunch hat, der Origin Slash Master hat, der aber ein lokaler Bunches und kein Remote Bunch ist, das ist immer sehr irritierend, wenn man das sieht. Was ich auch gesehen habe, ist einer, der dann seinen lokalen Bunch, Local Bunch genannt hat. Und dann hat diesen Local Bunch gepusht und das sieht halt total komisch aus. Weil wenn man den Bunch, namens Local Push, dann ok. Mitten im Rebase-Vorgang sein ohne es zu merken, ist auch toll. Da kommt nämlich immer die Frage, ok ich habe hier, also was halt ich mache ein Rebase und da muss man da ein Konflikt fixen. Man hat aber nicht Rebase-Continue gemacht. Entsprechend läuft das nicht so ganz weiter. Aber man macht schon fleißig weiter Komits und am Ende sagt man so, meine Änderung ist weg und gehe ich hin, ok geht Status. Und was sieht man da, Rebase im Gange oder irgendwie sowas. Und ja und dann merken sie, oh ich habe es ja nicht abgeschlossen. Auch eine schlechte Idee. Was ich dazu sagen kann ist, es gibt einen Springer für die Kommando-Zeile. Ich glaube oh my Git oder oh my ZSH, kennen vielleicht einige. Da kann man Git konfigurieren, so dass dann immer schön drin steht, welcher Bunch mit welchen Änderungen drin sind. Ich persönlich nutze zum Beispiel Liquid Prompt, das ist zum Beispiel das hier. Wo ich jetzt zum Beispiel direkt sehe, ich bin auf Bunch Master, habe 3 Sachen hinzugefügt, 3 Zeilen hinzugefügt und kein und eins auf und keine entfernt und wenn ich jetzt mal einen Commit mache, was wollte ich noch mal nicht verwenden, genau. Dann sehe ich auch ok, ich habe einen Commit den ich noch nicht gepusht habe und da sehe ich sehr schnell, ob irgendwas im Gange ist, was ich hätte fixen sollen. Genau, weil so sieht man jetzt direkt, ok, ich bin im Rebase Vorgang und dann ist das kaum zu übersehen, weil mancher passiert mir das ja auch, also eigentlich nicht, aber weil ich das eben sehe und kann das dann direkt halt eben fixen und gut ist. So, das habe ich nämlich auch mal gesehen und kürzlich kam ein Kollege zu mir und ich habe gesagt, was hältst du davon, wenn man Bunch ist merged, indem man einzelne Dateien rüber kopiert? Da kam ich jetzt auch noch nicht auf die Idee, fand ich auch spannend, weil gibt es schöne Befehle, gibt es ein Merch oder auch SVN Merch, da kenne ich mich so, weil da gibt es halt welche, die kopieren sich dann halt die Dateien von einzelnen Bunches, dann irgendwie in den aktuellen Bunch und nennen dann den Commit dann Merch, Bunch, irgendwas, dabei gibt es eine schöne Konkurrenzion. Sollte man nicht tun, ist alles ein bisschen komplizierter, als man es eigentlich machen sollte. Nicht baubarer oder ausführbarer Commits spielt ein bisschen auf das von vorhin mit dem Git-By-Sect an, ist immer praktisch, wenn man einen Commit hat, der sich kompilieren und bauen lässt, je nachdem, was das jetzt für ein Projekt ist, weil dann kann man Git-By-Sect auswählen, wenn man mal Probleme hat und dafür gibt es auch die ICD Pipelines, um das Ganze zu automatisieren und dann sieht man relativ früh, wenn was kaputt geht. Genau, das war es. Gibt es Fragen? Also Fragen, Anmerkungen, andere Ideen, die man nicht tun sollte? Wie willst du nicht komplierbare Commits verhindern, wenn ein Merch von mehreren Commits über ein Pro-Request reingeht und dazwischen andere Waren vorher? Verhindern ist schwierig. Man sollte halt selbst darauf aufpassen, würde ich sagen. Also irgendwo muss man natürlich zwischen technischen und sozialen Problemen gucken, weil da muss man irgendwie selbst gucken. Also richtig, ich glaube bei GitLab oder GitHub ist es meist ein bisschen schwieriger jeden Commit, weil da macht er meist nur den letzten Commit, aber wenn man lokal arbeitet, kann man das zum Beispiel verhindern. Also das ist ein bisschen, habe ich jetzt keine Patentlosung für hinter dir? Wie du das schon sehr schön erwähnt hast, GitSubmodules ist so eine Sache. Aber in der Praxis hat man sie ja dann doch immer wieder und alles ein gigantisches Reboot zu werfen, das ist auch keine gute Lösung. Pest oder Koffer rein? Ist irgendwas besser wie das? Ja, also kommt auch an, wie man fragt. Wenn man Google fragt, die haben alles in einem riesen Reboot drin, das ist glaube ich kein GitRebo, aber die haben diese Monorepos, Facebook auch, die haben auch Mercurial glaube ich. Ich selbst, ich würde einmal gucken, wie es sich einbinden lässt. Ich hatte ein Projekt gehabt, da waren dann irgendwelche Liveboots als Submodules eingebunden. Die haben sich alle jeden paar Monate mal, gab es noch was Neues und konnte uns dann hochziehen. Je häufiger man die Submodules hochziehen kann man immer ein bisschen darauf an. Also Patentlösung gibt es halt nicht. Wenn man richtig nutzt, ist es okay. Es ist immer abhängig. Also es kommt darauf an. Da vorne. Da. Ich habe noch einen schönen Vorschlag für Dinge, die man nicht tun sollte, wenn man sich die eigene History anguckt und einen Komet findet, für den man sich schämt. Da gibt es das schöne GitHub-Projekt in dem ich jetzt auf der Fokussport zu gehen. Hast du das schon mal gemacht? Hat die Person es denn gemerkt? Später gemerkt. Noch irgendwelche Fragen, Anmerkungen, Ideen, was gefehlt hat. Du hattest eben kurz erwähnt, dass du die Geier auf Deutsch hattest und das auf Englisch haben wolltest, dann kannst du da keine haben. Du hast wahrscheinlich die locale auf C gestellt. Ja, genau. Das war nur weil es abgestürzt ist. Die locale C.utf8, das ist dann auch Englisch kann, aber auch nicht Englisch. Stimmt, guter Hinweis. Also ich nutze halt GUI Tools eigentlich gar nicht, von daher ist das. Ich wollte nur sagen, es gibt ja wirklich gute GUI Tools, so in Wim und Emacs vor allem. Das letzte Wort habe mich ganz verstanden. Git GUI gehört aber nichts dazu. Ich habe irgendwann mal rausbekommen, das tut auch manchmal einfach so Git-Gabbage-Collector anwerfen, wenn es startet. Das heißt, ja, wenn man vielleicht so manchmal doch mit verloren hat und denkt man, oh ja, ich kann da noch Git reflog ausführen, da ist ja noch der commit drin. Oh, nee, der commit ist gar nicht mehr drin. Ah, ich habe in der Zwischenzeit Git GUI aufgerufen und das hat ihn einfach gelöscht. Ja, also es gibt ein paar GUI Tools, die ich okay finde, also unter Windows zum Beispiel Source Tree, aber Git Kraken gibt es ja, was so ein Elektron App ist, aber meistens gucke ich auch nur damit die Historianer nutzt damit nichts. Deswegen kann ich da auch gar nicht so viel zu sagen. So, noch irgendwer. Genau, ansonsten, ich bin heute noch da, morgen nicht mehr. Also wenn irgendwas ist, spreche ich euch an. Ich weiß ja nicht, ich knabber nur. Dankeschön.