 Ja, also, hallo erst mal und das ist mein Talk. Komet Makrami ist was, was ein Bekannter von mir immer sagt, wenn er auf Arbeit in die schlimmsten Probleme mit Git reinläuft oder mit seinen Kollegen, je nachdem. Nur, dass ich es noch mal sage, ich setze es so ein bisschen voraus, dass jeder von euch schon mal mit Git gearbeitet hat oder so. Sonst ist es vielleicht auch witzig, aber nur weil alle anderen lachen. Ja, also, meine Idee ist im Prinzip, Git ist gar nicht so schwer zu halten, wenn man sich an eine handvoll Dinge hält. Ich hab die jetzt mal irgendwie in drei Sachen zusammengefasst, die man machen könnte oder machen sollte, meiner Meinung nach. Und ich geh die mal ab und was passiert, was alles passieren kann, wenn man sich nicht dranhält. Zum einen hat Git halt einen bestimmten Scope, wurde quasi dafür gemacht, dass Quelltext gemanagt wird. Und wenn man außerhalb dieses Scopes Dinge tut, sollte man sich vielleicht immer mal überlegen, ob das eine gute Idee ist. Also, wenn ihr eure Fotosammlung in Git einspeist, dann ... ja. Das andere, der zweite Punkt ist ein bisschen kontrovers, aber Git befördert quasi, dass man am Ende eine lesbare und logisch aufeinander folgende History mit logischen Commits hat. Komm ich nachher noch zu, gibt Leute, die finden das nicht so gut, aber ich stell mich mal mehr auf die Seite der Leute, die Git so benutzen wollen, dass diese Features eingesetzt werden. Und das Letzte ist halt, wer History anfasst, die andere schon gesehen haben, und zwar nicht auf dem eigenen Bildschirm, sondern auf der eigenen Maschine, der hat halt echt ein Problem, und zwar mehr mit seinen Kollegen. Wer so ein Push minus F aufs Report tut, das ist in den seltensten Fällen eine gute Idee. Das sind so die drei Dinge, die ich abgrasen will und dann so ein bisschen erzähle. Das sind größtenteils Sachen, die mir passiert sind beim Arbeiten im Studium, drum rum, und Sachen, die Freunden Bekannten passiert sind. Und paar öffentlich gewordene Fälle. Ja, genau. Der Scope von Git, wie gesagt, kommt eigentlich aus dem Kernelumfeld, um Quelltext zu verwalten. Und gibt ein paar Sachen, die dabei nicht so bedacht wurden und nicht zentral für Git sind. Und das Erste ist riesige Dateien. Also, ich weiß nicht, wer von euch schon mal versucht hat, so eine 2-Gigabyte-Datei ins Git reinzufüttern. Es ist halt keine gute Idee, ja? Git nimmt sich dessen an und versucht es auch ganz gut, und das macht zwischen den verschiedenen Commits dann Delta-Compression, was Mittelgut funktioniert, vor allem, wenn sich die Datei gelegentlich ändert. Das Git da ein bisschen überfordert. Es macht, dass euer Repo super lahm ist, wenn so ein Checkout plötzlich vier Minuten dauert. Und das ist bei uns passiert, ja? Wir sind von irgendwie 20 Sekunden in einem schon mittelgroßen Repo auf vier Minuten gegangen, weil Leute halt eine Riesendatei reingetan haben. Das sorgt auch nur für Uns Zufriedenheit. Und auf dieses Problem sind auch schon gefühlte 50.000 Leute gestoßen, und deshalb gibt es gefühlte 70.000 Lösungen für das Problem. Und man kann die einfach benutzen. Viele davon basieren auch auf Git. Git, Annex, Git, Bup, Git. LFS, das ist relativ neu, Git, FED. Also, die gehen alle unterschiedlich ran, aber es gibt sie, und man kann sie einfach nehmen, ja? Oder tut die Riesendateien woanders hin? Auf euren privaten FDPs, aber das ist völlig egal. Ins Git-Repo vielleicht nicht. Im richtig schlimmen Fall, wenn ihr super der Gitner seid, nicht ohne Git auskommt, nehmt euch ein Submodul dafür, ja? Macht ein eigenes Repo für Riesendateien, das super langsam ist, und dann benutzt das halt niemand von eurem Kollegen, besser als nix war. Ja, genau. Und die riesigen Dateien kommen oft als Binarys daher, ja? Binarys im Git sind auch so eine Sache. Gibt natürlich immer Randfälle, bevor ihr mir hinterher ankommt, aber wir hatten diesen einen wichtigen Fall. Ja, es gibt Randfälle, da kann man das machen. Diese eine Binary, an die ihr nie wieder herankommt, oder die ihr jedes Mal cross-compile'n müsstet, auf dem Rechner, der im Keller steht, hinter drei Mauern. Aber ansonsten, man kann ja Diffs über Binarys machen. Das ging eine Weile, inzwischen sagt Git ja von alleine. Bei Git-Diff, ja, nee, und übrigens, da hat sich noch eine Binary verändert. Aber eine Weile lang, sah's so aus. Verändert ihr ein Bild, kriegt ihr ein Diff. Von Git ist halt keine mitgeholfen, ja? Also, echt mal überlegen, wie man's macht. Bildsysteme sind auch nicht so teuer, und mit nicht so teuer meine ich meistens kostenlos. Man kann echt gucken, dass die Binarys irgendwo anders herkommen oder irgendwo anders hinkommen. Und im schlimmsten Fall, ja, einfach ein Git-Ignore. Das bringt uns zum nächsten Teil. Wenn man halt kein ordentliches Git-Ignore hat, dann habt ihr alles in eurem Repo, ja? Oder ihr nicht, weil ihr macht ja alles richtig. Aber eure Kollegen, euer dummer Kollege, ihr kennt ihn, der ist ein bisschen doof und wahrscheinlich wieder am liebsten SVN benutzt und erzählt euch. Zweimal die Woche, in SVN wär das alles kein Problem, ja? Und dieser Kollege, dieser Kollege hat kein Git-Ignore, oder es interessiert ihn einfach nicht. Und der committed ... Gefühl seiner halbe PyTarm-Umgebung, ja? Ähm, der committed alle seine Swap- und Temp-Falls. Und ... Und ja, alles, was er zum Komplieren braucht, ja? Wenn ihr mal mit Leuten an Papers zusammenarbeitet, dann kommt da alle Dinge, die Latech zwischendurch ausspuckt, mit rein. Ganz viel Spaß. Kann ich echt versichern, wenn ihr Merch-Konflikte in so einer Aug-Start-High habt. Ha, ha, ha, ha, ha. Auch wo bin ich von Latech? Oder ihr benutzt ein Git-Ignore. Ähm, ergänzend zum Git-Ignore, wollte ich noch sagen. Man kann natürlich auch Release-Branches nehmen. Man kann ja mal so was in Release-Branchen decken, falls man nur über Git-Deployt. Dann hat man halt dafür ein Branch oder ein Commit, wo die Sachen drin stehen, die der Kunde unbedingt haben will. Wie, kein kostenloses Bildsystem leisten kann oder so? Ich weiß nicht. Aber was ich noch sagen wollte und was viele nicht machen, obwohl sie es machen könnten, also gerade so Leute, die immer den selben Editor verwenden, der immer dieselbe Outfond, Swap oder Temp-Files bauen. Wim-User zum Beispiel. Es gibt das Feature des Excludes. Man kann für sich auf seinem Rechner ein systemweites Git-Exclude bauen und sagen, ich werde nie in meinem Leben diese Wim-Swap-Files kommenten wollen. Dann sage ich dem Git halt wirklich deutlich. Kannste ja immer noch. Aber so ein Exclude macht halt alles besser, weil man sich nicht immer am Anfang des Projekts überlegen muss. Oh, richtig! Jetzt habe ich nur Dateien gefasst, ja ungünstig. Ich wollte davor noch einen Git-Ignore bauen. Ist empfehlenswert? Eine letzte Sache, die nur grob in den Scope gehört, weil Git kann eigentlich echt gut mit vielen Dateien. Git ist nicht schlecht mit vielen Dateien und auch nicht mit vielen Dateien, die sich häufig ändern. Aber es ist was, was in einem Bekannten von mir passiert ist. Die haben Git benutzt, um ihre Switch-Configs alle fünf Minuten von ihren Maschinen zu holen und einen automatischen Komet hinterherzuschieben, wenn sich was geändert hat. Ja, jetzt haben die Switches sich ja auch nicht ständig geändert, aber irgendwann ging es nicht mehr. Und sie haben nachgeguckt und es hat gesagt, fein, das System ist voll. Git ist ja nicht so groß, also es war voll viel Platz, aber waren halt die eine uns alle, ne? Weil ... ist halt ungünstig. Und auf so einem Kleinen läuft ja der Garbage-Collector auch nicht ständig. Haben sie ihn also angestoßen? Und der ist fünf Stunden gelaufen. Also, vielleicht, wenn man weiß, dass man mit vielen Dateien arbeitet, lohnt es sich auch mal, so einen Garbage-Collector anzustoßen, regelmäßig anzustoßen, nur so, ganz viele andere reinstolpern. Ja. Wie viele Dateien sehen wir jetzt? Million oder draußen? Es waren 400 Switches und halt alle fünf Minuten abgerufen, wenn sich halt mal was geändert hat. Aber das Ding ist ja, sind nicht diese Dateien, nicht diese 400 Dateien, ist der Git-Object-Store. Der heißt zwar Object-Store, aber es ist natürlich am Ende, sind es trotzdem nur Dateien auf eurem Datei-System. Ich war tatsächlich auf dieser Maschine nicht drauf, ich hab nur die Logs hinterher gesehen, und hinterher wieder eine und ein Star waren. Gott sei Dank, sonst wär ich echt doof gewesen. Ja, aber das ist quasi, wenn man den Scope von Git überschreitet, dann wird's all überlegt, wie gesagt. Es gibt ja auch die schönen Zusatz-Tools, Git, Annex, Git. LFS ist grade, glaub ich, von Git rausgekommen und so. Der zweite Teil ist Logische Commits, Logische History. Wie gesagt, da scheinen sich die Geister ja manche Leute sagen, das Schummelei und Lüge, wenn ihr hinterher eure History anpasst. Weil, das ist ja nicht ehrlich, ja. Da könnte ja jeder herkommen und sagen, guck mal, das sind meine zwei tollen Commits, mit denen ich dieses Feature geschafft hab aus dem Handgelenk. Während in Wirklichkeit damals Will fahre. Andere Leute sagen, ja, aber es ist doch ganz nett, wenn man sich durch so ein Repolist oder mal nachvollziehen will, was passiert ist, wenn man irgendwie ein Gefühl dafür bekommen kann, ohne dass man jeden Irgendwie jedes Entwickler nachvollziehen muss, ja. Jetzt habe ich diese Bibliothek probiert, ging nicht. Nächste Ahnung, nee, ging auch nicht. Oh, jetzt ist mir aufgefallen, ich soll hier vielleicht mein Passwort ändern. Jetzt geht's. Es ist sehr umständig, ich bin insgesamt mehr auf der Seite der Leute, die das vertreten, das kann sich ja jeder auch selbst aussuchen. Ich stelle hier nur die Sachen vor, die dagegen verstoßen. Und natürlich, die History, die man ändert, ist immer die nur lokale eigene. Das bekommen wir ja noch, ja. Wenn ihr schon gepusht habt und dann sagt, aber eigentlich sollten diese 12 Commits, zwei Commits sein. Und ihr schiebt das hinterher, denn ... ... ihr geben euch wahrscheinlich die Kollegen aufs Brot. Also, jedenfalls, das Erste, und ich sage kurz was dazu, da oben läuft What The Commit durch, das ist eine Webseite und ein Git-Rebo, wo Leute committen können, was sie ... Richtig. Äh, es ist fein, kann ich jedem empfehlen. Tut euren Scheiß dazu. Das Ding ist, solche Commit-Messages hat jeder von euch schon geschrieben. Und wahrscheinlich jeder auch mal geschrieben. Also, ich weiß nicht, wie es euch geht, aber ... Okay, vielleicht nicht so lyrisch. Aber, ja, man, also, nachts um zwölf, das ist jetzt der Backfix. Und ich geh jetzt schlafen, ja, scheiß drauf. Soll halt die anderen klarkommen? Äh, FU-Commits. Ihr macht euch halt keine Freunde damit, ne? Ist klar. Es ist halt für euch jetzt witzig. Für euch super witzig. Und ... Äh, wir ... Äh, wir ... Aber es macht euch langfristig keine Freunde bei Kollegen. Und was ... Okay, vielleicht auch so. So. Macht euch keine Freunde, ja. ich nicht. Ja, versprochen. Irgendwann weißt du, in den Hintern ist es so. Deshalb ordentlich Comic-Messages. Echt besser. Ich weiß nicht. Ich hoffe, ihr lest XKCD, dann kennt ihr den vielleicht auch, weil je später es wird, desto sinnvoller die Comic-Messages im Allgemeinen. Also, bei euch bestimmt nicht. Ihr macht's ja richtig, ja. Ja, ähm, ja, ähm, lass mich mal weitermachen, ja. Was? Ja, okay. Guckt, äh, ich, ähm, nee, also, was ich davor sagen wollte, ähm, riesige Commits sind doof, ja. Das ist quasi der erste Teil. Ich hab, ähm, jemanden mit dem ich zusammenarbeiten, äh, gearbeitet habe, für lange Zeit, der kam, äh, tatsächlich von SVN und das war auch, der Grund für seinen Verhalten, der hatte, äh, seine Comic-Zeiten, ja. Der hat jeden Mittwoch und jeden Freitag um 14 Uhr seinen Comic-Zeiten. Nein, ungelogen, ja, so was gibt es. Und dann war das halt immer so, Freitag 14 Uhr, grob, ja, so, wenn die Mittagspause durch war und hier, dann war das halt so, ich habe Feature A, B und C fertig, ich habe den Duck 65 gefixt und äh, so ein bisschen den Code-Style angepasst, ja. Äh, und dann war das erst mal, wow, du warst ja produktiv, ja, hast du schick gemacht, aber wenn der Comic mal irgendwie all war, dann konnten wir halt nicht hingehen und sagen, ja, wir rewarten den, ja. Sondern stattdessen haben wir halt gesagt, ja, ist all, ne. Also entweder wir klamüsern den jetzt auseinander oder wir fixen es magisch so. Es ist halt, man kann es nicht gut nachvollziehen und das ist ja eine der drei Sachen, für die Commits eigentlich gut sind, ne. Es ist damit ihr noch nachvollziehen könnt, was ihr gemacht habt, in welchen Schritten, ja, soll Menschen lesbar sein, äh, soll irgendwie äh, für euch rückgängig machbar sein, ja, für, für den üblichen Menschen nicht einen Fuck-up und es soll irgendwie für die Maschine sinnvoll sein, falls ihr mal tatsächlich einen Bug suchen müsst, nicht nur in so, keine Ahnung, ich hab hier 20 Commits und irgendwo hab ich was falsch gemacht, sondern mehr so, ich hab hier 400 Commits und was zum Fick geht vor sich. Äh, und dann wollt ihr Git-By-Sect laufen lassen, ja. Und äh, das sind quasi die drei Sachen für die Commits wirklich wirklich wichtig, also für die die Größe von so einem Comet wichtig ist. Und deshalb sind nämlich auch Winz-Commits scheiße, ja, das ist der nächste Punkt. Winzige Commits, wenn ihr so sagt, oh ja, ich hab's jetzt mal probiert. Nächster Comet. Ja, jetzt sollte es funktionieren. Nächster Comet, jetzt funktioniert es. Nächster Comet, jetzt funktioniert es wirklich. Und dann noch so ein Bugfix-Comet hinterher. Und das Ding ist, es passiert ja jedes Mal und das ist ja auch okay, also ich mach das ja auch bei mir lokal, ja, weil man will ja die verschiedenen Revisionen haben, ja, man will ja erst mal, bevor das Feature funktioniert, vielleicht die verschiedenen Irrwege dann noch sehen, nachvollziehen, vielleicht auch zurückverfolgen. Aber wenn man so was pusht und es dann in aller Mitarbeiter und Öffentlichkeit, History rumliegt, ist es halt echt ätzend, ja, weil das Git-By-Sect hängt sich da gerne dran auf, ja, findet halt zum Beispiel den ersten Fehler und sagt er, da ist der Fehler. Ist aber gar nicht, weil die Version vom Quelltex ist in Wirklichkeit nicht durchgekommen. Und jeder, der wissen will, was passiert ist und sich ins Repo einarbeitet, sieht halt wirklich eure 10, 12 Mal probieren Comets statt irgendwie zwei, drei schön zusammengefasst, die zusammen mein Feature bilden. Das ist, das kann ich nicht so empfehlen. Das sind quasi die drei Sachen, ja. Gute Comet-Messages, keine unfassbar großen Mega-Comets und auch keine Dial-Comets für, es ist nicht mal das halbe Feature fertig. Also, wenn man es logisch einteilen kann, ja, aber wenn nicht, dann nicht. Und dann kommen wir zu den Branches, ja. Es gibt Leute, die entwickeln ohne Feature-Branche, ja, ohne irgendwelche Feature-Branches, ohne nicht mal sonst was, die entwickeln auf ihrem Master. Wenn sie richtig, richtig geil sind, entwickeln sie auf ihrem Development-Branche und pushen Sachen, funktionieren zum Master, ja. Das Problem ist, wenn man das alleine macht, dann geht es gerade noch so an. Aber wenn man, also selbst wenn man alleine ist, das ist eigentlich ja mit Feature-Branches besser, geht mir so, wenn man es mal probiert hat. Aber wenn man das mit anderen zusammen macht, dann sind es halt meinetwegen fünf Leute, zehn Leute, 20 Leute, wie viele Entwickler habt ihr in dem Team? Und die Branchen dann nicht wirklich raus, ja? Die haben nur ihren halt lokalen Development-Branche zum Remote. Und immer, wenn sie pushen wollen, ist da ein magischer Merchkonflikt. Und dann pullen sie erst mal. Und weil es ja nicht ihr seid, sondern eure doven Kollegen, kennen die vielleicht nicht mal, dass man Pull minus, minus Rebase machen kann, was ihr bitte macht, sonst, ansonsten immer. Und dann haben sie wirklich immer, egal ob sie es brauchen oder nicht, ein Merch. Immer. Immer wenn sie irgendwie auf den Master oder auf den Development-Branche gucken wollen. Es ist unübersichtlich, es ist super ätzend, ja? Also ich meine, was immer eure Guille der Wahl ist, ja, ob ihr jetzt tatsächlich Gitlock benutzt oder GitG oder GitCast. Aber wenn ihr sowas seht, ja, da ist doch schon, also... Beides, ja? Auch hier, ja? Man hat halt, hier sieht es ein bisschen übersichtlicher aus, vielleicht auch nur, weil die Linien durchgezogen sind. Weiß ich, ja? Aber es ist halt wirklich, wir branchen hier weg. Oh, und jetzt merken wir hier und wir merken nochmal. Und wir haben hier, glaube ich, mal den Unterschied. Allein nur, wenn man Pull minus, minus Rebase macht. Hier sieht es nach keinem großen Unterschied aus, ne? Aber stellt euch vor, es machen jetzt zehn Leute, entweder das obere oder das untere. Es macht halt echt einen Unterschied. Und Pull minus, minus Rebase nimmt euch halt alle Merch-Konflikte ab, dies kann, ja? Wenn es nicht kann, ja, wenn ihr tatsächlich dieselben Ecken der Dateien angefasst habt, bech. Aber meistens hilft es und bitte, bitte, tut allen den Gefallen. Das andere ist langlebige Feature-Branches. Also Feature-Branches sind ja eigentlich ganz nett. Aber wenn eure Feature-Branche dann irgendwie schon zwölf Monate existiert, ja? Und jeden Monat irgendwie so ein Merch aus dem Master oder aus dem Development-Branche bekommt, um irgendwie noch was mit eurer Code-Basis zu tun sagen, dann ist das echt, echt ungünstig. Ich glaube, wir haben hier so auch ein Bild. Das Ding ist, Git hat sogar ein Feature dafür, ja? Das ist defaultmäßig ausgeschaltet, das heißt Git-Rire-Rire, weil naming things, ja. Aber das ist dafür da, sich einmal zu merken, wie ihr eure dummen Merch-Konflikte behoben habt und es immer wieder zu machen. Bei jedem neuen Merch, der so läuft und bei jedem Rebase, der wieder so läuft. Das ist natürlich schick, dass Leute so ein Feature gebaut haben, aber ich denke, wir wollen das alle lieber nicht benutzen, so insgesamt. Also nicht, dass du gezwungen sein, das zu benutzen. Langlebige Feature-Branches. Die Scrum-Entwickler machen das ja sogar gerne so, dass ihr Feature-Branches nur für die Dauer eines Scrum-Zyklus existieren, ja? Dann werden sie zusammen zurückgemarcht, so gut es halt geht, so weit halt man fertig geworden ist. Und dann guckt man weiter. Das hat den Vorteil, dass es da relativ saubere Abschlüsse gibt und man halt nicht mit unendlich Merges arbeitet. Solchen, nämlich. Genau. Dann auch was, auf das ich heute noch gestoßen bin, als ich irgendwie Leuten so das Gitlight der Welt erzählt habe, es gibt anscheinend Leute, die machen tatsächlich jeder Def hat seinen eigenen Branch. Ja, kein Feature-Branches, sondern du arbeitest dann deinem Branch, du arbeitest dann deinem Branch, wenn ihr überschneidende Sachen macht oder zusammen, da guckt ihr halt. Das kommt wieder auf dieses lesbare History zurück, nicht? Also, wenn die Commiss in einem logischen Zusammenhang stehen, hat das schon einen Vorteil, ja? Wenn ihr gleichzeitig an drei Features entwickelt und das auf eurem eigenen privaten Schnuckelbranche macht, mäßig übersichtlich, ja? Vor allem, wenn ihr dann noch schnell ein Buckfix baut, der gerade ganz dringend ist, ja, es macht unser Bild kaputt, mach mal schnell. Um logisch zu bleiben, sind Feature-Branches gut. Okay, wir können es nochmal witziger machen. Octo-Merges. Wer von euch hatten schon mal irgendwie drei oder mehr Commiss zusammen gemarcht? Also, nicht nur zwei. Hat Spaß gemacht? Also, typischerweise macht es nicht so viel Spaß. Git kann es aber, ja? Also, Git-Merges lässt nicht so viel wie ihr wollt. Octo-Merges sind ja nur acht, ja, ist ja nix. Das kann schon bei acht Commiss zusammen schiefgehen. Im Kernel, wir haben leider keinen Bild davon gefunden, weil es irgendwie den Rahmen springt, aber man muss es sich so vorstellen, nur besser. Im Kernel wurde vor einer Weile ein Merch-Commit gepusht. Der hatte 66 Eltern. Und unser Alalinus war so stolz darauf, dass sein liebes Tool Git das geschafft hat, dass er nur so ganz leicht du-du, also, das sieht ja bei mir in der GUI jetzt nicht mehr so gut aus, beschränkt ich vielleicht auch 15 oder 10 in Zukunft gesagt hätte. Also, Cthulhu-Merges, ja? Das ist vermeidet ist, weil ihr schießt euch damit in der Regel ins Knie, ja? Wenn ihr ganz genau wisst, was ihr tut, aber selbst da im Zweifelsfall macht die Merges nacheinander. Er tut nicht mehr weh. Und wenn man so eine Datei hat, in die vier Branches reingegangen sind und die haben alle Konflikte in dieser Datei, ist das echt, echt, echt unübersichtlich, ja? Kann ich gar nicht empfehlen, ja? Wenn man diese Datei dann aufmacht, nee, das, äh, unlustig, macht man nicht. Ja, an und für sich bin ich schon durch, weil der letzte Teil ist hoffentlich jedem klar und man muss nichts dazu sagen, nicht? Weil Push minus F, Force Push auf ein Repo, das einem nicht total gehört, weil man der König des Repos ist und weiß nicht, alle Entwickler einem eh die Füße küssen, ja? Ist eine ganz, ganz schlechte Idee, weil ihr macht damit allen anderen das Leben schwer, ja? Die häufigen Fälle dafür sind so, der Komet vor all, ja? Ich hatte einen Rechtschreibfehler, ich hatte einen Kommerfehler in meiner Komet-Message, das geht so nicht, ja? Ich habe ihn aber schon gepusht, aber ich habe ja gelernt, ich kann einen Komet ermenden. Da mache ich das schnell und püsche ihn hinterher, ja? Es haben aber schon in der Zwischenzeit drei Leute gepult, weil ja, da habe ich das jetzt nach der Mittagspause aufgefallen oder so, ja? Und dann ist der Ärger groß. In dem Büro, in dem ich zu lässt gearbeitet hatte, hatten wir tatsächlich einen dieser schnuppigen USB-Raketenwerfer in der Mitte des Büros montiert und wenn jemand entweder den Bild gebrochen hat oder die Tests oder sowas gemacht hat, ja? Push minus F, dann hat sich der so gedreht. Hat gut funktioniert, ja? Also, plus die Leute wohnen dann irgendwie immer den Rest des Tages getistet. Also, Peer Pressure kann auch zu guten Dingen verwendet werden in solchen Fällen, ja? Sonst eher nicht. Der andere? Oh, die History wäre hässlich, ja? Dasselbe, dass wir vorhin hatten, als was Gutes, ja? Ihr nehmt eure eigenen Comments und schuft es da, die so ein bisschen zusammen, dass sie hübscher sind, ist hier so, waah, was ich da letzte Woche gebaut hab, war ja nicht so hübsch, ja. Also eigentlich hätte ich das eleganter machen sollen, ja? Wenn ich clever gewesen wäre, hätte ich die Lösung gleich gesehen, ich tue mal, als wäre ich clever, ja? Und dann macht ihr so einen hübschen Rebase und Interactive Rebase auf der Geschichte, die schon irgendwie fünf Leute gepullt haben und dann pusht ihr den und dann, wenn die das nächste Mal pullen, dann weiß ich nicht. Kommen die zu euch ins Büro und fragen kräftig nach, was da eigentlich los ist. Äh, auch nicht gut, aber es gibt natürlich da Ausnahmen, nicht? Klar, wenn euch das Repo gehört oder wenn ihr einen großen Filterbranche drauf machen müsst, weil doch irgendwas durchgerutscht ist, was nicht hätte durchrutschen sollen? Und ihr wisst, wer das schon gepullt hat, ja? Also, das ist eine andere Variante. Ihr wisst, genau, dieses Repo ist nicht der Außenwelt zugänglich, das sind nur die drei Hanseln, die hier eben mit mir im Büro rumgammeln. Den kann ich mal sagen, äh, Leute, können wir da mal aufräumen und ihr klont das alles neu und dann ist alles gut. Aber wie gesagt, Ausnahmefelder im allgemeinen Push minus F keine gute Idee. Ähm, auf dazu eine schöne Geschichte, es hatten, äh, ich glaube, Jenkins Entwickler vor ein paar Jahren mal geschafft, ausversehen, auf 150 GitHub-Repos ein Force Push zu machen und den Master da umzusetzen. Und, das ist halt nicht so Jud, nicht? Äh, und er hat das quasi nur dem Umstand zu verdanken, dass der Kunden Support von GitHub so kompetent wie freundlich ist und ihm tatsächlich ganz schnell in allen, äh, in allen diesen 150 Repos übers Reflog rausgesucht hat, wo der Master denn davor gewesen ist und ihm das geschickt hat mit einem, hier, ne? Das sind die Hashes, jetzt machen wir. Äh, auch da im Übrigen, ja, immer wenn ihr zu einem Repo pusht, ich weiß nicht, wahrscheinlich wissen das alle und nur mir ist das noch nie aufgefallen oder so, aber es sagt euch sowohl den, den Hash von dem Komet, äh, der, der quasi vorher, der, an der Branche-Spitze war, auf die ihr schreibt und der, der es jetzt ist. Also, ihr habt da zwei Hashes stehen in Kursform und, das heißt, für eine Weile, je nachdem, wie lang eure Shell-History so ist, falls ihr, falls ihr geht über die Shell-Bedient, äh, habt ihr das da stehen und könnt noch mal nachgucken, falls irgendwie Reflog nicht euer Ding ist oder euer Reflog zu unübersichtlich ist, weil ihr in den letzten drei Stunden irgendwie in alle Branches das Repos geguckt habt oder so. Ja. Und letzte ist noch, ja, ähm, Dollsgid-Feature, ihr könnt ja sehr gut spezifizieren von welchem Branche, auf welchem Branche ihr pushen wollt, wenn ihr das wollt und wenn ihr das könnt und wenn ihr das nicht könnt oder unaufmerksam seid oder zu viel Chunk getrunken habt und plötzlich steht da so ein Doppelpunkt an der falschen Stelle, dann ist der Remote-Branch halt weg, ja, lässt sich alles fixen, aber auch das vorsichtig sein, nicht empfehlenswert und am besten keine super cleveren Sachen probieren, ja. Bringt euch nicht um, wenn eure Branches so heißen, wie sie auf dem Remote heißen, zum Beispiel, oder wenn ihr brav eure Tracking-Branches einrichtet und so. Ja. Jo. Deshalb war den, den, den Scope von Gitbeachten vernünftige Commits machen, die vernünftig zusammengehören und nicht auf öffentliche Geschichte zu greifen. Die alle schon kennen. Das war's. Jo. Halbe Stunde, also quasi knackig, wenn ihr noch Fragen oder Kommentare habt oder sagen wollt, dass das alles völlig falsch ist und ihr das in Wirklichkeit besser macht, dann macht's zu. Haben wir irgendwie Mikros dafür oder? Dankeschön. Nope. Also ich höre dich. Ich kann das auch einfach noch mal sagen, was du gesagt hast. Du kannst es auch so sagen und ich sag's hier vorne noch mal laut. Also ich sag's laut, gibt es überhaupt einen Grund, einen dersten Branches, wenn man Glohn hat, hatten wir ja quasi schon Branches. Was ist Begründung für so Leute? Für die Entwickler, die für jeden Entwickler einen Branch haben? Was der Grund dafür ist? Wie ist Icke? Also da dachte wohl mal jemand, wir kommen uns weniger in die Quere, vielleicht hat jemand mal geärgert, dass immer, wenn er pushen wollte, erst mal pullen musste oder so, dann hat er sich gedacht, wäre die Welt nicht schön, wenn ich das Rehbo für mich alleine hätte. Und dann hat er sich ein Defra... Ich weiß es wirklich nicht. Also es ist mir untergekommen. Ich weiß, dass es in Wirklichkeit passiert ist, ob die Leute dabei gedacht haben. Schwierig. Na klar. Auch kommt, dass es geht. Ich hätte auf dem Vortrag über Wim vs. E-Max halten können und da hätte ich das Meinung. Vielleicht geht es ja wohl auch. Ja, Thomas. Ich habe plötzlich in einem Projekt, das ist eine Direktorin, unbenannt. Und ich hatte auf dem alten Projekt, dass ein Haufen Komits noch, die ich noch nachteilig mörschen wollte, dann habe ich gemörgt, die Stabilität ist schlau. Das hat also die meisten Parteien dann richtig zugeordnet, obwohl sich der Fahrt geändert hatte. Aber manchmal kriegt es nicht hin. Gibt es darin einen Trick? Also, haben es alle gehört, Neva? Also die Frage war, jemand hat Dateien verschoben, einen Ordner unbenannt letztlich und hat es dann mit einem anderen Branch gemörscht, wo schon einiges passiert war in der Zwischenzeit und die meisten Fays hat, gibt es richtig zugeordnet, trotz unterschiedlichem Fahrt, aber manche nicht. Warum das so ist? An und für sich ist ja geht ganz gut damit. Es gibt ja auch Git-Move, um Dateien zu verschieben. Ich weiß nicht, ob du das benutzt hast. Aber was dahinter letztlich passiert ist, wenn ich mich richtig erinnere, dass Git quasi guckt, wie ähnlich Dateien sind. Man kann das anscheinend mit Git-Move ein bisschen besser machen, das Git ein bisschen mehr Hintergrundwissen darüber hat. Aber an und für sich guckt Git ja für so was an, sind sich die Dateien ähnlich genug? Ja, aber wenn Git quasi nicht genug Ähnlichkeit sieht, um zu sehen, das ist dieselbe Datei, nicht? Noch mal for the record anscheinend gibt es ein Kommandozeilen Parameter, mit dem man regeln kann, wie gut Git das erkennt. Git ist ja bekannt für die benutzerfreundliche und einfache UI auch in der Konsole. Was auch sein kann ist, weil Git ja an sich kein Ordner kennt, hast du da neue Dateien eingekriegt? Weil er hat den neuen Fahrt nicht gesehen, als zu verschieben, weil er kennt ja keine Ordner, sind eine Ecke mit Fahrt und hat die Verhandlungen dann verschoben, also die Neuen nicht. Wenn ob die Dateien, die Git nicht erkannt hat, neue Dateien waren, die in dem Branchen, also tendenziell Git-Magie. Also der Fall war, er hat dann gesagt, dass wir den Lokal Renovation hätten, deshalb hat man den Alpen auch noch wieder angelegen, die der Trader einfach eingeschmissen. Nicht gerade das Renovation kam da, weil ich es halt unbeleidigt habe. Wesig. Aber anscheinend gibt es da Parameter für, die machen das Git, das viel besser kann. Sonst auch wer? Ich sehe auch nicht wirklich was. Das ist jetzt keine Frage, das ist was, was ich heute mal hatte. Diskussion, ja. Es ist vielleicht vielen ja auch bekannt, die Standard-Einstellung, weil gibt es das vom Betriebssystem, erkannt wird, ob sich der Teilnahme geändert hat oder nicht, und wenn man wie nur einen kleinen Sturm, einen großen Sturm in einer Dateien haben, dann kann das wirklich, aber nicht mehr so unterschiedlich erkannt werden. Stimmt, es gibt irgendwie Betriebssysteme, oder, ja? Das ist gut zu wissen. Also, wer mehr can the case unter Windows einfügt, der hat da eventuell Probleme mit. Ist das ja, okay? Ich finde den zweiten Punkt gut mit so einer wirklichen Geschichte, und das, was man am Bisszündern hat, wobei es, was man so überwärtschmeißt, wenn man diese Kurdern zu vergessen hat und ähnliches, der ganze Vortrag ist aber welches Gefühl sehr software-zentral, software-Effektions-zentral im Sinne von ich habe eine Workstation, auf der ich wirklich meine Software, und wenn die dann geht, dann kommentiere ich meine Changes und ähnliches. Es gibt inzwischen so einen Trend, das nennt sich, ich glaube, software-defined Infrastructure, so wie Puppet, Chef und ähnliches, wo dann von zentraler Massmaster und ähnliches das, was eben repositoriert ist, auscheckt und dann wie ich erst sehe, was ich gerade kommentiert habe, sprich meine... Das klingt nach einer Schregenart, Puppet zu halten, aber okay. Mein Arbeitszyklus ist halt nicht, ich kann es testen, nicht unbedingt, nicht unbedingt. Ich habe nicht nur eine Testumgierung und das, was ich gerade verändere, im Code zu testen, sondern ich muss es erst kommenten, damit dann ein Master irgendwie guckt, ob es irgendwo läuft, sprich, das weiß ich eigentlich nicht. Das ist richtig, und das sind natürlich Sachen, die man sich überlegen sollte, wenn man so ein Set-up nimmt, nicht? Ich wollte mal etwas anmerken und sagen, das habe ich im Scope. Das ist ein richtiges Scope von Git, das so reinzuwenden. Doch schon, klar ist das im Scope von Git, aber dann hat man halt ein Haufen, nee, doch nicht, da hat ein Komma gefehlt. Komm jetzt. Aber dann unterläufst du ja das, was sich mal Leute für einen Workflow gedacht haben, das ist ja immer nicht so die geiste Lösung. Also ja, es ist nicht universell gültig. Klar, Menschen, Leute, Wortmeldung, Wortmeldung. Das, ja, ich habe auch mit solchen Menschen zusammengearbeitet. Das einzige, was ich sagen kann, dann liegt erst mal das, und wenn ihr damit fertig seid, dann liegt der Merch halt an euch. Dann müsst ihr halt seinen Comet und euren letzten von Ülfigen Comet... Er hat euch halt erfolgreich dann die Arbeit übergeholfen. Alternativ auch Git Revert als... Da muss man dann halt gucken, wie gerade der Zusammenspiel von diesem externen und eurer Firma und im Saftverhältnungschef ist. Ja, aber man kommt da raus. Dafür geht immerhin grad noch mächtig genug. Ja, also überhaupt erst mal gucken, was Git tut. Also auch falls ihr irgendwie Leuten Git beibringt, prügelt ihnen ein, Git-Status zu benutzen. Einfach immer, weil sonst kommen sie zu euch und sagen, es tut nicht. Vielleicht lesen sie grad noch so weit, dass Git da schreibt, ja, tut nicht, benutzt Push-F, weil Git ja hilfreich ist. Ganz ehrlich, Leuten Git beizubringen, dann sagt ihr ihn im Prinzip, ja, was Git sagt, ist eigentlich hilfreich. Außer, dass es sagt Push-Mioself dann. Aber ich hab nicht viel auf der Gugge reingegossen. Weil du wundervolle Antwort. Dann muss es ruhig sein. Dann kann man nichts machen. Noch? Push-Mios-End Git ist auch eine Pull, irgendwie, das Musik vorher ausgemacht. Nein, du kannst Fetch machen, nicht? Du kannst erst Fetch'en und dann Diffen und gucken, was... Ohne was zu transferieren geht nicht. Nein, du musst ja irgendwie sehen, was da ist. Irgendwie müssen die Sachen schon transferiert werden. Das ist schön, ich hab auch nichts gegen Makuri. Vielleicht bin ich glücklich, ja. Kommt, ich lass mir gern auch noch mehr erzählen. Geht alles in den nächsten Workshop. Kriegsgeschichten, dafür sind wir hier. Das ist nur 1998. Wer weiß noch, was im Kontrollell ist. Das ist ein H-Feed, also wir haben H-Feeds, und so ist es gut gehabt. Zu viel, viel selber kommt, damit ich ohne Probleme klar. Aber die tut es von drum. Einige zeigen es einfach nicht an. Irgendwann haben das alles ausgeblissen und das Diffen sah dann quasi leer aus. Also quasi, die GUI ist drum herum, meinst du? Das kannst du dir auch nicht ausdenken, oder? Das ist schon schick. Das klingt witzig. Also auch überhaupt sind Git-GUIs, es gibt einige echt gute und es gibt einige nicht mal so gute, und sie haben alle ihre Stärken und Schwächen nicht. Also zum Beispiel, die Freunde bei GNOME haben ja GitG neulich von einem Jahr oder so neu geschrieben. Und ich weiß nicht, wie es inzwischen ist, aber als es mal rauskam, habe ich mal ein bisschen getestet und ich habe es im Linux-Repot ausgeführt und dann habe ich dann auch noch ein paar H-Feeds ausgeführt und dann hat es halt in meinen Ramm gefressen und ist gestorben. Es ist halt ein großes Repot, ja, kannst du nichts machen, aber man kann es ja vielleicht trotzdem anzeigen. Also, nicht? Ja, also gute Git-GUIs finden es ehemaliger. Ein bisschen weiter, aber auch sehr lustig, wenn man nach einer Firma kommt, und auf dem Rehmband entwickelt, und es plötzlich noch ein anderes Rehmband gibt, das Querkennigkeiten hat. Und dann die Leute kommen, ja, das funktioniert jetzt und repot auf dem Branch. Submodules? Git-Submodules, wo du ein Repot in das andere einbettest und sagst, welche Version zusammen gehört. Ich weiß, hat seine Probleme. Git-Submodules sind relativ umständlich, aber das willst du dir, glaube ich, in dem Fall mal angucken, ja. Ja, die sind ja, also es sind immer noch zwei einzelne Repots, nur das eine weiß, ich brauche diese Version vom anderen, oder diesen Branch vom anderen. Ja, oder Abkennigkeiten auflösen, das ist auch schick. Man muss auch sagen, das geht nicht dafür da, von Kommunikation zu befreien. Nee, nee. Eine Hilfe und kein Ersatz. Ja, es kommt halt aus dem Kernumfeld. Ja, du schickst ja auch immer noch deine Patches per Mail. Du schickst doch bestimmt deine Patches noch per Mail. Nein, aber nee, klar. Leider, leider befreit uns Git nicht völlig von unseren Mitmenschen. Ja. Außer, sie machen alles richtig, so wie ihr alles richtig macht, dann ist das reibend. Stimmt. Menschen, Leute, Thomas? Sorry. So Services bewerfen, wo man dann irgendwie so seinen Projekt, Fortschritt mit zum Kappchen irgendwie visualisieren kann auf irgendwie extra ein Web Service. Das kann man als ein Gitarren kcoppeln und das will dann also Report Zugriff, inclusive Reit, da habe ich immer so ein ganz schlechtes Definientemarkt gegen. Ich habe so ein Tool noch nicht benutzt. Schreibzugriff auf's Repo geben, dann würde ich halt genau, wenn ich eine vernünftige Kopie vom Repo hätte, wüsste, dass irgendwo ein Backup ist, das benutzbar ist, ja? Weil, wie auch was war das KDE oder so? Irgendwann mal bemerkt hat, Versionskontrolle ist kein Backup, ja? Dinge können immer noch degradieren und wenn das nicht rechtzeitig gemerkt wird, dann sind sie das halt überall. Backups separat. Das hat fast das KDE-Rebo oder so geschrottet. Es war bemerkenswert groß. Du wolltest noch was, oder? Nicht steigen, nicht steigen. Ja, also klar. Um Leuten Git beizubringen, was man da alles für Hürden durchläuft, das ist ja nochmal ein eigenes Thema. Also ich habe ja morgen den Git und GitHub Workshop vor mir, wo ich versuche, Leuten in zwei Stunden Git und GitHub so weit nahezubringen, dass die anderen Leuten nicht zu sehr auf die Füße treten und ja, ich bin gespannt, wie weit wir dabei kommen. Aber es ist halt klar, also da zum Lernen kannst du Leuten einfach mal ihren Branch geben, weil dann macht ihr nichts kaputt. Ja, klar. Das ging jetzt schon um Produktiveinsatz. Menschen, Leute, Dinge? Wortmeldungen? Ja, also zu den Feature Branches. Also erstens macht es Sinn, seine Feature Branches sinnvoll zu benennen, nicht Patch 1, Patch 2, Patch 3. So wie das geht, wenn man automatisch auf der Webseite forkt. Ging davon aus, dass es quasi mit den Commit-Messages, aber ja, benennt auch Branches. Aber was ich sehr sinnvoll finde, wenn man hier rebased, gibt es einen, also erst mal gibt es einen Option für Git Merge, glaube ich minus G oder so, die sagt, macht immer einen Merge Commit. Und ich finde das sehr sinnvoll, wenn man da weiß, hier, also hier ist jetzt so ein bisschen History passiert und ich sehe ja nicht mal, dass das ein eigener Branch war, aber dadurch, dass ich jetzt einen Merge Commit erstelle, sehe ich jetzt, oh, hier ist das und sage, History zu Ende und hier ist, da fängt was neu an. Das gibt es in einigen Workflows. Also ich glaube auch Git Flow schreibt in Wirklichkeit vor, dass manche Merge Commits immer, also nie fast forward sind, immer einen extra Merge Commit haben, oder? Was? Ja, also ich sag ja, dass die nicht fast forward sind. Alle, die in den Development Branch gehen, glaube ich, oder? Alle Merges von Feature Branches in Development Branches dürfen nicht fast forward sein, damit du genau das hast. Den klaren Development Branch mit Fortschritten. Ja, also, aber ja, es ist auf jeden Fall gut im Hinterkopf zu haben, dass man sich quasi in manchen Fällen aussuchen kann, ob man diesen Merge Commit will oder nicht. In anderen, vielleicht auch nicht. Ja. Ja, wenn das jetzt noch ein Commit ist oder so, macht das noch besser. Ja. Sonst noch was? Noch mehr Geschichten? Noch haben wir Zeit. Nee? Okay, dann sind wir hier fertig. Danke, dass ich hier war.