WEBVTT NOTE Podcast: Wo wir sind ist vorne. Episode: Oh Git oh Gott! mit Michael van Engelshoven Publishing Date: 2021-04-18T10:59:00+02:00 Podcast URL: https://wowirsindistvorne.show Episode URL: https://wowirsindistvorne.show/oh-git-oh-gott-mit-michael-van-engelshoven/ 00:00:00.000 --> 00:00:03.400 Wo wir sind, ist vorne, Folge 25, heute geht's um Git. 00:00:03.400 --> 00:00:19.660 Herzlich willkommen bei Wo wir sind, ist vorne. 00:00:19.660 --> 00:00:22.460 Frontend-Fakten-Frotzeleien. 00:00:22.460 --> 00:00:26.480 Der Late-Night-Frontend-Talkshow rund um Webdesign und Entwicklung. 00:00:29.480 --> 00:00:38.180 Es reden sich um Head und Kragen, HTML-Fundamentalist Moritz Gießmann und JavaScript-Jongleur Konstantin Groß. 00:00:38.180 --> 00:00:47.480 Heute zu Gast, Webworker und Git-Versteher Michael van Engelshoven. 00:00:47.480 --> 00:00:58.440 Herzlich willkommen bei Wo wir sind, ist vorne, Folge 25. 00:00:58.960 --> 00:01:03.280 Wir haben das Viertelhundert voll gemacht oder keine Ahnung, ob man das so nennt. 00:01:03.280 --> 00:01:04.380 Wie man das so sagt, ja. 00:01:04.380 --> 00:01:05.660 Ja, genau. 00:01:05.660 --> 00:01:09.780 Heute zu Gast, wie ihr schon gehört habt, Michael van Engelshoven. 00:01:09.780 --> 00:01:10.500 Hi. 00:01:10.500 --> 00:01:11.340 Hi. 00:01:11.340 --> 00:01:11.880 Hi. 00:01:13.000 --> 00:01:29.540 So, und wir reden heute über Git, weil wir haben ja in den vergangenen Folgen schon öfter mal gesagt, wir sind beide Git-Anwender, der Konstantin und ich, aber wir haben immer mal wieder das ein oder andere Problem gehabt und wir haben uns heute Verstärkung geholt, um da mal ein bisschen drüber zu sprechen, ein bisschen Licht in unser Git-Dunkel zu bringen. 00:01:30.400 --> 00:01:30.820 Hoffentlich. 00:01:30.820 --> 00:01:32.380 Ja, auf jeden Fall. 00:01:32.380 --> 00:01:34.540 Wir haben große Hoffnungen in dich. 00:01:34.540 --> 00:01:37.780 Genau. 00:01:37.780 --> 00:01:42.040 So, sollen wir direkt zum Getränk voranschreiten. 00:01:43.520 --> 00:01:44.680 Ja, was hast du denn, erzähl mal. 00:01:44.680 --> 00:01:57.280 Ja, ich habe mal wieder ein Augustiner-Helles. Das habe ich jetzt öfter, weil es ist eine ganze Kiste bei mir angekommen und ich trinke ja nur beim Podcast oder beim Stream Bier und auch nicht immer und deswegen hält das jetzt die nächste. 00:01:57.280 --> 00:01:58.960 Okay, also bis zu Folge 29. 00:01:58.960 --> 00:02:04.220 Ja, stimmt. Vielleicht, ich weiß nicht, ob ich bei jedem Stream, naja, wie auch immer. 00:02:04.220 --> 00:02:06.960 Ach nee, im Podcast 29, da sieht man meine mathematische Kenntnisse wieder. 00:02:06.960 --> 00:02:07.200 Ja. 00:02:07.200 --> 00:02:10.100 25 und 24 ist 29. 00:02:10.100 --> 00:02:11.400 Genau. 00:02:11.400 --> 00:02:14.120 So, Konstantin, was trinkst du? 00:02:14.120 --> 00:02:16.280 Ich trinke heute Wasser und Almdudler. 00:02:16.280 --> 00:02:17.100 Ja. 00:02:17.100 --> 00:02:22.600 Ich habe das blöde Gefühl, schon wieder krank zu werden und da wollte ich meinem Körper nicht noch zusätzlich Alkohol zumuten. 00:02:22.600 --> 00:02:25.180 Okay, gut. Michael? 00:02:25.180 --> 00:02:26.580 Hast du auch was? 00:02:26.580 --> 00:02:30.540 Ich bin ja hier im Kölner Heizdrucksgebiet und darum trinke ich in Kölsch. 00:02:30.540 --> 00:02:32.060 Ah, okay. 00:02:32.060 --> 00:02:34.540 Es war heute ein Mühl in Kölsch von der Malzmühle. 00:02:34.540 --> 00:02:39.260 Sehr gut. Habe ich auch noch nie gehört. Also, dann zum Roll oder so? 00:02:39.260 --> 00:02:39.460 Zum Roll. 00:02:39.460 --> 00:02:40.380 Zack. 00:02:40.380 --> 00:02:42.320 Und, äh. 00:02:42.320 --> 00:02:46.500 Dazu brauchen wir mal eine zweite Lasche. Das ist der Soundeffekt. 00:02:46.500 --> 00:02:47.160 Remote, ja. 00:02:47.160 --> 00:02:49.740 Ja. 00:02:49.740 --> 00:02:53.180 Ich überbrücke mal. 00:02:53.180 --> 00:02:55.880 Man könnte den Eindruck gewinnen, dass wir 00:02:55.880 --> 00:03:00.300 nur Gäste und Gästinnen mit Fun im Namen oder mit Verwandtschaftsverhältnis einladen. 00:03:01.060 --> 00:03:02.240 Was ja fast dasselbe ist. 00:03:02.240 --> 00:03:06.440 Ach so, die müssen nicht miteinander verwandt sein, aber mit einem von uns. 00:03:06.440 --> 00:03:10.680 Weil wir hatten jetzt Gerrit van Aken, meinen Bruder und jetzt dich. 00:03:11.560 --> 00:03:14.880 Aber dem ist natürlich nicht so. Also, es darf auch jemand anders mal kommen. 00:03:14.880 --> 00:03:16.340 Vielleicht stimmt's ja auch. 00:03:17.340 --> 00:03:18.540 Das müssen wir jetzt durchziehen. 00:03:18.540 --> 00:03:21.780 Müssen alle anderen wieder ausladen, die wir vielleicht schon eingeladen haben. 00:03:21.780 --> 00:03:22.540 Wer weiß. 00:03:22.540 --> 00:03:25.140 Könnte früher oder später zu einer Herausforderung werden. 00:03:25.140 --> 00:03:25.400 Ja. 00:03:25.400 --> 00:03:29.260 Oder wir müssen halt dann auf holländisch senden. 00:03:29.260 --> 00:03:33.100 Da gibt's, glaube ich, mehr Auswahl an Fans, wenn wir dann holländische Gäste einladen. 00:03:35.020 --> 00:03:35.300 Ja. 00:03:35.300 --> 00:03:36.780 Mensch, ja. 00:03:36.780 --> 00:03:39.140 Wollen wir mal zur Retro kommen? 00:03:39.140 --> 00:03:40.360 Oder hast du noch was zur Begrüßung? 00:03:40.360 --> 00:03:40.700 Nee, noch nicht. 00:03:40.700 --> 00:03:41.660 Es steht noch was. 00:03:41.660 --> 00:03:43.520 Es steht noch was im Trello in unserem Geheimen. 00:03:43.520 --> 00:03:43.660 Ja. 00:03:43.660 --> 00:03:45.620 Ich muss hier auf einem Bildschirm hin und her switchen. 00:03:46.620 --> 00:03:47.740 Ach ja, genau. 00:03:47.740 --> 00:03:52.940 Mensch, Michael, erzähl doch mal kurz irgendwie, was du so tust, dass man dich so ein bisschen 00:03:52.940 --> 00:03:56.240 einordnen kann für die, die dich jetzt irgendwie noch nicht kennen. Also, was machst du? Was 00:03:56.240 --> 00:03:58.100 tust du? Wer bist du? 00:03:58.100 --> 00:04:04.500 Ja, ich bin der Michael von Engelshofen. Ich bin JavaScript-Entwickler bei der Brambits GmbH 00:04:04.500 --> 00:04:10.500 in Köln und bin da angestellt als Lead-Entwickler. Mach eigentlich hauptsächlich Frontend-Arbeiten 00:04:10.500 --> 00:04:16.540 von morgens bis abends. Und ja, um das auch schön mit meinen Kollegen zu teilen, 00:04:16.620 --> 00:04:17.840 benutze ich da auch regelmäßig Git. 00:04:17.840 --> 00:04:24.580 Cool. Okay, das sind ja super Voraussetzungen für unsere heutige Git-Folge. Und dann können 00:04:24.580 --> 00:04:39.340 wir jetzt zur D-Retro. 00:04:39.340 --> 00:04:45.340 Ja, wir werden jedes Mal, ich würde nicht sagen, besser anders von der Grammatik her. 00:04:45.900 --> 00:04:46.220 Naja. 00:04:46.220 --> 00:04:48.440 Ja, Mensch. 00:04:48.440 --> 00:04:49.700 Ich fang an, ne? 00:04:49.700 --> 00:04:50.200 Ja. 00:04:50.200 --> 00:04:54.260 Haben wir jetzt rumgeschoben. Ich bin heute so verstrahlt und verplant. Und der Grund kommt 00:04:54.260 --> 00:04:58.440 jetzt auch gleich als erster Retro-Punkt. Mein Computer ist kaputt. Also mein Arbeitsrechner 00:04:58.440 --> 00:05:02.580 hier im Homeoffice, den ich also sowohl zum Arbeiten als auch für unsere Streamer-Reihen 00:05:02.580 --> 00:05:07.680 und Podcaster-Reihen brauche. Und der hat sich nach unserem letzten Stream letzten Freitag 00:05:07.680 --> 00:05:11.660 hat er sich einfach verabschiedet am nächsten Morgen. Fuhr er nicht mehr hoch, hat nur einmal 00:05:11.660 --> 00:05:15.820 kurz geklackert. Und dann erscheint 0-0 auf dem Mainboard und dann macht er das gleiche 00:05:15.820 --> 00:05:17.280 Spiel von vorne und das macht er so lange bis... 00:05:17.280 --> 00:05:18.120 Der vorletzte. 00:05:18.120 --> 00:05:18.940 Der vorletzte. 00:05:18.940 --> 00:05:19.660 Das war der vorletzte. 00:05:19.660 --> 00:05:19.900 Der vorletzte. 00:05:19.900 --> 00:05:24.700 Ach, wir haben ja am Mittwoch nochmal gestreamt. Ja, stimmt. Ja, sonst ging es ja gar nicht. 00:05:24.700 --> 00:05:29.020 Sonst wäre der nächste Retro-Punkt gar nicht entstanden. Genau. Ja, und jetzt ist immer 00:05:29.020 --> 00:05:34.480 diese blöde Frage. Alles natürlich abgekabelt und rausgebaut und versucht hochzufahren. 00:05:35.160 --> 00:05:39.640 Entweder Mainboard oder CPU. Es werden noch Wetten angenommen, aber es ist immer so blöd 00:05:39.640 --> 00:05:43.240 zu debuggen, wenn man jetzt nicht gerade selber irgendwie das durchmessen kann und so. 00:05:43.240 --> 00:05:49.280 Ja, und ich kann auf jeden Fall sagen, was der Konstantin selbst nicht sieht, gerade, weil 00:05:49.280 --> 00:05:52.800 er in meine Richtung guckt, ist, hinter ihm steht der Rechner auch. Ich kann ihn sehen. 00:05:52.800 --> 00:05:54.820 Komplett ausgehöhlt, ausgeweidet. 00:05:54.820 --> 00:05:58.820 Power, genau. Man kann reingucken. Sieht nicht so gesund aus gerade. 00:05:58.820 --> 00:06:00.120 Nee, ist auch nichts. Ist nichts mehr drin. 00:06:00.120 --> 00:06:05.360 Ja, genau. War es, war es? Bist du damit... 00:06:05.360 --> 00:06:08.940 Ja, das war... Also mehr hat sich in meinem Leben irgendwie nicht ergeben, die letzten zwei Wochen. 00:06:08.940 --> 00:06:14.200 Sonst war einfach gar nichts. Es ist nichts passiert, außer dass der Rechner kaputt gegangen ist. 00:06:14.200 --> 00:06:18.220 Okay, na, das ist ja auch ein okayes Leben, glaube ich, wenn man sonst keine Probleme hat. 00:06:18.220 --> 00:06:18.900 Wenn es sonst nichts gibt, oder? Ja. 00:06:18.900 --> 00:06:20.900 Ja, mein... 00:06:20.900 --> 00:06:22.000 Ist ja schon drama genug. 00:06:22.000 --> 00:06:23.000 Ja, richtig. 00:06:24.580 --> 00:06:28.580 Ja, stimmt. Das kann schon durchaus sehr dramatisch sein, je nachdem, wie wichtig das als Arbeitsgerät ist. 00:06:28.580 --> 00:06:34.580 Ja, also in unserer Branche, würde ich mal sagen. Also ich kann es auch auf Papier schreiben, aber... 00:06:34.580 --> 00:06:37.220 Naja, du hast ja offenbar noch ein Ersatzgerät, sonst könnten wir gerade nicht aufnehmen. 00:06:37.220 --> 00:06:40.640 Den Laptop. Den Laptop, von dem ich letztens schon erzählt habe, dass er mir fast abgeraucht wäre. 00:06:40.640 --> 00:06:41.980 Naja, noch lebt er. 00:06:41.980 --> 00:06:45.020 Deswegen hoffe ich mal erhält. Aber deswegen bin ich heute so ein bisschen gehandicapt. 00:06:45.020 --> 00:06:53.060 Habe halt nur einen Bildschirm, der auch noch relativ klein ist und muss hier zwischen Trello und Jitsi und Studio Link und Reaper und allem hin und her schalten. 00:06:53.220 --> 00:06:56.940 Also ich bin, also ja, wie gesagt, ein bisschen durch den Wind. 00:06:57.220 --> 00:07:16.280 Was auch gehandicapt war, war, Achtung, krasse Überleitung, mein MacBook beim letzten Stream, nämlich dadurch, dass Konstantins Rechner, der immer unseren Stream so schön gemacht hat, mit seiner wahrscheinlich dicken Grafikkarte drin, kaputt ist, mussten wir jetzt umsteigen auf mein Gerät. 00:07:21.220 --> 00:07:38.060 Ich habe den MacBook Air mit Apple Silicon M1 Prozessor zum ersten Mal an die Grenzen gebracht, wo ich dann dachte, okay, jetzt ist irgendwie Ende, weil wir wollten streamen und wir haben da mehrere Stunden damit verbracht, das einzurichten und hatten sehr große Probleme damit, den Stream stabil zu kriegen. 00:07:38.160 --> 00:07:47.320 Vor allem der Sound hat große Probleme gemacht, hat immer wieder rumgeknackst. Und das war wohl später im Stream auch nochmal so, aber immer dann, wenn ich irgendwie noch ein extra Browserfenster aufgemacht habe. 00:07:47.620 --> 00:07:51.840 Also es war wohl wirklich ein Ressourcenproblem, so Rendering-seitig. 00:07:51.840 --> 00:07:57.060 Aber ist doch mal ein schönes Benchmark, oder? So ein neues Gerät und dann erstmal austesten, wo liegen denn die Grenzen? 00:07:58.120 --> 00:08:10.620 Ja, also Live-Video-Rendering scheint, also auf dem Prozessor, scheint irgendwie schwierig zu sein. Ich rendere sonst irgendwie nicht viel Video, also das ist ein Fall, den hätte ich jetzt sonst nicht getestet. 00:08:11.520 --> 00:08:24.400 Aber es gibt vielleicht Abhilfe, weil, wie ich gerade gesagt habe, auf dem Prozessor, die aktuelle OBS-Version, die wir da einsetzen, die hat das, die unterstützt noch nicht den M1-Prozessor. 00:08:24.900 --> 00:08:29.600 Das heißt, man kann kein Hardware-Video-Rendering machen, sondern es läuft halt echt alles auf der CPU. 00:08:29.600 --> 00:08:37.240 Aber der aktuelle Release-Candidate von OBS, 27 ist das, glaube ich, Release-Candidate 2, da kann man das wieder einschalten. 00:08:37.240 --> 00:08:42.480 Und wir haben es jetzt noch nicht getestet, aber sind guter Dinge, dass das vielleicht was bringt dann am Ende. 00:08:42.480 --> 00:08:48.920 Also mein erster Test war von 20% CPU beim Recording runter auf 6 oder 7. 00:08:48.920 --> 00:08:54.020 Allerdings im Stream haben wir es noch nicht getestet. Wir müssen mal gucken, vielleicht geht es ja dann trotzdem. 00:08:54.020 --> 00:09:05.140 Und ich meine, dann ist dem Spaß ja wieder keine Grenze gesetzt, weil dann wird das Ding so verwendet, wie man es verwenden soll und die Hardware wird ausgenutzt und dann kann man damit doch streamen. 00:09:05.140 --> 00:09:06.440 Also wir werden es sehen. 00:09:06.440 --> 00:09:10.000 Ansonsten, vielleicht läuft ja bis zum übernächsten Stream mein Rechner wieder tatsächlich. 00:09:10.000 --> 00:09:16.900 Und für den nächsten Stream, vielleicht kann man das auch schon vorwegnehmen, haben wir ja nicht irgendwelches Codesharing geplant, sondern dann machen wir was anderes. 00:09:16.900 --> 00:09:20.180 Sollen wir es schon spoilern, was wir vorhaben? 00:09:20.180 --> 00:09:22.420 Ja, du kannst es ruhig spoilern, ich habe es schon vergessen. 00:09:23.140 --> 00:09:26.360 Achso, wir streamen ja am Dienstag statt am Mittwoch nächste Woche. 00:09:26.360 --> 00:09:29.080 Achso, das wusste ich noch gar nicht. 00:09:29.080 --> 00:09:29.940 Nein, nein, nein. 00:09:29.940 --> 00:09:31.020 Da hast du mich doch gefragt. 00:09:31.020 --> 00:09:34.260 Ich habe dich gefragt, aber du hast gesagt, du musst das noch abklären. 00:09:34.280 --> 00:09:35.600 Ich habe doch gesagt, das passt, habe ich nicht gesagt. 00:09:35.600 --> 00:09:36.660 Also Moritz, das passt. 00:09:36.660 --> 00:09:56.160 Okay, das wird ein bisschen verrückt, weil ich, ja, das müssen wir auf jeden Fall erzählen, weil ich als mittlerweile sehr, sehr neuer Apple-Fanboy und früher Apple-Kritiker, wir haben uns überlegt, wir könnten die Apple-Keynote am Dienstag kommentieren. 00:09:56.660 --> 00:10:02.300 Und der Konstantin, und es ergibt sich eine interessante Geschichte draus, weil, wie gesagt, ich bin ein frischgebackener Fanboy. 00:10:02.880 --> 00:10:05.740 Und der Konstantin ist immer noch sehr Apple-kritisch. 00:10:05.740 --> 00:10:08.740 Und ich glaube, das könnte interessant werden. 00:10:08.740 --> 00:10:10.400 Aber auch nicht mehr so kritisch wie früher. 00:10:10.400 --> 00:10:11.820 Wie wir da drauf reagieren. 00:10:11.820 --> 00:10:13.340 Allerdings, ich glaube, streamen dürfen wir es nicht. 00:10:13.340 --> 00:10:14.740 Wir dürfen es nicht einblenden oder so. 00:10:14.740 --> 00:10:16.340 Wir können quasi nur drauf reagieren. 00:10:16.340 --> 00:10:17.320 Machen wir einen Live-Kommentar. 00:10:17.320 --> 00:10:18.460 WWSV-Reacts. 00:10:19.040 --> 00:10:23.160 Und vielleicht interessiert es jemanden, vielleicht interessiert es auch einfach gar niemanden. 00:10:23.160 --> 00:10:23.740 Es macht nichts. 00:10:23.740 --> 00:10:27.900 Dann sind wir einen Tag näher am Affiliate bei Twitch. 00:10:27.900 --> 00:10:29.460 Das könnte vielleicht ganz witzig werden. 00:10:29.460 --> 00:10:41.740 Also, ich glaube, gerade weil nicht nur Fans dann zuschauen, sondern eben auch du dann als Kritiker, sage ich mal, könnte das durchaus interessant werden, wie unterschiedlich die Reaktionen zu bestimmten Sachen ausfallen. 00:10:41.740 --> 00:10:43.880 Oder du sagst, what the fuck, was ist das für ein Quatsch? 00:10:43.880 --> 00:10:48.660 Und dann sage ich, ah, das ist total geil, weil du musst hier, das ist total super. 00:10:48.660 --> 00:10:49.100 Gucken wir mal. 00:10:49.100 --> 00:10:50.680 Schauen wir mal. 00:10:50.680 --> 00:10:56.340 Vielleicht wartet der Konstantin mit seinem neuen Rechner oder seinen Reparaturen dann noch bis nach der Keynote. 00:10:56.340 --> 00:10:58.140 Ach so, ach so. 00:10:58.140 --> 00:11:02.740 Ja, ich habe ihm auch schon gesagt, das ist jetzt ein super Zeitpunkt, um es richtig zu kaufen. 00:11:02.740 --> 00:11:04.080 Ja, mal gucken. 00:11:04.080 --> 00:11:04.900 Mal gucken. 00:11:04.900 --> 00:11:07.460 Ja, okay, gut. 00:11:07.460 --> 00:11:10.480 Dann, äh, Michael, du hast auch einen Retro-Punkt mitgebracht. 00:11:10.920 --> 00:11:13.140 Ich habe auch einen Retro-Punkt mitgebracht. 00:11:13.140 --> 00:11:19.220 Wir sind gerade ein bisschen dabei, unsere Website von Bootstrap-Utilities auf Tailwind umzubauen. 00:11:19.220 --> 00:11:21.500 Nicht nur, weil es hip ist. 00:11:21.500 --> 00:11:24.120 Ich glaube auch fest daran, dass alles besser werden wird. 00:11:24.120 --> 00:11:29.660 Gerade diese Mischung aus, das gibt es als Bootstrap-Utility, das nicht. 00:11:29.660 --> 00:11:32.700 Und dann habe ich jetzt so CSS und Utility-Klassen gemischt. 00:11:32.700 --> 00:11:34.860 Darum geht es mir aber nicht. 00:11:34.860 --> 00:11:39.860 Davon wollen wir einfach weg und haben jetzt schon einen Haufen Utility-Klassen angepasst. 00:11:40.100 --> 00:11:45.460 Und du scrollst durch die Seite und denkst dir, hm, sieht das noch alles richtig aus oder nicht? 00:11:45.460 --> 00:11:50.300 Dann habe ich mir gedacht, boah, was echt cool wäre, wäre jetzt so ein Visual Regression-Test. 00:11:51.640 --> 00:11:55.200 Aber ich habe jetzt keine Lust, hier tagelangen Aufwand rein zu investieren. 00:11:55.200 --> 00:11:57.060 Kriege ich das nicht irgendwie schnell hin? 00:11:58.000 --> 00:12:05.480 Ich weiß, dass andere Teams bei uns sowas in der Art schon mal gemacht haben, aber die nutzen eine Plattform dafür und das war mir alles ein bisschen zu aufwendig. 00:12:05.480 --> 00:12:12.420 Und dann habe ich ein bisschen rumgegoogelt und Puppeteer kennt ihr wahrscheinlich, nehme ich an. 00:12:12.420 --> 00:12:16.200 Das ist halt ein Headless Chromium quasi, den ich mit JavaScript steuern kann. 00:12:16.720 --> 00:12:19.240 Und der ist ja auch in der Lage, Screenshots zu machen. 00:12:19.240 --> 00:12:24.140 Mit dem Parameter Full Page True kann ich mir sogar ein Screenshot von der gesamten langen Seite machen lassen. 00:12:24.140 --> 00:12:27.600 Also nicht nur von der Bildschirmgröße. 00:12:28.320 --> 00:12:31.420 Und dann bin ich auf eine Extension für Jest gestoßen. 00:12:31.420 --> 00:12:32.800 Jest, das ist so ein Testrunner. 00:12:32.800 --> 00:12:35.100 Die nennt sich Jest Image Snapshot. 00:12:35.100 --> 00:12:43.800 Und auch wenn ich jetzt kein großer Fan von Snapshot-Testing bin, was Image Snapshot quasi machen kann, ist, dass er sich diesen Buffer nimmt, 00:12:43.800 --> 00:12:49.780 also den Puppet, den er gemacht hat, und den er als Bild ablegt. 00:12:49.780 --> 00:12:57.140 Und in einem erneuten Durchlauf kann er das quasi nochmal machen und zeigt mir dann ein Diff an zwischen Stand Alt und Stand Neu. 00:12:57.880 --> 00:13:03.940 Und dann war es plötzlich total easy, Unterschiede an der Seite zu finden, tatsächlich auch noch Wax zu finden, 00:13:03.940 --> 00:13:10.940 wo Klassen nicht richtig transformiert worden sind und ja, große Angst erst gehabt. 00:13:10.940 --> 00:13:15.940 Und dann, ich glaube innerhalb von einer Stunde oder so, hatte ich ein Skript, was mir das vergleichen konnte. 00:13:15.940 --> 00:13:16.660 Cool. 00:13:16.660 --> 00:13:19.020 Ja, große Erleichterung. 00:13:19.020 --> 00:13:21.920 Zwei Probleme gab es. 00:13:21.920 --> 00:13:22.660 Selbst geschrieben? 00:13:22.660 --> 00:13:27.020 Selbst, ja, es ist, keine Ahnung, 30 Zeilen Testdatei. 00:13:27.440 --> 00:13:28.440 Okay. 00:13:28.440 --> 00:13:34.060 Letztendlich gehe ich einfach hin und schnappe mir die Sitemate-XML, die generiert da rumliegt. 00:13:34.360 --> 00:13:39.320 Also, es ist eine statische Seite mit Gatsby und dann nehme ich mir einfach die Sitemate-XML, 00:13:39.320 --> 00:13:44.480 parse dann mir alle URLs raus und rufe dann eine nach der anderen auf und mache den Vergleich. 00:13:44.480 --> 00:13:46.420 Cool. 00:13:46.420 --> 00:13:47.820 Also, ich kenne das aus Beyond Compare. 00:13:47.820 --> 00:13:48.980 Kennt ihr das, Beyond Compare? 00:13:49.140 --> 00:13:50.180 Oh ja, tatsächlich. 00:13:50.180 --> 00:13:54.140 Also, es ist zum Dateien vergleichen. 00:13:54.140 --> 00:13:55.980 Also, natürlich hauptsächlich irgendwie Textdateien. 00:13:55.980 --> 00:14:00.940 Ich habe zwei verschiedene Codestände und vergleiche die dann miteinander und kriege dann so die Diffs angezeigt, 00:14:00.940 --> 00:14:04.480 wie bei Git oder wie so GOEs für Git auch. 00:14:06.120 --> 00:14:10.760 Und man kann das aber auch benutzen für sogar Audiodateien und für Bilder. 00:14:10.760 --> 00:14:17.800 Und da habe ich das auch schon genutzt, eben eine Seite von einem auf ein anderes System, ich weiß gar nicht mehr, was es war, umgestellt und dann das miteinander verglichen. 00:14:17.900 --> 00:14:19.940 Also, das ist echt ganz praktisch, wenn man sowas hat. 00:14:19.940 --> 00:14:21.240 Ja. 00:14:21.240 --> 00:14:22.620 Aber cool. 00:14:22.620 --> 00:14:23.560 Zwei Probleme gab es letztendlich. 00:14:23.560 --> 00:14:30.080 Wir haben auf einer der Unterseiten haben wir so eine Durchlaufanimation, wo so ein Text durchläuft. 00:14:30.080 --> 00:14:34.500 Der hat natürlich nicht immer exakt die gleichen Animationsframe. 00:14:34.500 --> 00:14:46.060 Das heißt, häufig hast du dann so ein False Positive, nein, False Negative, wo der sagt, oh, die Seite ist kaputt und da guckst du rein und dann siehst du nur, dass der Text irgendwie so vier Pixel weiter oben ist oder so. 00:14:46.500 --> 00:14:47.620 Und dann weißt du Bescheid, okay. 00:14:47.620 --> 00:14:52.740 Kannst du da irgendwie so einen Threshold einstellen vielleicht, dass der das dann gar nicht bemerkt? 00:14:52.740 --> 00:14:55.380 Ja, du kannst tausend Sachen einstellen. 00:14:55.380 --> 00:15:00.120 Ich habe mich aber aufgrund des Zeitdrucks da nicht wirklich tief mit beschäftigt. 00:15:00.120 --> 00:15:04.420 Also, du kannst ihm sagen, wie viele Pixel abweichen dürfen, ganz prozentual angeben. 00:15:04.420 --> 00:15:14.820 Aber mir ging es halt wirklich darum, erstmal alles zu sehen, weil ich habe zum Beispiel auch die Underlines von den Links, die sind in den Pixel nach unten gewandert und das wollte ich schon sehen, 00:15:14.920 --> 00:15:17.660 an welchen Seiten da vielleicht was kaputt gegangen ist, etc. 00:15:17.660 --> 00:15:24.760 Ja, und bei uns werden alle Bilder gelazy loaded, also wenn das scrollt, sind die erst so geblurrt und werden dann nachgeladen. 00:15:24.760 --> 00:15:32.100 Das sorgt auch dafür, dass der Papettierer nicht immer exakt dasselbe Bild sieht. 00:15:32.100 --> 00:15:37.400 Also hast du dann häufig so bei den Bildern, dass du sagst, guck mal, das ist nur ein Ticken unscharf und das schon nicht mehr. 00:15:38.200 --> 00:15:41.500 Und da hast du dann auch so ein paar Fehler, die eigentlich keine sind. 00:15:41.500 --> 00:15:45.080 Aber ansonsten hat es super geklappt, also ich war echt erleichtert. 00:15:45.080 --> 00:15:49.160 Cool. Darf ich kurz fragen, wie macht ihr das mit dem, dass es erst geblurrt dargestellt wird? 00:15:49.320 --> 00:15:56.960 Weil da habe ich mal irgendwie so eine API gesehen, die das quasi für einen macht, die dann irgendwie so irgendwie nur 3, 4 kW groß oder sowas war das Bild dann quasi. 00:15:56.960 --> 00:15:59.000 Es sind quasi vier Pixel, die dann aufgespannt werden. 00:15:59.000 --> 00:16:01.740 Oder ist es ein eigenes Request oder in der Seite mit drin? 00:16:03.020 --> 00:16:05.840 Letztendlich, also wir machen das nicht, das bringt Gatsby quasi mit. 00:16:05.840 --> 00:16:12.240 Aber was die machen, ist, wie du schon sagst, die machen eine verkleinerte Version des Bildes, die ist, ich glaube, 5x5 Pixel oder so. 00:16:12.240 --> 00:16:15.680 Und die wird dann tatsächlich schon als Base64 ins HTML entledet. 00:16:15.680 --> 00:16:16.560 Ah, okay, Base64. 00:16:16.560 --> 00:16:19.180 Das heißt, du hast eigentlich gar keinen Request, wenn die Seite lädt. 00:16:19.180 --> 00:16:19.820 Okay, perfekt. 00:16:19.980 --> 00:16:28.260 Und wenn du dann da hinscrollst, geht dann, ja letztendlich ist es eine Rated Componential, die das macht, geht dann hin und lädt dann das richtige Bild nach. 00:16:28.260 --> 00:16:28.920 Cool. 00:16:28.920 --> 00:16:29.320 Cool. 00:16:29.320 --> 00:16:32.240 Ja, dann übernehme ich nochmal. 00:16:32.240 --> 00:16:33.680 Oder warst du fertig? 00:16:33.680 --> 00:16:34.860 Ich bin fertig. 00:16:34.860 --> 00:16:35.560 Sehr gut. 00:16:35.560 --> 00:16:37.700 Genau. 00:16:37.700 --> 00:16:39.560 Ich habe noch einen zweiten Retropunkt. 00:16:39.560 --> 00:16:43.260 Ich weiß, es ist immer schwierig, über sich selbst was Gutes zu sagen. 00:16:43.260 --> 00:16:45.100 Ich tue mir da immer schwer damit. 00:16:47.080 --> 00:16:51.920 Es ist irgendwie zu cool, als es irgendwie ein bisschen zurückzuhalten. 00:16:51.920 --> 00:17:00.880 Ich bin in den Dankesbereich eines Web-Development-Buchs gelandet, also im Vorwort sozusagen. 00:17:00.880 --> 00:17:03.100 Und das könnt ihr euch ja mal anschauen. 00:17:03.100 --> 00:17:07.520 Und zwar ist es das Web-Development-Glossary von Jens Meiert. 00:17:07.520 --> 00:17:13.600 Und da habe ich irgendwann letztes Jahr mal, also es ist schon länger her, ich habe jetzt erst herausgefunden, dass ich da drin bin. 00:17:13.600 --> 00:17:16.780 Also tatsächlich, ich glaube, es kam letztes Jahr schon raus. 00:17:17.080 --> 00:17:23.600 Und zwar habe ich da Glossar-Einträge hinzubeigesteuert über Twitter, die mit Y beginnen. 00:17:23.600 --> 00:17:24.720 Danach wurde gesucht. 00:17:26.180 --> 00:17:28.060 Mir sind da relativ viele eingefallen. 00:17:28.060 --> 00:17:31.040 Ich habe da zum Beispiel geschrieben, Jan, YQL, YSlow. 00:17:31.040 --> 00:17:33.820 Vielleicht erinnert sich der eine oder andere noch dran. 00:17:33.820 --> 00:17:39.280 Also Jan ist ja jetzt gar nicht so alt, aber YQL und YSlow sind schon eher ältere Sachen. 00:17:39.280 --> 00:17:39.560 Genau. 00:17:39.560 --> 00:17:41.820 Und da habe ich ein bisschen Dank dafür bekommen. 00:17:41.820 --> 00:17:42.720 Es hat mich sehr gefreut. 00:17:42.720 --> 00:17:44.180 Und da könnt ihr mal reinschauen. 00:17:44.180 --> 00:17:46.660 Also es hat mich, ja, ich bin gerührt. 00:17:47.220 --> 00:17:51.620 Und ich habe das mit dem Jens auch geschrieben über Twitter und da hat er gemeint, ah, das ist wie es zum ersten Mal. 00:17:51.620 --> 00:17:55.080 Ja, nach dem ersten Mal, das zweite Mal, das lässt er nicht so lange auf sich warten, hat er gemeint. 00:17:55.080 --> 00:18:00.060 Jetzt bin ich gespannt, was für Bücher ihr schreibt und wie ich euch dabei unterstützen kann. 00:18:00.060 --> 00:18:01.740 Genau. 00:18:01.740 --> 00:18:02.160 Ja, cool. 00:18:03.200 --> 00:18:03.600 Dann? 00:18:03.600 --> 00:18:04.360 Dann? 00:18:04.360 --> 00:18:04.700 Vielleicht? 00:18:04.700 --> 00:18:06.100 Kommt, vielleicht? 00:18:06.100 --> 00:18:10.060 Die Property der Woche. 00:18:10.060 --> 00:18:12.860 Hat sogar gepasst, Mensch. 00:18:12.860 --> 00:18:15.160 Ja, ich gebe mir Mühe. 00:18:15.160 --> 00:18:17.360 Also es ist mit der Grammatik, das, naja. 00:18:17.360 --> 00:18:20.580 Ja, die Property der Woche hat dieses Mal unser Gast mitgebracht. 00:18:20.580 --> 00:18:22.000 Schieß los. 00:18:22.000 --> 00:18:27.540 Ja, wahrscheinlich schlagen viele den Hände beim Kopf zusammen. 00:18:27.540 --> 00:18:29.200 Die Hände beim Kopf zusammen. 00:18:29.200 --> 00:18:30.480 Sehr gut. 00:18:32.180 --> 00:18:35.380 Für mich war es tatsächlich Object Punkt Entries. 00:18:35.380 --> 00:18:46.940 Gefühlt bin ich eigentlich immer am Bleeding Edge der Mascript Releases und nutze, was nur geht und lasse es halt vom Babel transpilieren. 00:18:46.940 --> 00:18:51.240 Aber in einem Code Review bin ich über Object Punkt Entries gestolpert. 00:18:51.240 --> 00:18:54.680 Auf den ersten Blick habe ich es gar nicht wahrgenommen. 00:18:54.680 --> 00:18:57.860 Ich dachte nur, was macht der Mensch da? 00:18:57.860 --> 00:19:00.500 Der muss doch irgendwie noch auf den Key zugreifen. 00:19:00.500 --> 00:19:01.680 Wieso geht das nicht? 00:19:02.180 --> 00:19:06.180 Was ich dann irgendwann gesehen habe, der macht gar nicht Object Keys, der macht Object Entries. 00:19:06.180 --> 00:19:15.800 Und da kriege ich statt einfach nur den Key und ich muss mein Value dann selbst nochmal über den Property Namen accessen, bekomme ich einfach beide reingereicht. 00:19:15.980 --> 00:19:19.000 Wie ich das jetzt aus RAM da mit To-Pairs und From-Pairs oder so kenne. 00:19:19.000 --> 00:19:22.020 Und da habe ich erstmal recherchiert. 00:19:22.020 --> 00:19:23.580 Seit wann gibt es das denn? 00:19:23.580 --> 00:19:26.560 Und ja, das gibt es tatsächlich seit erst 2017. 00:19:26.560 --> 00:19:30.060 Ist quasi im selben Release gekommen wie die Object Punkt Values. 00:19:30.740 --> 00:19:35.340 Und ja, ist somit auch gut supported und ja, werde ich jetzt nur noch benutzen. 00:19:35.340 --> 00:19:37.040 Spart einem viel Arbeit. 00:19:37.980 --> 00:19:40.380 Ja cool, man lernt immer wieder was Neues dazu. 00:19:40.380 --> 00:19:42.320 Auch wenn man denkt irgendwie, man kennt schon alles. 00:19:42.320 --> 00:19:49.400 Da hatten wir es auch, ich bin jetzt echt immer verwirrt, war das im Stream oder im letzten Podcast, wo wir es auch darüber hatten. 00:19:49.400 --> 00:19:52.040 Oder war es vielleicht sogar nur im Vor- und Nachgeplänkel, wo wir uns drüber unterhalten haben. 00:19:52.040 --> 00:19:57.300 Ich glaube, das war wegen Overflow X und Y im Stream, wo ich auch gesagt habe, da dachte ich, das kenne ich schon. 00:19:57.300 --> 00:20:01.180 Das kommt übrigens vielleicht demnächst nochmal als Property der Woche. 00:20:01.180 --> 00:20:06.400 Jetzt heute nicht, weil der Michael dankenswerterweise was mitgebracht hat. 00:20:06.400 --> 00:20:12.580 Und ihr kriegt bei uns immer nur eine Property pro Woche und dann müsst ihr ja wieder zwei Wochen warten, bis ihr die nächste kriegt. 00:20:12.580 --> 00:20:16.220 Mit Spenden könnte man das übrigens vielleicht verkürzen. 00:20:16.220 --> 00:20:18.740 Vielleicht, vielleicht gibt es dann auch wieder einen Spam-Spot, man munkelt. 00:20:20.500 --> 00:20:22.040 Obwohl, wir haben eine Spende gekriegt, ne? 00:20:22.040 --> 00:20:23.600 Ach, echt haben wir wieder? 00:20:23.600 --> 00:20:27.480 Ja, vielleicht reicht die ja für einen Spam-Spot. Wir haben ein Bier gesponsert bekommen. 00:20:27.480 --> 00:20:30.540 Okay, okay, dann, ja, wer weiß. Vielleicht sind es zwei Wochen. 00:20:30.540 --> 00:20:32.560 Jetzt kriege ich keinen hin. 00:20:32.560 --> 00:20:34.180 Was? 00:20:34.180 --> 00:20:35.180 So spontan. 00:20:35.180 --> 00:20:38.380 Nein, nein, nein, das machen wir ja, das machen wir nicht. 00:20:38.380 --> 00:20:39.880 Das machen wir vielleicht im Stream mal. 00:20:39.880 --> 00:20:40.240 Genau. 00:20:40.240 --> 00:20:49.260 Genau, übrigens, wenn ihr euch wundert, worüber wir reden beim Stream, wir sind seit einer Weile bei Twitch unter twitch.tv slash www.iv. 00:20:49.640 --> 00:20:57.560 Gerne mal vorbeischauen und da streamen wir ein- bis zweimal die Woche so ein bisschen Frontend, Afterwork, Aftershow-Party. 00:20:57.560 --> 00:21:02.760 Ja, ja, genau, das habe ich jetzt mal gesagt. Der Stream ist so ein bisschen die Aftershow-Party des Podcasts, habe ich so das Gefühl. 00:21:03.360 --> 00:21:14.860 Wir nehmen uns immer vor, wir machen irgendwie, oh, hier, Live-Coding und hier und da und am Schluss reden wir dann irgendwie über Entwicklersorgen und machen Gruppentherapie und kriegen private Fragen gestellt und so. 00:21:14.860 --> 00:21:16.960 Ist aber auch mal ganz gut. 00:21:16.960 --> 00:21:20.280 Ja, doch, finde ich auch. Also macht Spaß, den Austausch da zu haben. 00:21:20.280 --> 00:21:22.900 Okay. 00:21:23.280 --> 00:21:29.960 Dann können wir jetzt, oh, Mensch, sind wir schnell heute. Bisschen über 20 Minuten und wir kommen jetzt weit unter der Schrie. 00:21:29.960 --> 00:21:33.120 Hier ist WWS IV mit dem Tagesthema. 00:21:33.200 --> 00:21:38.700 Zur Grammatik. 00:21:38.700 --> 00:21:42.680 Jetzt habe ich den, habe ich den, äh, den, äh, den Jingle in dich reingespielt, sorry. 00:21:42.680 --> 00:21:45.200 Ich habe in den Jingle genommen. 00:21:45.200 --> 00:21:46.820 Also, so rum. Ja, gut. 00:21:46.820 --> 00:21:50.140 Mit der Verzögerung ist das verzeihbar. 00:21:50.140 --> 00:21:51.700 Was, Verzögerung? 00:21:52.340 --> 00:21:55.560 Ja, wir haben ja mit Sicherheit irgendwie, wir sind nicht exakt live mit Soundfordern. 00:21:55.560 --> 00:21:56.800 Circa 4 Millisekunden. 00:21:56.800 --> 00:22:00.080 Ja, wir haben es ausgemacht. 00:22:00.080 --> 00:22:00.980 Also, die spiele ich für mich. 00:22:00.980 --> 00:22:04.260 Genau, also, jetzt aber Thema. Und zwar, heute geht es um Git. 00:22:04.260 --> 00:22:12.660 Und zwar, äh, wie ich vorhin schon gesagt habe, ähm, wir haben immer mal wieder unsere kleinen oder größeren Problemchen gehabt mit Git. 00:22:12.660 --> 00:22:18.200 Und, ähm, der Michael ist heute da, um uns ein bisschen tiefer in die Materie einzuführen. 00:22:18.200 --> 00:22:26.360 Und ich glaube, wenn ich so richtige Erinnerungen habe, wollte er auch am Anfang so ein bisschen, äh, so die Grundkonzepte, ähm, mal ein bisschen näher drauf eingehen. 00:22:26.360 --> 00:22:28.180 Habe ich das richtig verstanden, Michael? 00:22:28.180 --> 00:22:33.660 Ja, ich habe mir gedacht, das ist ein guter Einstieg. Ähm, ich wollte jetzt aber keinen Frontalvortrag halten. 00:22:33.660 --> 00:22:40.760 Ich dachte, wir unterhalten uns einfach ein bisschen drüber und, ähm, gucken mal so, wem welche Konzepte bewusst sind. 00:22:40.760 --> 00:22:44.580 Also, ich denke mal, bekannt sind die meisten Sachen wahrscheinlich irgendwie jedem. 00:22:45.300 --> 00:22:50.300 Ähm, aber mir persönlich hat es einfach geholfen, den Zusammenhang so ein bisschen zu verstehen. 00:22:50.300 --> 00:23:00.060 Und dann haben sich einfach so ein paar Sachen für mich erschlossen, warum Sachen gehen können oder nicht gehen können oder warum ich in gewissen Situationen Fehler bekomme. 00:23:00.060 --> 00:23:04.060 Und, ja, deswegen dachte ich, wäre das vielleicht ein guter Einstieg. 00:23:04.060 --> 00:23:07.980 Ja, sehr gerne. Also, hilft uns bestimmt auch sehr weiter. 00:23:09.360 --> 00:23:10.880 Ja, das ist ja das Ziel heute, ne? 00:23:10.880 --> 00:23:11.240 Genau. 00:23:11.240 --> 00:23:12.880 Das ist ja quasi eine Art Therapiestunde. 00:23:12.880 --> 00:23:14.180 Genau, mal wieder. 00:23:14.180 --> 00:23:24.020 Ja, letztendlich sind wir ja dazu gekommen, ihr hattet in irgendeiner Folge, ich glaube, es war auch in einer Retrospektive, Rebase-Probleme gehabt. 00:23:24.020 --> 00:23:28.400 Und als ich das gehört habe, habe ich gedacht, Moment mal, die Situation kenne ich. 00:23:28.400 --> 00:23:30.640 Die haben wir bei uns in der Firma auch sehr häufig. 00:23:31.100 --> 00:23:33.960 Und, ähm, da kann man was gegen tun. 00:23:33.960 --> 00:23:41.180 Äh, also nicht, ähm, ich helfe dir, das Problem zu lösen, sondern, ähm, wir reden mal darüber. 00:23:41.180 --> 00:23:43.920 Das Verständnis zu schaffen, was das Problem eigentlich ist. 00:23:43.920 --> 00:23:44.740 Das Verständnis, genau. 00:23:47.240 --> 00:23:50.080 Ja, lass einfach anfangen. 00:23:50.080 --> 00:23:56.240 Äh, ich schmeiß direkt mal so ein Konzept in den Raum, ähm, und zwar, das ist das Thema Hashing. 00:23:56.240 --> 00:23:57.080 Mhm. 00:23:57.080 --> 00:23:58.880 Könnt ihr mit dem Begriff was anfangen? 00:23:58.880 --> 00:24:12.640 Ähm, äh, das ist das, was man auch sieht bei den Commits, dieser, ja, Commit-Hash halt, der da, diese, diese, äh, alphanumerischen Zeichenketten, die quasi einen Commit bezeichnen, eindeutig. 00:24:12.640 --> 00:24:13.820 Äh, genau. 00:24:13.820 --> 00:24:20.860 Ähm, und auch die Dateien an sich werden im Hintergrund irgendwie gehasht, ne, und sind dann da in dieser, in diesem Index als Hash abgelegt. 00:24:20.860 --> 00:24:22.040 Äh, genau. 00:24:22.040 --> 00:24:22.220 Richtig? 00:24:22.220 --> 00:24:25.380 Ähm, aber die Frage ist halt, wie kommt so ein Hash zusammen? 00:24:25.380 --> 00:24:42.500 Ja, also man, man spricht auch teilweise so vom kryptografischen Hashen, ähm, da gibt's verschiedene Algorithmen, äh, den SH1 oder SH256 Algorithmus, ähm, der Clou an dem Ding ist eigentlich, ähm, dass ich, ähm, wenn ich denselben Input in das Ding reinschiebe, 00:24:42.680 --> 00:25:02.280 dann bekomme ich immer exakt denselben Output aus dem Teil raus, ja, das heißt, wenn ich jetzt, ähm, mal mit einem Objekttyp anfange, und zwar mit dem Blob-Objekt, was wir so in Git haben, äh, das ist quasi meine Datei, also mein Dateienhalt, und der wird quasi durch die, die Hash-Funktion von Git gejagt, und dann kommt da so ein eindeutiger Hash raus. 00:25:02.280 --> 00:25:06.920 Und, ähm, solange die Datei dieselbe ist, ist auch der Hash immer derselbe. 00:25:06.920 --> 00:25:16.920 Gehe ich aber hin und ändere wirklich nur ein Zeichen, mache einen Zeilenumbruch weg, lösche ein Leerfeld raus, irgendwas total Triviales, ändert sich dieser Hash komplett. 00:25:16.920 --> 00:25:25.060 Ja, und, ähm, so kann ich quasi dann halt auch die Objekte quasi ablegen, indem ich die einfach hashe und den Hash quasi als Dateinamen benutze. 00:25:25.060 --> 00:25:41.060 Ja, ähm, wenn man zum Beispiel mal das Git-Verzeichnis mal reingucken würde, ähm, und, äh, jetzt nicht in der Situation ist, wo alles schon gepackt ist, sondern in einem relativ frischen Repository, ähm, dann sieht man quasi, dass da einfach Dateien angelegt werden, die haben den Hash als Dateinamen. 00:25:41.060 --> 00:25:56.860 Und, ähm, ja, wenn man direkt mal im Editor reinguckt, dann sind die schon ein bisschen komprimiert, ähm, aber es gibt einen Git-Befehl, mit dem kann man die sich dann quasi auslesen, ähm, und, ja, so legt quasi Git unsere Dateien ab. 00:25:56.860 --> 00:26:03.700 Was, äh, weißt du das, ähm, was nutzen die denn intern? Ist das SHA-1? Weil das sieht mir relativ kurz aus, das sind ja, glaube ich, 40, äh, Zeichen, ne? 00:26:03.700 --> 00:26:12.500 Ja, genau, es ist, es ist, glaube ich, noch SHA-1, äh, die sind aber dabei, ähm, auf, äh, den 256er zu wechseln. 00:26:12.500 --> 00:26:17.080 Ich meine aber, das ist noch nicht durch, weil da müsste eigentlich der Commit-Hash auch länger sein. 00:26:17.080 --> 00:26:22.420 Es ist halt ein relativ schwieriges Thema, weil wenn du natürlich den Algorithmus umstellst, dann sind die Hashes alle anderen. 00:26:22.420 --> 00:26:22.920 Ja, klar. 00:26:22.920 --> 00:26:32.880 Und, ähm, ich hab da mal so ein bisschen recherchiert, wie es da aussieht, und da gibt's dann irgendwie Übersetzungstabellen von altem Hash auf neuem Hash, die dann in den Repositories noch gelegt werden müssen. 00:26:33.700 --> 00:26:37.120 Ah, ich glaube, da steht uns eine spaßige Zeit bevor. 00:26:37.120 --> 00:26:39.740 Klingt, als könnte da viel kaputt gehen auch dabei. 00:26:39.740 --> 00:26:43.560 Wie ist das mit der Kollision bei SHA-1? 00:26:43.560 --> 00:26:53.900 Weil irgendwo hab ich, hab ich so im Vorrecherchieren gelesen, so von denen, ja, das ist quasi total unwahrscheinlich, dass zwei gleiche Dateien denselben Hash, äh, zwei unterschiedliche Dateien denselben Hash erzeugen. 00:26:53.900 --> 00:26:59.380 Aber ich meine, bei 40 Zeichen, irgendwo sind ja auch Grenzen, und da kann's ja schon Kollisionen auch geben, theoretisch, oder? 00:26:59.900 --> 00:27:14.540 Ja, ich kann dir jetzt die Wahrscheinlichkeit der Kollision nicht nennen, aber, ähm, man hat ja irgendwann gesagt, äh, SHA-1 ist nicht mehr kryptographisch sicher, weil die Wahrscheinlichkeit zu hoch ist, ähm, und dann kann natürlich potenziell ein Risiko bestehen, ne? 00:27:14.540 --> 00:27:23.200 Weil, wenn jetzt jemand hingeht und eine Datei manipuliert und das auf diese Weise schafft, dass exakt wieder derselbe Hash rauskommt, ne? 00:27:23.700 --> 00:27:46.080 Ähm, ähm, und hab dann da halt Chart, äh, Chartcode eingefügt. Ähm, was ich mir jetzt schon extrem komplex vorstelle, die Datei so zu editieren, dass ich funktionalen Chartcode da eingebaut habe, der auch nicht direkt erkannt wird, aber die Datei auch nicht unten einfach ein gigantisches Kommentar mit irgendwelchen Random-Zeichen hat, damit ich nachher wieder auf diesen Hash rauskomme. 00:27:46.860 --> 00:27:55.800 Ähm, weil es würde ja auch direkt auffallen, ähm, aber das Potenzial ist da, und da haben wir gesagt, das wollen wir nicht, ähm, eingehen, das Risiko. 00:27:55.800 --> 00:28:08.340 Wenn wir jetzt aufs, aufs, aufs Quantum, Quantum Computing, äh, drauf zusteuern, dann wird's halt vielleicht doch leichter, sowas berechnen zu lassen, also ein Skript, das quasi so lange den Code verändert, bis der Code noch funktional ist, aber trotzdem diesen Hash ergibt. 00:28:08.900 --> 00:28:12.820 Genau, und nach der KI da drauf sitzen hast, die nur sagt, der Code sieht gut aus. 00:28:12.820 --> 00:28:13.960 Genau. 00:28:13.960 --> 00:28:18.760 Ja, ach, wer will das schon, diese ganze Moderna-Technik, ne? 00:28:18.760 --> 00:28:34.300 Ja, ähm, wenn ich jetzt auch so eine Datei gehashed hab, äh, das bezieht sich ja nur auf den Content, da hab ich ja gar keinen Dateinamen drin, und, ähm, das fand ich eigentlich ganz witzig, äh, dass die Dateinamen erstmal nichts mit dem Dateinhalt zu tun haben. 00:28:34.300 --> 00:28:42.620 Ja, ähm, quasi das nächste Level von Objekten, weil gibt es quasi das Tree-Objekt, und das Tree-Objekt repräsentiert quasi ein Verzeichnis, ne? 00:28:42.620 --> 00:28:57.080 Und das, ähm, müsst ihr euch vorstellen wie einfach eine Liste von Hashes, und, ähm, da steht noch ein Typ dran, und zwar ob es ein Blob ist oder ein Tree, und somit kann ich jetzt quasi auch verschachteln, wenn ein Tree-Objekt auf ein anderes verweist, kann ich quasi, ja, auf andere Ordner verweisen. 00:28:58.140 --> 00:29:14.780 Und, ähm, ja, da steht dann quasi der Hash des entsprechenden Objekts, und dahinter steht dann der Dateiname, und, ähm, so merkt sich Git quasi, wie sieht das Verzeichnis aus, und, ähm, über den Link auf das Blob-Objekt mit Hash-XY zum Beispiel, ähm, würde, ähm, 00:29:14.780 --> 00:29:22.180 , ähm, eher dann jetzt zum Beispiel den Inhalt der Index-HTML mit dem Dateinamen Index-HTML referenzieren, ne? 00:29:22.180 --> 00:29:31.420 Was dann im Umcash-Loss halt auch bedeutet, wenn ich irgendwo in einem Unterordner noch eine Datei habe, die exakt den gleichen Inhalt hat wie die Index-HTML, dann, ähm, haben die auch den gleichen Hash. 00:29:32.060 --> 00:29:34.460 Und somit habe ich die Datei auch nur einmal in der Repository. 00:29:34.460 --> 00:29:35.540 Mhm, ah ja. 00:29:35.540 --> 00:29:36.140 Ne? 00:29:36.140 --> 00:29:43.280 Also gerade so diese ganzen, gut, Git-Keep-Dateien haben sowieso keinen Inhalt, aber, äh, was, was könnte es denn noch geben? 00:29:43.280 --> 00:29:51.660 Also irgendwie, ich habe die HT-Access-Dateien vielleicht, die verzeichnete sperren, und da habe ich 20.000 davon in meinem Projekt, dann hätte ich die trotzdem aber in Git nur einmal. 00:29:51.660 --> 00:29:59.700 Und die belegen dann auch nur einmal den Speicher. Also klar, die Dateien existieren trotzdem mehrfach, ne? Aber ich habe sie nicht noch 20.000 Mal zusätzlich in diesem Git-Ordner drin. 00:29:59.700 --> 00:30:01.460 Praktisch. 00:30:01.460 --> 00:30:21.640 Ähm, genau, das hast du nicht. Ähm, der Clue ist natürlich, äh, du machst jetzt Änderungen in deinem Verzeichnis, dann ändert sich deine Datei, hat einen neuen Block, äh, einen neuen Hash-Dead-Block-Objekt, und, ähm, der steht dann als Ersatz in dem Tree-Objekt, ähm, aber alle anderen Referenzen verweisen halt immer an. 00:30:21.660 --> 00:30:29.820 und auf die gleichen Block-Objekte, ne? So hast du nicht mit jedem Commit, äh, ein linear wachsendes, ähm, ein linear wachsendes, ähm, ein linear wachsendes Speicherverbrauch, ne? 00:30:29.820 --> 00:30:30.120 Ja, ja. 00:30:30.120 --> 00:30:37.460 Du speicherst nur das neu, was sich wirklich geändert hat, ne? Ja, also hast du eigentlich immer einen Diff, ne? Also du speicherst nur das Diff, nur den Unterschied. 00:30:37.460 --> 00:30:42.980 Äh, äh, genau das tue ich nicht. Ähm, ich speicher wirklich die Block-Objekte, ne? 00:30:42.980 --> 00:30:43.180 Okay. 00:30:43.180 --> 00:30:51.640 Du nimmst den Dateienhalt, hashst den, speicherst das Ding ab und referenziert das in ein Tree-Objekt. Und dieses Tree-Objekt, das ist quasi einfach Text, 00:30:51.660 --> 00:30:58.080 kannst du dir vorstellen, wie wenn du LSA machst, so eine Art von Liste. Äh, äh, dieses Tree-Objekt wird quasi auch wieder gehashed, 00:30:58.080 --> 00:31:04.320 und somit habe ich auch hier wieder mein eindeutig referenzierbares Objekt, ne? 00:31:04.320 --> 00:31:10.740 Und der Clou ist dann halt, wenn ich jetzt meine Datei ändere, nur ein Zeichen, habe ich ja gerade schon gesagt, ändert sich ja der komplette 00:31:10.740 --> 00:31:18.180 Hash, der ja dann in dem Tree-Objekt aktualisiert wird, welches wieder gehashed wird, und somit ändert sich auch dieser Hash komplett, ne? 00:31:18.180 --> 00:31:24.320 Aber so bist du halt, ja, auf der sicheren Seite, dass du halt nichts überschreibst, wenn du die Kollision nicht triffst. 00:31:25.120 --> 00:31:32.620 Ja, würde mich mal interessieren, ob das schon, ob das bekannt ist, ob das irgendwo in einem Git-Projekt schon mal passiert ist. 00:31:32.620 --> 00:31:36.740 Wäre, glaube ich, ein schwer zu findender Fehler wahrscheinlich. 00:31:36.740 --> 00:31:40.620 Ja, am besten noch so ein Git-Körnel, äh, ein Linux-Körnel oder sowas. 00:31:40.620 --> 00:31:41.240 Auch, ja. 00:31:41.240 --> 00:31:44.680 Hat 30 Jahre keiner gemerkt. 00:31:48.400 --> 00:31:55.180 Ja, letzter Objekt, lass mich doch kurz auf den letzten Objekt-Typen kommen, dann sind wir mit dem Thema Hashing eigentlich durch. 00:31:55.180 --> 00:31:58.680 Das ist wirklich das Objekt, was jetzt jeder kennt, und zwar ist das das Commit-Objekt. 00:31:58.680 --> 00:32:02.220 Das Commit-Objekt zum Beispiel verweist dann auf ein Tree-Objekt. 00:32:02.220 --> 00:32:11.240 Und so weiß ich, hey, bei dem Commit XY war der Dateistand folgender, weil ich habe das Tree-Objekt, was eindeutig verwiesen ist. 00:32:11.240 --> 00:32:13.980 In dem Tree-Objekt habe ich mein Blob-Objekt, was eindeutig verwiesen ist. 00:32:14.760 --> 00:32:20.940 In dem Commit-Objekt habe ich dann noch andere Sachen, wie zum Beispiel den Autor des Commits, der dann da mit Name und Mail-Adresse drin steht. 00:32:20.940 --> 00:32:26.260 Und dem Timestamp, wann der Commit gemacht worden ist. 00:32:26.260 --> 00:32:28.600 Ich habe aber auch einen Committer da drin stehen. 00:32:28.600 --> 00:32:31.840 Ja, also in den meisten Fällen steht da zweimal Michael drin. 00:32:31.840 --> 00:32:32.700 Okay. 00:32:32.700 --> 00:32:39.140 Und ich habe den Eltern-Commit drin stehen, ja, der vor dem Commit quasi liegt. 00:32:39.600 --> 00:32:44.860 Und dann natürlich unsere schöne Commit-Message, die sehr aussagekräftig ist. 00:32:44.860 --> 00:32:45.560 Hoffentlich. 00:32:45.560 --> 00:32:49.180 Ja, das Ding wird dann halt quasi auch wieder gehasht. 00:32:49.180 --> 00:32:53.860 Und ja, das ist quasi das, was wir als Commit-Hashter sehen. 00:32:53.860 --> 00:32:57.720 Das ist wirklich der gehasht-Inhalt dieses GIP-Commit-Objekts. 00:32:57.720 --> 00:33:03.440 Wer da mal Bock hat, mal reinzuschauen, ihr könnt einfach in eurer Git-Repository reingehen. 00:33:03.440 --> 00:33:11.520 Mit dem Befehl git cat-file und dem Parameter pay-for-print und dann einfach mal ein Commit-Hash angeben. 00:33:11.520 --> 00:33:14.000 Dann seht ihr den Inhalt des Commit-Objekts. 00:33:14.000 --> 00:33:15.900 Und da könnt ihr euch dann einfach durchhangeln. 00:33:15.900 --> 00:33:17.800 Dann nehmt ihr einfach mal, ihr werdet dann einen Tree sehen. 00:33:17.800 --> 00:33:19.920 Dann nehmt ihr einfach mal den Hash von dem Tree-Objekt. 00:33:19.920 --> 00:33:22.460 Führt den gleichen Befehl aus mit dem Hash vom Tree-Objekt. 00:33:22.460 --> 00:33:24.580 Dann seht ihr mal den Inhalt von so einem Tree-Objekt. 00:33:24.840 --> 00:33:33.540 Und so kann man sich bis in die kleinste Spitze von euren Dateibaum hangeln und da mal so reinschauen. 00:33:33.540 --> 00:33:38.480 Und ja, was ich halt interessant fand, da sind einfach Textdateien. 00:33:38.480 --> 00:33:42.820 Die sind jetzt komprimiert, damit sie halt nicht so viel Platz verschlucken. 00:33:42.820 --> 00:33:47.660 Auch wenn man da reinguckt, das ist echt dann irgendwie gar nicht mehr so komplex. 00:33:47.660 --> 00:33:54.000 Wenn man sieht, was für eine Macht-Git mit dieser simplen Struktur irgendwie dann schafft. 00:33:54.000 --> 00:33:56.240 Wer sich das ausgedacht hat, ein Genie. 00:33:56.240 --> 00:33:58.940 Ja, ich bin immer wieder fasziniert, ja. 00:33:58.940 --> 00:34:00.320 Ja, Linus, oder? 00:34:00.320 --> 00:34:01.920 Ja. 00:34:01.920 --> 00:34:04.120 Oder hat sich das, glaube ich, ausgedacht? 00:34:04.120 --> 00:34:05.200 Linus Pauls, ja. 00:34:05.200 --> 00:34:06.000 Tatsächlich, ja. 00:34:06.000 --> 00:34:06.520 Ja. 00:34:06.520 --> 00:34:12.780 Okay, was kommt denn als nächstes? Hast du noch was? 00:34:12.780 --> 00:34:13.800 Ich habe. 00:34:13.800 --> 00:34:16.660 Ich weiß nicht, wie wir jetzt genau vorgehen. 00:34:16.660 --> 00:34:20.980 Ja, genau, wir haben ja irgendwann noch so einen Fragenblock, sage ich mal. 00:34:20.980 --> 00:34:23.040 Aber wir wollten ja erstmal so ein bisschen die Konzepte machen. 00:34:23.160 --> 00:34:24.440 Genau. 00:34:24.440 --> 00:34:28.720 Also ich hätte jetzt noch zwei Konzepte, die jetzt aber, glaube ich, relativ schnell durchgehen. 00:34:28.720 --> 00:34:31.140 Da würde ich jetzt noch weitermachen. 00:34:31.140 --> 00:34:31.840 Ja, ja, klar. 00:34:31.840 --> 00:34:34.520 Wir müssen gar nicht viel moderieren. Sehr gut. 00:34:34.520 --> 00:34:38.820 Ich sage mal, die Fragen haben wir uns im Vorhinein schon mal angeguckt, die so existieren. 00:34:39.000 --> 00:34:43.880 Und ich habe schon irgendwie versucht, die überall so ein bisschen in meinen Notizen einzubauen. 00:34:43.880 --> 00:34:47.000 Kommen wir dann hoffentlich auch dran vorbei. 00:34:47.000 --> 00:34:48.640 Sehr gut. 00:34:50.360 --> 00:34:54.120 Ja, nächstes Konzept, was ich als wichtig empfinde. 00:34:54.760 --> 00:34:56.120 Das ist der sogenannte DAG. 00:34:56.120 --> 00:34:56.940 D-A-G. 00:34:56.940 --> 00:34:59.520 Okay, hast du noch nie gehört? 00:34:59.520 --> 00:35:01.200 Nee, habe ich noch nie gehört. 00:35:01.200 --> 00:35:04.700 Also das Akronym war mir nie bewusst. 00:35:04.700 --> 00:35:08.820 Was das ausgeschrieben bedeutet, ist Directed Acyclic Graph. 00:35:09.260 --> 00:35:10.260 Auch das habe ich nie gehört. 00:35:10.260 --> 00:35:13.720 Ein gerichteter, a-züglicher Graph. 00:35:13.720 --> 00:35:15.420 Das ist ein Graph. 00:35:15.420 --> 00:35:18.080 Ihr kennt nur Graph Zahl, aber das ist es nicht. 00:35:18.080 --> 00:35:22.760 Nein, ein Graph im Sinne von verknüpften Knoten. 00:35:23.760 --> 00:35:27.040 Also eine Tree-Struktur ist euch sicherlich bekannt. 00:35:27.040 --> 00:35:33.140 Ein Baum und ein Graph hat den Unterschied, dass es auch wieder zusammenwachsen können. 00:35:33.140 --> 00:35:35.280 Also ich habe quasi so ein Netz. 00:35:35.280 --> 00:35:41.560 Und das ist quasi die Art und Weise, wie Git quasi die Commits organisiert. 00:35:41.560 --> 00:35:46.480 Jeder Commit zeigt zum Beispiel zu seinem Parent Commit. 00:35:46.480 --> 00:35:52.680 Und so baut sich dann halt nachher dieser Graph auf. 00:35:53.220 --> 00:35:56.380 Ich habe mehrere Commits, die auf dasselbe Eltern-Elemente zeigen können. 00:35:56.380 --> 00:35:58.860 Das ist, wenn ich zum Beispiel eine Branch anfange. 00:35:58.860 --> 00:36:01.200 Ja, weil ich den ersten Commit in der Branch mache. 00:36:01.200 --> 00:36:05.820 Da habe ich dem originalen Zweig einen Commit habe und eine Branch einmache. 00:36:05.820 --> 00:36:08.560 Da habe ich zwei Commits, die auf dasselbe Eltern-Elemente zeigen. 00:36:08.560 --> 00:36:09.120 Ah, okay. 00:36:09.120 --> 00:36:12.340 Und so weiß ich dann, wann das abgezweigt ist von dem Main-Branch zum Beispiel. 00:36:12.340 --> 00:36:13.140 Ja, genau. 00:36:13.140 --> 00:36:15.360 Du weißt erst mal, wann das abgezweigt worden ist. 00:36:15.360 --> 00:36:17.760 Und wenn wir uns noch mal an das Hashing zurückerinnern, 00:36:17.760 --> 00:36:20.860 in dem Commit-Objekt steht ja auch der Parent-Commit drin. 00:36:22.020 --> 00:36:24.060 Das heißt, wenn ich da einen anderen Hash eintrage, 00:36:24.060 --> 00:36:28.160 dann ist auch der Commit-Hash von meinem Commit auch plötzlich wieder ein ganz anderer. 00:36:30.220 --> 00:36:35.580 Und ja, ich habe auch tatsächlich die Möglichkeit, dass ein Commit auf mehrere Parents verweisen kann. 00:36:35.580 --> 00:36:39.180 Und zwar ist das die Situation, wenn ich einen Merch-Commit mache. 00:36:39.180 --> 00:36:42.460 Dann habe ich zwei Eltern-Elemente, weil ich zwei Branches zusammengeführt habe. 00:36:42.460 --> 00:36:46.000 Er verweist dann nachher wieder nur noch auf ein Tree-Objekt, 00:36:46.000 --> 00:36:49.160 weil da hat er dann den Verzeichnisbaum zusammengelegt. 00:36:50.040 --> 00:36:51.460 Aber ich habe zwei Eltern-Commit. 00:36:51.460 --> 00:36:53.960 Interessant. 00:36:53.960 --> 00:36:57.840 Also das habe ich mir echt noch nie so, nicht mal versucht vor Augen zu führen. 00:36:57.840 --> 00:37:03.080 Man nutzt es einfach irgendwie und sieht es so und irgendwie macht man sich gar keine Gedanken, wie das funktioniert. 00:37:03.080 --> 00:37:04.980 Aber ich finde es echt interessant, das mal so zu erfahren. 00:37:04.980 --> 00:37:08.900 Ich glaube, ich muss die Folge hinterher noch mal anhören, um es richtig zu verstehen. 00:37:08.900 --> 00:37:13.700 Und dann mal deine Commits angucken. 00:37:13.700 --> 00:37:14.980 Genau. 00:37:14.980 --> 00:37:19.040 Ja, genau, quasi noch mal mitmachen. 00:37:19.040 --> 00:37:24.120 Also währenddessen in den Git-Repository reinschauen, während dem Hören und dann das noch mal nachvollziehen. 00:37:24.120 --> 00:37:25.860 Das kann ich jetzt natürlich nicht nebenher machen. 00:37:25.860 --> 00:37:28.000 Ich habe es eben schon versucht, aber... 00:37:28.000 --> 00:37:29.420 Ich auch, aber ich bin auch gescheitert. 00:37:29.420 --> 00:37:30.860 Sonst kann ich nicht mehr zuhören. 00:37:30.860 --> 00:37:33.300 Genau, aber das mache ich im Anschluss vielleicht echt noch mal. 00:37:33.300 --> 00:37:36.860 Wenn wir die Folge veröffentlicht haben, höre ich es mir noch mal an und versuche es noch mal nachzuvollziehen. 00:37:37.040 --> 00:37:38.400 Also es ist auf jeden Fall... 00:37:38.400 --> 00:37:40.520 Ich glaube, man muss es dann auch mal anfühlen. 00:37:40.520 --> 00:37:47.280 Wichtig ist hier einfach, oder was ich als wichtig empfinde, ist halt einfach sich bewusst zu sein, 00:37:47.280 --> 00:37:49.720 wenn ich eine Datei verändere, dann kriegt die einen neuen Hash. 00:37:49.720 --> 00:37:53.840 Ja, der neue Hash muss in den Tree-Objekt stehen, weil sonst ist die Datei nicht verwiesen. 00:37:53.840 --> 00:37:57.120 Ja, damit ändert sich definitiv der Hash des Tree-Objekts. 00:37:57.120 --> 00:38:01.000 Und da der Hash wiederum im Commit steht, ändert sich auch der Hash des Commits. 00:38:01.000 --> 00:38:07.020 Und so entstehen halt Situationen, wie ich plötzlich andere Commits habe, wenn ich ein Rebase gemacht habe. 00:38:07.040 --> 00:38:16.160 oder ich Commits meinen Kollegen vielleicht auch mal unterm Hintern wegziehe, 00:38:16.160 --> 00:38:22.500 weil der plötzlich auf einem ganz anderen Hash unterwegs ist, als ich, der irgendwie gedacht hat, 00:38:22.500 --> 00:38:24.200 hey, ich rebase den Branch mal schnell. 00:38:25.540 --> 00:38:31.560 Und der Konstantin hat das aber nicht mitgekriegt und guckt noch schön auf die alten Hashes drauf und verweist da drauf. 00:38:31.560 --> 00:38:34.760 Und ja, da komme ich dann halt nachher in eine ganz blöde Situation. 00:38:35.280 --> 00:38:37.460 Ich glaube, über Rebase sprechen wir nachher auch nochmal, ne? 00:38:37.460 --> 00:38:38.280 Ja, definitiv. 00:38:38.280 --> 00:38:39.560 Da haben wir schon aufgeschrieben. 00:38:39.560 --> 00:38:40.900 Ja, genau. 00:38:40.900 --> 00:38:44.520 Ja, Hashes sind schön und gut, kann sich nur keine Sau merken. 00:38:45.400 --> 00:38:47.260 Ja, deswegen letztes Konzept, was ich so habe. 00:38:47.260 --> 00:38:49.580 Ich habe es jetzt hier als Referenzen stehen. 00:38:49.580 --> 00:38:52.840 Ich glaube, mit geht heißt es auch wirklich Refs. 00:38:52.840 --> 00:38:58.340 Ich stelle mir das einfach immer vor als Etiketten, die an Commits dranhängen, 00:38:58.340 --> 00:38:59.920 damit ich mich an die Commits erinnere. 00:38:59.920 --> 00:39:02.660 Und das sind letztendlich die Namen unserer Branches zum Beispiel. 00:39:02.660 --> 00:39:04.780 Ja, weil ich Master habe. 00:39:04.920 --> 00:39:11.960 Dann ist es einfach nur ein Label, was auf Commit A, B, 2, 5 verweist. 00:39:11.960 --> 00:39:17.100 Und wenn ich jetzt hingehe und einen neuen Commit mache, 00:39:17.100 --> 00:39:21.360 dann gibt es nichts weiter, wie die Commit zu erzeugen mit dem neuen Hash. 00:39:21.360 --> 00:39:24.600 Und dann nimmt er das Label und klebt das an den neuen Commit dran. 00:39:24.600 --> 00:39:29.960 Das heißt auch, wenn ich jetzt hingehe und auf irgendeine Branch bin 00:39:29.960 --> 00:39:31.860 und aus dem jetzt einen neuen Branch ableite, 00:39:31.860 --> 00:39:34.440 dann ist das letztendlich erstmal auch ein Etikett 00:39:34.440 --> 00:39:36.140 und die hängen alle an dem selben Commit dran, 00:39:36.140 --> 00:39:38.680 solange ich noch keine Commits in der Fall gemacht habe. 00:39:38.680 --> 00:39:44.160 In der Vorstellung hat man so einen Branch so als eigenes Ding. 00:39:44.160 --> 00:39:48.280 Und eigentlich ist es aber, klebt der Branch nur da und markiert. 00:39:48.280 --> 00:39:51.440 Hier, ich bin der Main-Branch und ich bin der Feature-Branch. 00:39:51.440 --> 00:39:52.760 Okay, interessant. 00:39:52.760 --> 00:39:55.060 Und ich finde, wenn du das jetzt weißt, 00:39:55.060 --> 00:39:58.260 dann gehst du vielleicht auch einfach mal hin und missbrauchst so einen Branch, 00:39:58.260 --> 00:40:01.480 um einfach dir irgendwo einen Label dran zu hängen, 00:40:01.480 --> 00:40:04.320 wo du sagst, hey, das Ding möchte ich mir mal kurz merken. 00:40:04.440 --> 00:40:08.600 Falls ich hier jetzt was kaputt mache, dann kann ich da immer noch zurückgeben. 00:40:08.600 --> 00:40:09.260 Ja. 00:40:09.260 --> 00:40:12.300 Also wie ein Tag dann, oder? 00:40:12.300 --> 00:40:13.280 Das ist so mein Escape-Hatch. 00:40:13.280 --> 00:40:14.900 Okay, aber wie ein Tag, oder? 00:40:14.900 --> 00:40:16.320 Ein Tag ist auch nichts anderes. 00:40:16.320 --> 00:40:19.100 Es gibt aber die, ich glaube, sie heißen einen Annotated Tag, 00:40:19.100 --> 00:40:22.780 wo du dann auch wieder einen Hash hast, um das zu signieren. 00:40:23.900 --> 00:40:28.220 Habe ich, ehrlich gesagt, noch nie benutzt oder wenn unbewusst. 00:40:28.220 --> 00:40:31.000 Aber ja, auch ein Tag ist quasi ein Label. 00:40:31.000 --> 00:40:31.660 Genau. 00:40:32.960 --> 00:40:36.340 Aber auch der Branch eines Remotes zum Beispiel ist auch nur ein Label. 00:40:36.340 --> 00:40:39.520 Wenn du zum Beispiel hingehst und sagst, gib Fetch, 00:40:39.520 --> 00:40:44.180 dann geht er ja hin und zieht sich alle Objekte von deinem Remote in dein Repository rein. 00:40:44.180 --> 00:40:48.820 Und dann siehst du zum Beispiel sowas wie origin slash master. 00:40:48.820 --> 00:40:54.040 Und das ist auch quasi einfach nur ein Etikett, was auf den Commit verweist, 00:40:54.040 --> 00:40:58.300 wo der Master, der das Remote gesagt hat, hey, da ist gerade mein Master-Branch. 00:40:59.440 --> 00:41:02.420 Und da kannst du quasi auch einfach hingehen und sagen, 00:41:02.420 --> 00:41:05.580 okay, jetzt gehe ich hin und möchte meinen Master-Etikett 00:41:05.580 --> 00:41:07.680 an den selben Commit dran kleben. 00:41:07.680 --> 00:41:11.840 Und das ist das, was man letztendlich mit dem Befehl git reset macht. 00:41:11.840 --> 00:41:14.700 Das hört sich irgendwie so an, als würde ich irgendwas kaputt machen 00:41:14.700 --> 00:41:15.660 und zurücksetzen. 00:41:15.660 --> 00:41:21.380 Aber git reset ist quasi der Befehl, der das Label, auf dem du gerade bist, 00:41:21.380 --> 00:41:23.220 irgendwo anders dran kleben kann. 00:41:23.220 --> 00:41:23.900 Ah, okay. 00:41:23.900 --> 00:41:28.880 Ja, jetzt ist gleich schon Licht aufgegangen jetzt so von der Vorstellung her. 00:41:29.200 --> 00:41:30.460 War das immer so ein Buch mit sieben Siegeln? 00:41:30.460 --> 00:41:32.620 Jetzt ist mir das schon klarer mit dem Reset. 00:41:32.620 --> 00:41:34.660 Genau. 00:41:34.660 --> 00:41:36.940 Git reset hat noch so drei Parameter. 00:41:36.940 --> 00:41:41.520 Du kannst ja sagen, git reset hard, soft oder mixt. 00:41:41.520 --> 00:41:43.340 Mixt ist der Standardfall. 00:41:43.340 --> 00:41:47.640 Wenn du hart sagst, dann schmeißt du halt alles weg und setzt das Ding zurück. 00:41:48.280 --> 00:41:50.980 Das ist was, was ich ganz gerne nutze, wenn ich sage, hey, ich weiß, 00:41:50.980 --> 00:41:54.720 das, was mein Master hier lokal hat, das ist komplett veraltet. 00:41:54.720 --> 00:41:56.760 Und ich habe auch sicherlich da nichts drin gemacht. 00:41:56.760 --> 00:41:59.580 Da gehe ich eigentlich immer hin und mache dann ein git reset hard 00:41:59.580 --> 00:42:00.880 dann auf den Region Master. 00:42:03.540 --> 00:42:07.880 wenn man kein Merch, äh, kein Problem machen kann. 00:42:07.880 --> 00:42:08.280 Ja. 00:42:08.280 --> 00:42:14.820 Und, ähm, manchmal brauchst du aber auch, ähm, nochmal den Stand, ähm, von deinen Änderungen. 00:42:14.820 --> 00:42:17.900 Du willst ihn nicht wegwerfen, sondern willst einfach nur mal das Label in Schritte zurück machen. 00:42:18.420 --> 00:42:21.180 Dann würdest du sagen, irgendwie git reset hat tilde eins zum Beispiel, 00:42:21.180 --> 00:42:23.560 weil du sagst vom hat einen Commit zurück. 00:42:23.560 --> 00:42:26.160 Und, ähm, tilde eins. 00:42:26.160 --> 00:42:31.040 Ich möchte aber die ganzen geänderten Dateien, ähm, ich möchte die nicht verwerfen, 00:42:31.040 --> 00:42:33.720 sondern ich möchte die vielleicht nochmal einzeln committen oder so. 00:42:33.720 --> 00:42:36.480 Weil ich festgestellt habe, hey, was ich gerade committet habe, 00:42:36.480 --> 00:42:38.760 wollte ich nicht als einen großen Commit machen. 00:42:38.760 --> 00:42:42.960 Ah, und da kommen wir nämlich dann schon zu meiner großen Problematik 00:42:42.960 --> 00:42:44.300 mit dem Squashen, glaube ich auch so, ne? 00:42:44.300 --> 00:42:47.760 Es ist nochmal ein bisschen was anderes, aber eben genau dieses, 00:42:47.760 --> 00:42:50.680 äh, ich will da nochmal zurück und, und ich hab da was falsch gemacht 00:42:50.680 --> 00:42:52.860 und ich kann das eben, ich kann das wieder richten. 00:42:52.860 --> 00:42:56.620 Weil das war bei mir, das hat bei mir nämlich eine Zeit lang gedauert, 00:42:56.620 --> 00:42:59.820 äh, dass ich verstanden habe, okay, wenn ich was kaputt gemacht habe 00:42:59.820 --> 00:43:02.520 und falsch, äh, committet habe, das ist dann nicht einfach, 00:43:02.520 --> 00:43:04.920 das ist dann in der Datenbank und das kann ich nie wieder ändern, ja, 00:43:04.920 --> 00:43:07.160 sondern, sondern ich kann da halt wirklich wieder zurück taggen 00:43:07.160 --> 00:43:09.480 und das verwerfen und wenn ich das dann wieder einchecke, 00:43:09.480 --> 00:43:12.380 dann ist es auch tatsächlich in GitHub zum Beispiel dann geändert. 00:43:12.380 --> 00:43:15.960 Oder ich hatte mal den Fall, dass ich, äh, nachträglich, ähm, 00:43:15.960 --> 00:43:18.440 den, den Namen und die E-Mail-Adresse, die da eingestanden, äh, 00:43:18.440 --> 00:43:21.460 da war halt die falsche eingestellt in dem, in dem GUI, das ich genutzt habe 00:43:21.460 --> 00:43:25.260 und ich wollte nicht, dass die private E-Mail-Adresse da, äh, in dem Repository getaggt ist 00:43:25.260 --> 00:43:28.020 und selbst das ließ sich dann alles rückwirkend nochmal überschreiben 00:43:28.020 --> 00:43:31.720 und das war, äh, ja, hat, ja, hat eben gedauert zu wissen, dass das so funktioniert 00:43:31.720 --> 00:43:33.540 und dass das nicht unwiederbringlich ist, was ich da war. 00:43:33.540 --> 00:43:36.340 Ja, genau, letztendlich lässt sich alles überschreiben, ne? 00:43:36.340 --> 00:43:39.880 Also, du kannst ja auch, wenn du ein Commit absetzt, kannst du mit dem, ähm, 00:43:39.880 --> 00:43:43.520 ähm, ähm, Parameter, minus minus author, also Autor, ähnlicher Autor, 00:43:43.520 --> 00:43:47.260 kannst du angeben, wer der, der Commit, ähm, Autor ist, ne? 00:43:47.520 --> 00:43:52.200 Das, ähm, nutze ich hin und wieder mal, wenn, keine Ahnung, der Chef reinkommt 00:43:52.200 --> 00:43:55.440 und sagt, ändere mal hier den Text, dann gehe ich hin und sage, 00:43:55.440 --> 00:43:57.820 ja, gut, das habe nicht ich mir ausgedacht, dass der Text geändert wird. 00:43:57.820 --> 00:43:58.140 Ah, okay. 00:43:58.140 --> 00:44:01.080 Und dann kann ich auch da mal jemand anders da dran schreiben. 00:44:01.080 --> 00:44:01.660 Ah, ja. 00:44:01.660 --> 00:44:03.560 Ich stehe trotzdem als Committer drin, ne? 00:44:03.560 --> 00:44:05.840 Eben bei den Hash-Geschichten habe ich ja gesagt, 00:44:05.840 --> 00:44:08.180 im Committer-Objekt steht Autor und Committer drin. 00:44:08.180 --> 00:44:11.380 Ich bin trotzdem der Committer, also man sieht, dass ich das Committed habe, 00:44:11.380 --> 00:44:14.300 aber ich habe die Möglichkeit zu sagen, ja, aber geschrieben hat es ein anderer. 00:44:14.300 --> 00:44:15.680 Ja, cool. 00:44:17.520 --> 00:44:20.220 Es trifft mir aber total ab, wir waren beim Thema Referenzen. 00:44:20.220 --> 00:44:22.780 Ich habe jetzt gerade auch schon nach dem Head gesprochen. 00:44:22.780 --> 00:44:25.660 Head ist so ein Spezialfall und zwar repräsentiert Head quasi, 00:44:25.660 --> 00:44:27.860 wo ich gerade bin auf meiner Platte. 00:44:27.860 --> 00:44:30.240 Also wenn ich jetzt einen Branch auschecke, 00:44:30.240 --> 00:44:32.440 da zeigt Head auf dem Branch-Namen drauf. 00:44:32.440 --> 00:44:35.760 Und Head hat aber die Besonderheit, 00:44:35.760 --> 00:44:37.100 der muss nicht immer auf dem Branch zeigen, 00:44:37.100 --> 00:44:38.680 sondern der kann auch auf dem Commit zeigen. 00:44:38.680 --> 00:44:41.400 Ich kann ja auch sagen, get check out und durch den Commit-Hash, 00:44:41.400 --> 00:44:45.020 wo dann Gitte mal sagt, Achtung, du bist im Detached-Hash-Status. 00:44:45.020 --> 00:44:46.000 Ach, das ist das dann, okay. 00:44:46.520 --> 00:44:49.000 Das ist dann, wenn mein Head gerade auf dem Commit zeigt. 00:44:49.000 --> 00:44:52.100 Es wird deshalb gewarnt, weil wenn ich jetzt einen neuen Commit mache, 00:44:52.100 --> 00:44:55.700 dann wird der zwar an diesem Commit, auf dem ich gerade bin, drangehangen, 00:44:55.700 --> 00:44:58.380 also der Commit, auf dem jetzt gerade der Head ist, 00:44:58.380 --> 00:45:00.940 wird dann als Eltern-Element in dem neuen Commit eingetragen. 00:45:01.940 --> 00:45:03.500 Aber es hängt kein Label dran. 00:45:03.500 --> 00:45:06.680 Und wenn ich jetzt wieder sage, get check out Master zum Beispiel, 00:45:06.680 --> 00:45:11.100 dann habe ich mir den Hash hoffentlich irgendwo hingeschrieben. 00:45:11.100 --> 00:45:14.680 Weil den musst du nicht schnell wiederfinden. 00:45:14.680 --> 00:45:17.400 Gibt es aber auch Tricks, kommen wir vielleicht gleich nochmal zu. 00:45:17.400 --> 00:45:25.720 Ja, Master ist wie jeder andere Branch-Name auch einfach nur ein Branch, ein Label. 00:45:27.720 --> 00:45:35.340 Wir hatten die Frage über Twitter, was ist mit dem Namen Master, Main, muss er jetzt Main heißen, darf er Main heißen? 00:45:35.400 --> 00:45:39.480 Politisch haben wir gesagt, gehen wir da jetzt gar nicht drauf ein, bevor wir uns die Finger verbrennen. 00:45:39.480 --> 00:45:42.520 Aber was hat das denn für Implikationen? 00:45:42.520 --> 00:45:45.100 Muss ich da irgendwas berücksichtigen, wenn ich es dann doch umbenennen will? 00:45:45.740 --> 00:45:49.180 Erstmal ist es nur ein Label, das heißt machen, warum nicht? Kannst du machen. 00:45:49.180 --> 00:45:53.420 Du kannst dann bei GitHub und Co. einstellen, was so der Default-Branch ist, 00:45:53.420 --> 00:45:56.920 dass wenn das dann jemand klont oder auf dein Repository geht, 00:45:56.920 --> 00:45:59.300 das dann auch direkt dann auf den neuen Branch-Namen ist. 00:45:59.300 --> 00:46:04.620 Wo man halt mal drüber nachdenken muss, ist, was man sonst noch so für Tools einsetzt. 00:46:04.620 --> 00:46:08.800 Und ob in diesen Tools vielleicht irgendwo Master hardgecodet ist, 00:46:08.920 --> 00:46:13.900 weil das ja bislang immer schon der Tag-Name war für den Haupt-Branch. 00:46:13.900 --> 00:46:14.160 Ja. 00:46:14.160 --> 00:46:19.780 Also ich habe bei mir auf der Platte schon das ein oder andere Shell-Script oder Git-Alias, 00:46:19.780 --> 00:46:25.720 wo ich wirklich dann, keine Ahnung, lösche Branches, die schon gemerged sind. 00:46:26.720 --> 00:46:30.000 Wenn du aber sagst, Git-Branch ist minus minus Merge, 00:46:30.000 --> 00:46:32.100 also dann listet der ja auf, was alles gemerged ist, 00:46:32.100 --> 00:46:36.360 dann listet der auch den Master auf, weil der keine losen Comments mehr hat, 00:46:36.360 --> 00:46:38.280 die noch nicht im Master sind quasi. 00:46:38.280 --> 00:46:41.600 Und da wissen wir natürlich nicht, dass der gelöscht wird. 00:46:41.600 --> 00:46:44.620 Und ja, da habe ich dann halt... 00:46:44.620 --> 00:46:46.440 Also mir ist bewusst, dass ich einige Spezialfälle habe, 00:46:46.440 --> 00:46:48.060 die auf dieses Master-Tag zielen. 00:46:48.060 --> 00:46:52.080 Bevor man halt diese Umstellung macht, muss man halt sicher gehen, 00:46:52.080 --> 00:46:55.040 dass man nicht irgendwelche Tools abkoppelt. 00:46:55.040 --> 00:47:01.400 Ja, bei GitHub zum Beispiel ist es jetzt auch mittlerweile Standard, 00:47:01.400 --> 00:47:03.500 dass sie den Branch Main nennen. 00:47:03.500 --> 00:47:08.240 Genau, also nochmal zusammengefasst. 00:47:08.240 --> 00:47:11.000 Also es steht dem eigentlich überhaupt nichts im Wege, 00:47:11.000 --> 00:47:12.720 weil es eigentlich nur ein Name ist, 00:47:12.720 --> 00:47:17.740 außer man hat irgendwas Externes, was eben darauf unter Umständen zugreift. 00:47:17.740 --> 00:47:22.280 Also keine Ahnung, wenn ich jetzt irgendwie automatisch irgendwas mit Branches mache 00:47:22.280 --> 00:47:26.060 oder so und mit Jenkins oder keine Ahnung, was für ein Tool irgendwie dranhängt 00:47:26.060 --> 00:47:28.320 und das einen bestimmten Branch auscheckt und damit was tut, 00:47:28.320 --> 00:47:31.740 dann sollte man natürlich da schauen, dass das da dann auch überall glatt gezogen wird. 00:47:31.740 --> 00:47:34.240 Aber ich denke, das wird man dann sofort merken, wenn der Bild fehlschlägt. 00:47:35.360 --> 00:47:36.580 Oder keiner mehr passiert. 00:47:36.580 --> 00:47:40.660 Oder dann ein Commit, den du in den Master gemacht hast, zu keinem neuen Release führt, 00:47:40.660 --> 00:47:45.620 weil die Pipeline immer guckt, bin ich im Master-Branch, wenn ich einen Release machen will. 00:47:45.620 --> 00:47:48.020 Aber nein, ich bin im Main-Branch, also muss ich nichts tun. 00:47:48.020 --> 00:47:48.680 Genau. 00:47:49.820 --> 00:47:54.620 Okay, nee, aber das klingt ja schon mal echt gut, weil das heißt, so Git-seitig gibt's überhaupt gar kein Problem. 00:47:54.620 --> 00:47:58.340 Eigentlich ist es nur mehr so das Drumherum, was man sich eventuell drumherum gestrickt hat. 00:47:58.340 --> 00:47:59.160 Ja. 00:47:59.160 --> 00:48:00.000 Ja, cool. 00:48:00.000 --> 00:48:00.400 Genau. 00:48:00.400 --> 00:48:03.000 Das heißt, kann man einfach umstellen, wenn man möchte. 00:48:03.000 --> 00:48:07.980 Was ist denn der Befehl dafür, dass wir das kurz genannt haben, 00:48:07.980 --> 00:48:09.560 falls jetzt jemand sagt, oh ja, muss ich gleich machen? 00:48:09.560 --> 00:48:10.920 Ähm. 00:48:10.920 --> 00:48:14.720 Sorry, aber jetzt überfall ich dich hier. 00:48:14.720 --> 00:48:19.300 Nee, aber es gibt keinen Befehl für, hey, ich stelle vom Master auf Main um. 00:48:19.300 --> 00:48:26.060 Du checkst den Master-Branch aus und leitest davon einen neuen Branch ab, den du Main nennst. 00:48:26.060 --> 00:48:29.540 Und dann ist das ja erstmal ein zweites Label, was am selben Commit klebt. 00:48:29.540 --> 00:48:31.540 Achso, und dann löscht du einfach den Master-Branch. 00:48:31.540 --> 00:48:31.800 Ah, okay. 00:48:31.800 --> 00:48:36.420 Ich dachte, da gibt's vielleicht irgendwie so ein Renaming oder so irgendwie Rename-Command, 00:48:36.420 --> 00:48:37.620 das das dann automatisch macht. 00:48:37.620 --> 00:48:41.700 Aber wenn das nicht an Bord ist, könnte ja in der Tat sein. 00:48:41.700 --> 00:48:43.440 Das ist ein Git-Branch. 00:48:43.440 --> 00:48:44.580 Mal gucken. 00:48:44.720 --> 00:48:48.100 Minus-MV oder so, weiß ich jetzt gerade nicht. 00:48:48.100 --> 00:48:51.660 Ich hab ehrlich gesagt, das ist noch nicht sehr häufig, Branch ist unbenannt. 00:48:51.660 --> 00:48:55.180 Äh, Git-Branch-M und dann neuer Name. 00:48:55.180 --> 00:48:55.980 Ja, ja. 00:48:55.980 --> 00:48:57.500 Sehe ich jetzt gerade hier. 00:48:57.500 --> 00:48:57.960 Ich hab's vermutet. 00:48:57.960 --> 00:49:02.340 Gut, also sogar noch einfacher. 00:49:02.340 --> 00:49:06.820 Da hättest du noch so darauf gestoßen, hey, das hättest du auch in sechs Commands lösen können. 00:49:06.820 --> 00:49:08.600 Statt? 00:49:08.600 --> 00:49:13.560 Also etwas in Git zu machen, wo ich mir immer denke, ja, klar ist es immer cool, 00:49:14.000 --> 00:49:19.840 alle Argumente zu wissen und dann in zwei Commands irgendwo zu landen, anstatt in fünf. 00:49:19.840 --> 00:49:20.340 Okay. 00:49:20.340 --> 00:49:22.140 Na gut, aber sechs Commands sind ja auch schon viel. 00:49:22.140 --> 00:49:23.080 Was war denn dann vorher? 00:49:23.080 --> 00:49:24.720 Ein eigenes Shell-Skript, oder? 00:49:24.720 --> 00:49:29.220 Ähm, das war ja so ein Training-Ding. 00:49:29.220 --> 00:49:33.880 Da ging's darum, dass du drei Feature-Branches hast und du sollst die alle drei nacheinander 00:49:33.880 --> 00:49:36.120 ge-rebased in das Remote bewegen. 00:49:36.440 --> 00:49:40.400 Und er hat dann gesagt, ja, super, du hast es in zwölf Kommandos geschafft. 00:49:40.400 --> 00:49:42.480 Äh, das geht aber auch in sechs. 00:49:43.380 --> 00:49:50.520 Ich denke mal, ja, cool, die Herausforderung ist interessant, aber letztendlich das Wichtige 00:49:50.520 --> 00:49:57.240 ist einfach, dass ich zum Ziel komme, nichts kaputt mache und zum Schluss. 00:49:57.260 --> 00:50:00.840 Ja, solange der Weg nicht ewig dauert, genau, ist es, glaube ich, wichtig, dass man zum Ziel 00:50:00.840 --> 00:50:05.640 kommt und nicht, äh, wie kurz der Weg da ist, weil ich glaube, so ein langer Weg ist vielleicht 00:50:05.640 --> 00:50:08.460 auch okay, vielleicht auch dann für das eigene Hirn ein bisschen verständlicher. 00:50:08.460 --> 00:50:12.320 Man muss auch nicht alles auswendig kennen, jeden, wie du gerade schon gesagt hast, irgendwie 00:50:12.320 --> 00:50:14.120 jedes, äh, jeden Parameter. 00:50:16.200 --> 00:50:18.480 Wobei es nicht schlecht ist, wenn man jeden Parameter kennt, ne? 00:50:18.480 --> 00:50:22.560 Ja, ich, ich fürchte, bei Git musst du sehr viel kennen. 00:50:22.560 --> 00:50:23.080 Ja. 00:50:23.080 --> 00:50:30.740 Ja, äh, da auch nochmal meine, meine Empfehlung, äh, die Seite git-scm.com, also Git-Source-Control-Management 00:50:30.740 --> 00:50:36.180 heißt es, glaube ich, ausgesprochen, äh, das ist so die Hauptseite für Git, ähm, da gibt's 00:50:36.180 --> 00:50:39.920 einmal die Dokumentation, wenn ich auf Slash-Doc gehe und, äh, die haben auch ein Buch, 00:50:39.920 --> 00:50:45.940 aus Slash-Book, das gibt's sogar, manche Deutsch, für Leute, die sich vielleicht vor Englisch 00:50:45.940 --> 00:50:48.620 scheuen, äh, das ist auf jeden Fall sehr informativ. 00:50:48.620 --> 00:50:55.260 Und, äh, da kann ich auf jeden Fall empfehlen, mal reinzuschauen, wenn man sich fragt, ähm, 00:50:55.260 --> 00:50:59.500 wie war nochmal das richtige Argument oder halt das Git-Buch halt, wenn man generell nochmal 00:50:59.500 --> 00:51:01.320 das verstehen möchte, wie das alles funktioniert. 00:51:01.320 --> 00:51:03.320 Cool. 00:51:03.320 --> 00:51:08.120 Ja, da landet man auch automatisch schon drauf, wenn man, äh, Git-Sachen googelt, also finde 00:51:08.120 --> 00:51:10.220 ich, landet man relativ häufig da, ja. 00:51:10.220 --> 00:51:13.720 Ja, aber ich finde, das ist halt auch wirklich eine, eine gute Dokumentation. 00:51:13.720 --> 00:51:15.440 Also, da bin ich immer fündig geworden. 00:51:15.680 --> 00:51:21.420 äh, ich sag mal so, Man-Pages hab ich immer so ein bisschen Angst vor, weil, ja, das finde 00:51:21.420 --> 00:51:26.180 ich nie, was ich suche, ähm, oder es ist, es ist mir nicht so direkt eingängig. 00:51:26.180 --> 00:51:30.200 Ja, manchmal hat man ja so der Anspruch, hey, ich möchte drauf, so als Entwickler, als 00:51:30.200 --> 00:51:34.940 scrollt man eh nur durch und guckt sich die Exempels an, ähm, das finde ich geht bei Man-Pages 00:51:34.940 --> 00:51:40.700 immer schwierig, aber ich finde, die Git-Dokumentation sehr gelungen. 00:51:40.700 --> 00:51:45.440 Ja, ich möchte so Doku eigentlich auch nicht, also ich meine, gut, Man-Pages gibt's auch im Web, aber 00:51:45.440 --> 00:51:50.440 der klassische Befehl ist ja Man und dann, äh, den Befehl, zu dem man was wissen will und das 00:51:50.440 --> 00:51:54.420 auf der Kommandozeile zu lesen, das ist sehr mühselig. Also, da google ich lieber danach und lande 00:51:54.420 --> 00:51:57.440 genau auf dem Spezialartikel, der sich um meinen Befehl dreht. 00:51:57.440 --> 00:52:02.180 Also, da bist du direkt im Stack-Overflow, wo du die Kommandozeile einfach probieren kannst. 00:52:02.180 --> 00:52:05.240 Ja, richtig. Genau, das ist doch das Schönste. 00:52:05.240 --> 00:52:10.760 Das, äh, habt ihr übrigens in eurer Visual Studio Code-Folge verpasst, das, äh, die wichtige 00:52:10.760 --> 00:52:16.700 Extension, ähm, in der man einfach einen Suchbegriff eingeben kann und dann sucht er bei Stack-Overflow 00:52:16.700 --> 00:52:20.960 und pastet automatisch von der beantworteten Antwort den Code in deinen Visual-Folge. 00:52:20.960 --> 00:52:22.620 Echt? Weißt du, weißt du gerade, wie die heißt? 00:52:22.620 --> 00:52:23.340 Nee, leider nicht. 00:52:23.340 --> 00:52:25.160 Dann können wir so verlinken. Okay, finden wir raus. 00:52:26.640 --> 00:52:30.380 Aber das fand ich sehr bezeichnend. 00:52:30.380 --> 00:52:30.920 Oh ja. 00:52:30.920 --> 00:52:36.000 Es gibt ja tatsächlich, äh, Menschen, die so vorgehen. 00:52:36.000 --> 00:52:46.780 Ja, ähm, was ich immer gut finde, ist, ähm, wenn ich Dinge visualisieren kann, ähm, am liebsten 00:52:46.780 --> 00:52:53.980 im Kopf, äh, jetzt gerade so ein Graph, wo sind jetzt Commits, wo zweigt was ab oder so, ähm, 00:52:56.020 --> 00:53:01.760 und wenn nicht, dann auch gerne auf dem Bildschirm, ähm, das machen ja die, die Tools, die Guis, die man so 00:53:01.760 --> 00:53:10.940 verwenden kann, ähm, das ist ja auch schon ganz gut, ähm, wer sich so ein bisschen vor den Guis scheut, äh, kann das aber auch auf der Konsole erreichen. 00:53:11.420 --> 00:53:20.360 Und zwar kann ich, wenn ich, wenn ich git log sage, ähm, kann ich zum Beispiel mit Minus Minus Graf, kann ich mir quasi, ja, ja, den Eskiart Grafen anzeigen lassen, der Commits. 00:53:20.360 --> 00:53:26.100 Wenn ich das dann noch kombiniere mit Minus Minus One Line, damit ich nicht die kompletten Commit Messages immer sehe, 00:53:26.100 --> 00:53:33.840 sondern wirklich nur in einem Zeiler, das ist dann in einem Graph tatsächlich übersichtlicher, ähm, dann ist das schon sehr hilfreich. 00:53:33.840 --> 00:53:40.840 Und dann am besten noch mit dem Parameter Minus Minus All, dass ich nicht nur ab dem Commit, auf dem ich gerade bin, weiter nach unten alles sehe, 00:53:40.840 --> 00:53:54.840 sondern wirklich alle Zweige, die auch neben mir liegen oder vielleicht schon weiter vorne sind, äh, dann finde ich persönlich das immer sehr hilfreich, wenn ich da mal so gerade reingucke, wo bin ich gerade, was hat mein Kollege gepusht, ähm, sind da Commits drin, die ich 00:53:54.840 --> 00:54:10.180 zufällig auch schon habe, ähm, oder, ähm, gerne hätte, das finde ich immer sehr hilfreich. Ähm, da kommen wir auch vielleicht in die Show Notes, ich hab so ein Kind alias, der heißt bei mir einfach HIST wie HISTORY, äh, der ist noch mit einem anderen 00:54:10.180 --> 00:54:18.080 ähm, Format ein bisschen ausgestattet, vielleicht packt man den einfach an die Show Notes mit dabei. Ja, gerne. Ähm, dann ist es ein bisschen praktischer, wenn man sich nicht 00:54:18.080 --> 00:54:27.240 einen Wolf tippt, sondern, ich sag einfach bei mir immer, GIT HIST, das ist irgendwie der zweitäufigste Befehl nach GIT-Status, ähm, ja, finde ich zum Beispiel sehr hilfreich. 00:54:27.240 --> 00:54:29.700 Ja, gerade schon mal, ähm, 00:54:29.700 --> 00:54:34.700 drauf angesprochen, die Geschichte, die ich da mit dem, hey, das hättest du auch in sechs Commits schaffen können, 00:54:34.700 --> 00:54:39.520 hatte, ähm, es gibt, ähm, so zwei Lerntools, die ich ganz cool finde im Web, ähm, 00:54:39.520 --> 00:54:40.980 äh, das ist einmal 00:54:40.980 --> 00:54:45.500 learngitbranching.js.org, ähm, das ist quasi 00:54:45.500 --> 00:54:47.500 so ein Ding mit so Lernaufgaben, 00:54:47.500 --> 00:54:49.640 also da werden dir quasi Herausforderungen gestellt, 00:54:49.640 --> 00:54:51.420 das wird aber halt auch sehr schön visualisiert. 00:54:51.420 --> 00:54:53.560 Das ist kein echtes GIT, was da läuft, 00:54:53.560 --> 00:54:55.420 sondern die simulieren das so ein bisschen, 00:54:55.420 --> 00:54:57.640 also du musst jetzt zum Beispiel nichts adden 00:54:57.640 --> 00:54:59.240 und keinen Text schreiben, sondern du sagst einfach 00:54:59.240 --> 00:55:01.040 git commit, dann ist da ein neuer commit zum Beispiel, 00:55:01.040 --> 00:55:03.420 ähm, aber das ist ganz gut, wenn man 00:55:03.420 --> 00:55:05.460 sich einfach mal dann diesen Branch zeigen lassen 00:55:05.460 --> 00:55:07.480 kann, wenn ich ein Merch mache, was passiert, 00:55:07.580 --> 00:55:09.980 wenn ich Rebase mache, was passiert, ähm, 00:55:09.980 --> 00:55:13.560 das finde ich sehr, sehr schön gelöst. 00:55:13.560 --> 00:55:15.680 Das kommt mir bekannt vor, das habe ich schon mal gesehen, 00:55:15.680 --> 00:55:17.380 ich glaube, das ist vielleicht sogar in unserer 00:55:17.380 --> 00:55:19.660 Geilteile-Liste, äh, 00:55:19.660 --> 00:55:21.540 schon mit drin, muss ich 00:55:21.540 --> 00:55:24.020 gerade mal kurz gucken, oder habe ich es vielleicht 00:55:24.020 --> 00:55:25.580 sogar schon mal erwähnt, ich weiß nicht genau, 00:55:25.580 --> 00:55:27.500 aber das, das habe ich vor kurzem, äh, 00:55:27.500 --> 00:55:29.500 mal gesehen, das ist an mir vorbeigescrollt, ja. 00:55:29.500 --> 00:55:31.460 Das Coole ist, das bringt halt auch so ein 00:55:31.460 --> 00:55:33.340 Sandbox-Modus mit, das heißt, wenn ich irgendwie 00:55:33.340 --> 00:55:35.440 einem Kollegen was erkläre oder so, kann man 00:55:35.440 --> 00:55:37.280 das auch sehr gut mal dafür nutzen, um das so 00:55:37.280 --> 00:55:39.340 während ich erkläre, zu visualisieren. 00:55:40.020 --> 00:55:40.380 Cool. 00:55:40.380 --> 00:55:44.280 Ja, und dann gibt es so noch ein Git-School, 00:55:44.280 --> 00:55:47.000 Visualizing-Git heißt das, das funktioniert sehr 00:55:47.000 --> 00:55:49.280 ähnlich, hat halt nicht so dieses Aufgaben-Prinzip, 00:55:49.280 --> 00:55:52.740 ähm, was ich da finde, ist, dass es mit den 00:55:52.740 --> 00:55:54.400 Remotes so ein bisschen hübscher, 00:55:54.400 --> 00:55:56.420 ansehlicher ist, 00:55:56.420 --> 00:55:58.280 besser verständlich. 00:55:58.280 --> 00:56:00.880 Ha, muss man einfach mal reingucken. 00:56:01.580 --> 00:56:01.700 Ja. 00:56:01.700 --> 00:56:04.320 Schauen wir mal rein. 00:56:04.320 --> 00:56:05.700 Und ihr auch. 00:56:05.700 --> 00:56:09.780 Okay. 00:56:09.780 --> 00:56:15.020 So, ähm, das waren die Konzepte, 00:56:15.020 --> 00:56:16.540 habe ich das richtig verstanden? 00:56:16.540 --> 00:56:19.640 Also, wir sind schon, wir sind schon ein bisschen 00:56:19.640 --> 00:56:20.700 weitergegangen, genau. 00:56:20.700 --> 00:56:23.460 Ähm, sollen wir mal auf die eine oder andere 00:56:23.460 --> 00:56:26.640 Frage, äh, eingehen, die wir hatten oder die aus 00:56:26.640 --> 00:56:28.340 der Community kamen? Wir haben ja eine jetzt auch 00:56:28.340 --> 00:56:31.700 schon beantwortet, mindestens eine. Ähm, wir haben 00:56:31.700 --> 00:56:33.640 jetzt schon so ein bisschen über Tools gesprochen 00:56:33.640 --> 00:56:36.860 und GUIs, ähm, und vielleicht kommen wir mal 00:56:36.860 --> 00:56:39.500 zur ersten Frage, äh, das ist eine, die ich mir 00:56:39.500 --> 00:56:41.940 gestellt habe, ähm, und ich stelle sie jetzt auch 00:56:41.940 --> 00:56:43.680 nochmal, also, was würdest, was für ein Tool 00:56:43.680 --> 00:56:45.620 beziehungsweise welchen Workflow würdest du 00:56:45.620 --> 00:56:48.740 empfehlen, so für Dummies, ähm, wenn man 00:56:48.740 --> 00:56:51.720 möglichst wenig kaputt machen können will, sozusagen? 00:56:51.720 --> 00:56:53.180 Also, wenn man, wenn man möglichst wenig 00:56:53.180 --> 00:56:55.460 Ärger haben will, was für ein Git-Workflow 00:56:55.460 --> 00:56:56.940 würdest du empfehlen und was für ein Tool 00:56:56.940 --> 00:56:59.140 würdest du, ähm, empfehlen? 00:56:59.140 --> 00:57:01.320 Ja, es kommt halt immer so ein bisschen drauf an, 00:57:01.320 --> 00:57:03.160 was ich machen will. Es gibt sehr viele 00:57:03.160 --> 00:57:05.100 GUIs da draußen mittlerweile, äh, 00:57:05.100 --> 00:57:07.040 Sostree, Git-Kraken, äh, 00:57:07.040 --> 00:57:09.140 keine Ahnung, fallen jetzt gerade 00:57:09.140 --> 00:57:12.400 nicht alle ein. Ähm, was ich bei denen immer so 00:57:12.400 --> 00:57:14.900 schwierig finde, also ich habe früher auch immer 00:57:14.900 --> 00:57:17.420 nur auf die Teile abgezielt, ähm, fand das dann 00:57:17.420 --> 00:57:20.380 aber immer ein bisschen schwierig, wie das zu 00:57:20.380 --> 00:57:22.540 nutzen ist und dann sind halt auch so Sachen wie 00:57:22.540 --> 00:57:24.540 ein Rebass dann gerne in die Hose gegangen, weil 00:57:24.540 --> 00:57:27.540 ich nicht verstanden habe, was passiert. Ähm, seit 00:57:27.540 --> 00:57:29.240 ich mich ein bisschen tiefer damit beschäftigt 00:57:29.240 --> 00:57:31.440 habe, bevorzuge ich in der Tat dann doch die 00:57:31.440 --> 00:57:36.320 Konsole, weil das wirklich so, ja, so nah am 00:57:36.320 --> 00:57:39.360 Konzept ist. Es ist alles so verständlich und 00:57:39.360 --> 00:57:41.420 auch wenn man ein bisschen mehr tippen muss, 00:57:41.420 --> 00:57:44.080 finde ich, ist, ähm, nachvollziehbarer, was 00:57:44.080 --> 00:57:46.480 passiert, weil man halt nicht irgendeinen 00:57:46.480 --> 00:57:48.600 GUI hat, was das alles so ein bisschen verschleiert und 00:57:48.600 --> 00:57:51.600 unter der Haube dann zehn Kommandos ausführt, ähm, und 00:57:51.600 --> 00:57:55.600 du weißt dann nicht, was alles passiert ist. Ähm, wenn 00:57:55.600 --> 00:58:24.600 ich aber jetzt z.B. relativ Einsteiger bin und erst mal einfach was committen will, weil ich gerade, keine Ahnung, in einem GitHub Repository mitmachen möchte, um mich da so ein bisschen zu beteiligen, dann finde ich in der Tat die GitHub for Desktop App ganz gut. Die kann nicht viel, also so ein, keine Ahnung, interaktiven Rebase oder so, kriegst du damit nicht hin. Aber ich sag so, für die Basics funktioniert die super. Und das ist ja letztendlich Dateien adden in die Stage, dann kommit daraus erzeugen. 00:58:24.600 --> 00:58:45.040 und dann kommit daraus erzeugen, das irgendwo hin pushen und wieder pullen. Und gerade für Einsteiger finde ich es auch völlig legitim, wenn man dann mit Merge-Commits arbeitet, um sein Repository auf den aktuellen Stand zu bringen. Da muss man auch nicht der krasse Rebase-er sein, der sagt hier, so eine feine Linie ist meine History. Ist das nicht schön? 00:58:45.720 --> 00:58:56.080 Das wäre jetzt witzigerweise meine nächste Frage gewesen, Rebase oder Merge-Commits? Also ich glaube auch, das Einfachere sind Merge-Commits, wenn einen der Graph nicht interessiert. 00:58:56.080 --> 00:59:08.980 Du musst weniger nachdenken und ja, deswegen, du kannst dich auch erst mal dann auch wirklich auf die wichtigen Themen konzentrieren, nämlich dich irgendwo daran beteiligen und den Commit auf das Remote bringen. 00:59:10.040 --> 00:59:20.360 Vielleicht können wir die Begriffe nochmal abgrenzen, so für Dummies wie mich. Was ist jetzt genau mit Merge-Commit gemeint und gegen Rebase? 00:59:21.320 --> 00:59:32.120 Genau, also der Unterschied ist, Merge-Commit-Rebase. Bei dem Merge-Commit, also sagen wir, die Grundsituation ist, ich habe hier zwei verschiedene Stände und ich möchte zusammenführen. 00:59:33.720 --> 00:59:41.360 Ich habe zum Beispiel, mein Kollege hat in der Master-Branch auf dem zentralen Repository was hingepusht und ich möchte das jetzt bei mir drin haben. 00:59:41.360 --> 00:59:45.940 Da kann ich einfach erst mal hingehen und sagen, ich mache ein Git-Pull. 00:59:45.940 --> 00:59:50.920 Und was Git-Pull letztendlich unter der Haupte macht, ist, der macht erst mal ein Git-Fetch. 00:59:50.920 --> 00:59:56.960 Git-Fetch kopiert mir quasi die ganzen Objekte vom Remote in meinem Repository, was ich lokal habe. 00:59:58.000 --> 01:00:03.500 Und macht dann automatisch ein Merge zwischen mir und dem Remote. 01:00:03.500 --> 01:00:05.440 Und dann habe ich quasi ein Merge-Commit. 01:00:05.440 --> 01:00:12.780 Wenn Git feststellt, hey, da sind gar keine Änderungen, dann macht Git automatisch sowas, was dir ein Fast-Forward-Merge nennt. 01:00:12.780 --> 01:00:18.060 Dann nimmt er einfach dein Label und schiebt das ganz vorne einfach an den neuesten Commit dran. 01:00:18.060 --> 01:00:20.580 Wenn du zum Beispiel noch keinen einzigen Commit gemacht hast. 01:00:21.680 --> 01:00:27.640 Und bei einem Git-Rebase gehst du quasi hin und sagst, hey, ich habe hier schon zwei, drei Commits lokal gemacht. 01:00:27.640 --> 01:00:30.420 Konstantin hat auch schon gepusht. 01:00:30.420 --> 01:00:36.320 Ich möchte aber nicht diese ganze Verästelung haben, weil das irgendwann einfach total unübersichtlich wird. 01:00:36.320 --> 01:00:40.400 Und ich nicht mehr so einfach nachvollziehen kann, wo kommt jetzt welche Änderung her. 01:00:40.940 --> 01:00:48.960 Deswegen entscheide ich mich und entscheidet sich das Team dazu und sagt, hey, wir wollen möglichst eine lineare Historie haben. 01:00:48.960 --> 01:00:51.660 Dann musst du dann mit einem Rebase arbeiten. 01:00:51.660 --> 01:01:00.540 Und dann Git quasi Git hin und nimmt deine Commits und spielt die dann auf dem letzten Commit in dem Remote quasi wieder. 01:01:01.820 --> 01:01:03.900 Aber dadurch hast du halt diese Verzweigung nicht mehr. 01:01:03.900 --> 01:01:14.060 Also du hast keinen Merge-Commit, der dann zwei Eltern-Element hat, sondern du hast wirklich neue Commits, die dann nachfolgend dem letzten Commit, den du gefetscht hast, dann ablaufen. 01:01:16.140 --> 01:01:33.780 Ja, an der Stelle natürlich die Frage, wie, wenn wir jetzt schon bei Rebacen sind, ich habe ja mal dieses Problem beschrieben, was du jetzt auch schon so ein bisschen angerissen hast, dieser Konflikte, die bei mir auftreten, obwohl ich gar keine, obwohl ich die Files vielleicht gar nicht angefasst habe. 01:01:33.780 --> 01:01:37.920 Also ich muss so mehrfach diesen Prozess durchlaufen beim Rebase. 01:01:37.920 --> 01:01:52.000 Im Prinzip so für jeden Commit einzeln habe ich das Gefühl, also ich weiß nicht genau, wie ich in diesen Zustand gekommen bin, aber ich hatte dann jedes Mal wieder Konflikte bei jedem einzelnen Commit, der von außen reinkam, aber die gar nicht meine Files waren. 01:01:52.000 --> 01:01:52.820 Ja. 01:01:52.820 --> 01:01:55.680 Kannst du mir sagen, wie ich da hingekommen bin und wie ich da nicht mehr hinkomme? 01:01:55.680 --> 01:01:59.940 Natürlich nicht. Es gibt wahrscheinlich tausend Situationen, wie du da hingekommen bist. 01:01:59.940 --> 01:02:07.160 Ich kann mir was vorstellen, was wahrscheinlich ist, aber ich kann es ja nicht mit Sicherheit sagen, weil ich halt nicht dabei war. 01:02:07.160 --> 01:02:12.340 Ich würde da erst noch mal ein bisschen drüber eingehen, wie funktioniert Rebase überhaupt? 01:02:12.340 --> 01:02:17.700 Also Rebase, die Anwendungsförderung haben wir uns ja gerade schon so ein bisschen angeguckt. 01:02:17.700 --> 01:02:23.500 Meistens mache ich das halt, um meine Änderungen auf den aktuellsten Stand zu bringen. 01:02:23.500 --> 01:02:26.380 Ich kann Rebase aber auch nutzen, um aufzuräumen. 01:02:26.380 --> 01:02:27.660 Kommen wir später nochmal zu. 01:02:29.400 --> 01:02:33.280 Was macht Rebase, wenn ich den Befehl ausführe? 01:02:33.280 --> 01:02:36.640 Ich muss ja ein Ziel angeben, wohin ich Rebasen möchte. 01:02:36.640 --> 01:02:46.620 Und was Git dann letztendlich macht, der sucht den letzten gemeinsamen Commit zwischen meinem aktuellen Head, wo ich gerade drauf bin, und dem Ziel, was ich angegeben habe. 01:02:46.620 --> 01:02:54.340 Das heißt, er geht meine Linie runter und sucht den Commit, den unsere beiden Zweige gemeinsam haben. 01:02:55.540 --> 01:03:01.900 Und dann nimmt er alle Commits, die er gefunden hat in meinem Zweig und legt quasi für alle einen Patch an. 01:03:01.900 --> 01:03:05.780 Also wirklich das Patch-File-Format. 01:03:05.780 --> 01:03:11.080 Wir haben ja festgestellt, Git speichert keine Diffs, sondern speichert ja den absoluten Stand. 01:03:11.880 --> 01:03:15.180 Und jetzt brauche ich aber gerade quasi einen Diff, den ich anwenden kann. 01:03:15.180 --> 01:03:16.900 Und deswegen macht er für jeden Commit einen Patch. 01:03:16.900 --> 01:03:24.100 Und was er dann macht, ist, der nimmt die Patches wieder von vorne nach hinten und auf dem Ziel, wo ich hin möchte, bepleitet die alle. 01:03:24.100 --> 01:03:25.220 Nach und nach. 01:03:26.820 --> 01:03:27.860 Ah, okay. 01:03:27.860 --> 01:03:40.280 Jetzt geht der Konstantin hin und ändert aus irgendeinem Grund die Commits, keine Ahnung, ändert nochmal eine Datei, hat eine Konsole-Lock rausgelöscht, gehört da ja nicht rein. 01:03:40.280 --> 01:03:42.900 Hat er dann schön mit einem interaktiven Rebase gemacht. 01:03:42.900 --> 01:03:44.820 Guckst du mir heimlich zu? 01:03:48.140 --> 01:03:51.540 Ich kann auch keine Ahnung, einen anderen Namen ausdrücken. 01:03:51.540 --> 01:03:52.440 Nee, nee, ist schon okay. 01:03:52.440 --> 01:03:53.040 Schon okay. 01:03:53.040 --> 01:03:56.640 Ich fühle mich nur ein bisschen ertappt. 01:03:56.640 --> 01:04:13.400 Jetzt pusht er die ganze Geschichte nach vorne und somit hat er quasi eine neue Historie erzeugt, weil er hat jetzt die Commit-Hashes verändert durch seine Änderung an einer Datei irgendwo in der Historie. 01:04:13.400 --> 01:04:17.540 Der Mopeds hat jetzt aber noch die alten Commits bei sich. 01:04:18.020 --> 01:04:27.780 Und wenn der Mopeds jetzt einfach hingeht und sagt, gib Rebase, Regen, unser Feature, dann sucht er ja den gemeinsamen Commit von unseren beiden Zweigen. 01:04:27.780 --> 01:04:34.400 Was er dann zwangsläufig bei mir finden wird oder bei Mopeds, sind halt auch die alten Commits von Konstantin. 01:04:34.400 --> 01:04:37.920 Und die versucht er jetzt auch wieder alle anzuwenden. 01:04:37.920 --> 01:04:45.860 Wenn jetzt der Konstantin aber diese Dateien verändert hat, kann das natürlich dazu führen, dass du dann die ganze Zeit Konflikte bekommst. 01:04:46.240 --> 01:04:48.680 Obwohl du an diesen Dateien eigentlich gar nichts gemacht hast. 01:04:48.680 --> 01:04:58.000 Weil du quasi die Commits, die eigentlich Konstantin gemacht hatte, vor 1-2 Wochen, jetzt anfängst auf Konstantins neue Historie anzuwenden. 01:04:59.000 --> 01:05:04.640 Da ist es quasi sinnvoll, wenn du so ein Rebase machst, dass du einfach beschränkst, was möchtest du rebasen. 01:05:04.640 --> 01:05:16.780 Du kannst dann bei dem Rebase-Kommando, wenn du es in der Konsole eintippst, kannst du sagen, du möchtest mit dem Parameter onto, gibst du dann den Branch an, wo du hin möchtest. 01:05:17.320 --> 01:05:25.440 Und dann kannst du als Argument angeben, wie viele Commits du, welche Commits du bis wohin dir nehmen möchtest. 01:05:25.440 --> 01:05:32.980 Ich mache dann immer so Sachen wie hat tilde 5, was so ein Shorthand dafür ist, vom aktuellen hat 5 Commits zurück. 01:05:34.080 --> 01:05:35.940 Weil ich weiß, ich habe 5 Commits gemacht. 01:05:35.940 --> 01:05:39.420 Ich kann ja hier mit Gitist mal schnell in die Historie gucken, dann sehe ich, aha, 5 Commits. 01:05:39.420 --> 01:05:41.720 Ich kann mir auch den absoluten Hash daraus kopieren. 01:05:41.720 --> 01:05:46.920 Dann muss ich aber den vor meinem letzten Commit nehmen, weil der Hash, den ich angebe, das ist immer exklusive. 01:05:47.320 --> 01:05:52.120 Und dann kann ich sagen, hey, ich möchte nur die 5 Commits rebasen, die ich selber gemacht habe. 01:05:52.120 --> 01:05:58.780 Und damit kann man das Thema schon so einen guten Schritt entschärfen. 01:05:58.780 --> 01:06:00.240 Genau. 01:06:00.240 --> 01:06:02.140 Wichtig ist einfach immer, hey, was macht Git? 01:06:02.140 --> 01:06:05.700 Der sucht erstmal den Schnittpunkt von uns beiden. 01:06:05.700 --> 01:06:11.640 Und wenn ich natürlich rebase und das Zeug pushe, dann sind das natürlich andere Commits. 01:06:11.840 --> 01:06:18.620 Und somit findet Git die dann auch nicht oder denkt fälschlicherweise, dass er die auch rebasen soll. 01:06:18.620 --> 01:06:20.380 Genau. 01:06:20.380 --> 01:06:26.940 Bringt auf jeden Fall ein bisschen mehr Licht in mein Git-Dunkel. 01:06:26.940 --> 01:06:28.800 Werde ich auf jeden Fall mal drauf achten. 01:06:28.800 --> 01:06:34.780 Ich bin jetzt tatsächlich aber dazu übergegangen und wir haben das jetzt auch projektweit so beschlossen, dass wir Merge-Commits machen. 01:06:34.780 --> 01:06:39.520 Und damit, seitdem ist das Problem auch nicht mehr aufgetaucht, logischerweise. 01:06:39.520 --> 01:06:47.280 Aber ich weiß gar nicht, ich glaube, irgendwie Git macht aber unter der Haube manchmal auch noch Rebases, wo man gar nicht selbst Rebase jetzt getriggert hat, oder? 01:06:47.280 --> 01:06:52.300 Ist das nicht irgendwie auch so implizit in irgendwelchen Sachen mit drin? 01:06:52.300 --> 01:06:59.440 Weil es gibt ja quasi so, manche Git-Befehle sind ja so Aliases, die dann verschiedene andere Git-Befehle ausführen. 01:06:59.440 --> 01:07:00.800 Ich überlege gerade. 01:07:03.440 --> 01:07:09.740 Also, was du machen kannst, ist, dass du Git konfigurieren kannst, was passieren soll, wenn du Pult sagst, dass er dann Rebase versucht. 01:07:09.740 --> 01:07:16.980 Es ist halt häufig dann nicht möglich und dann fängst du an, dann selbst das Problem zu lösen. 01:07:16.980 --> 01:07:19.560 Ja, das ist hart belassen. 01:07:19.560 --> 01:07:26.400 Genau, also das habe ich dann auch ausgeschaltet, dass das nicht passiert, beziehungsweise auf Merge umgestellt. 01:07:26.400 --> 01:07:27.880 Der Standard ist ja dann Merge. 01:07:27.880 --> 01:07:29.600 Oder man kann die Standard einstellen. 01:07:29.600 --> 01:07:32.540 Ja, es ist definitiv die Variante mit weniger Fehlerpotenzial. 01:07:32.540 --> 01:07:38.820 Ja, ich persönlich mag es, wenn die Historie aber auch geil aussieht. 01:07:40.400 --> 01:07:43.080 Also nicht nur der Code geil aussieht, sondern auch die Historie. 01:07:43.080 --> 01:07:55.460 Und wir sind bei uns eigentlich, ich glaube mittlerweile auch im ganzen Unternehmen, also ich mache bei uns auch hier und da mal so einen Vortrag-Workshop zum Thema Git. 01:07:55.460 --> 01:07:59.400 Und ich glaube, bei uns sind mittlerweile alle Teams fleißig am Rebasen. 01:08:01.200 --> 01:08:05.440 Aber die Probleme, wie du so beschrieben hast, kommen halt auch, ganz ehrlich, die passieren auch mir. 01:08:05.440 --> 01:08:09.320 Und auch ich sitze manchmal da und denke, warum schlägt das jetzt viel? 01:08:09.320 --> 01:08:22.800 Was noch ein ganz wichtiger Punkt ist, wenn du Konflikte löst in einem Rebase, du musst immer den Konflikt so lösen, wie der zu diesem Zeitpunkt sein soll. 01:08:23.180 --> 01:08:27.540 Also wir machen ja unsere Patchs, macht ja Git-Rebays und wendet die an. 01:08:27.540 --> 01:08:34.140 Und wenn dann so ein Patch fehlschlägt, also die Anwendung des Patches fehlschlägt, dann kriegst du ja diesen Merge-Konflikt. 01:08:34.140 --> 01:08:40.080 Und dann darfst du nicht hingehen und sagen, ja, ich weiß, zum Schluss muss das so aussehen. 01:08:40.080 --> 01:08:41.880 Das darfst du nicht machen. 01:08:41.880 --> 01:08:46.420 Du musst hingehen und sagen, hey, zu diesem Zeitpunkt muss es so und so aussehen. 01:08:46.420 --> 01:08:48.300 Ich weiß, dass das gleich noch geändert wird. 01:08:48.300 --> 01:08:49.920 Das ist total schwierig. 01:08:49.920 --> 01:08:54.180 Also erstmal die ganzen Commits im Kopf zu verarbeiten. 01:08:54.180 --> 01:09:01.260 Was ich da ganz gerne mache, Git, wenn der den Merge versaut hat, dann sagt er, hey, ich konnte dem den Commit nicht anwenden. 01:09:01.260 --> 01:09:06.320 Wenn ich es überhaupt nicht hinkriege, dann gehe ich auch manchmal hin und sage dann einfach Git-Show auf diesen Commit-Hash. 01:09:06.320 --> 01:09:09.380 Und dann sehe ich, was dieser Commit eigentlich machen möchte. 01:09:09.380 --> 01:09:16.420 Und dann kann man meistens einfach daraus schließen, ach ja, er will nur diese Klasse ändern in meinem HTML. 01:09:16.420 --> 01:09:18.860 Ich habe aber noch zwei, drei weitere Klassen hinzugefügt. 01:09:18.860 --> 01:09:22.100 Ja gut, dann nehme ich einfach diese Klasse und ändere die gerade manuell nochmal. 01:09:22.100 --> 01:09:26.180 Okay, weil das ist nämlich dann der Grund, warum sonst genau das passiert, was Moritz gesagt hat. 01:09:26.180 --> 01:09:34.720 Dass du immer wieder Konflikte und den nächsten Konflikt und den nächsten Konflikt, weil das eben diesen Rattenschwanz hinter sich her zieht, weil du es nicht zu dem Zeitpunkt geändert hast, sondern wieder irgendwas anderes noch drin hast. 01:09:35.560 --> 01:09:41.300 Git macht ja diese Patches und in dem Patch steht ja quasi immer drin, welche Zeile wird gelöscht, welche wird dafür eingefügt. 01:09:41.300 --> 01:09:47.080 Und der findet einfach dann nicht mehr diese Zeile, wie sie gelöscht wird, weil du die schon irgendwas ganz anderes geändert hast. 01:09:47.080 --> 01:10:01.260 Das ist auch super wichtig, dass man da die Kontrolle behält und nicht versucht, das schnell zu fixen, sondern dann einfach nochmal kurz nachdenkt. 01:10:02.000 --> 01:10:07.380 Ich meine auch, dass man sich diesen letzten Commit, den er nicht anwenden konnte, mit rebase hat anzeigen lassen kann. 01:10:07.380 --> 01:10:09.640 Also git show rebase tiefstrich hat. 01:10:09.640 --> 01:10:12.480 Ich meine, das ist der Commit, den er nicht anwenden konnte. 01:10:12.480 --> 01:10:15.820 Da muss man nicht immer im Text nach der Commit-Message suchen. 01:10:15.820 --> 01:10:18.840 Genau. 01:10:18.840 --> 01:10:26.140 Ja, und wichtig ist halt, wenn man halt mit rebase arbeitet, dass man seine Kollegen nicht abhängt. 01:10:27.340 --> 01:10:32.860 Also ich kann nicht einfach hingehen und die ganze History dann ins Remote pushen und meine Kollegen kriegen das nicht mit. 01:10:32.860 --> 01:10:38.580 Also da ist es dann halt sinnvoll, eine Strategie zu wählen, wie das möglichst vermieden wird. 01:10:40.020 --> 01:10:45.980 Was wir ja mal in einem Projekt gemacht haben, wo wir sehr viele Leute immer an einem Feature gearbeitet haben. 01:10:45.980 --> 01:10:48.780 Wir haben einfach mehrere Branches gemacht für dieses Feature. 01:10:48.780 --> 01:10:50.480 Wir hatten quasi eine Feature-Branch. 01:10:50.480 --> 01:10:54.340 Da haben wir gesagt, hey, an diesem darf niemand rebasen. 01:10:55.200 --> 01:11:00.020 Und von diesem Feature-Branch abzweigend hat dann jeder sein Mini-Feature gemacht. 01:11:00.020 --> 01:11:04.280 Ich baue eine Komponente ein, ich ändere was an der State-Behandlung, wie auch immer. 01:11:04.280 --> 01:11:07.500 Und in seinem eigenen Branch konnte man dann rebasen, wie man möchte. 01:11:07.500 --> 01:11:13.700 Und wenn man fertig war, hat man einen Pull-Request aufgemacht in diesem eigentlichen Feature-Branch. 01:11:14.860 --> 01:11:20.220 Und wenn man dann gesagt hat, okay, das ganze Team ist jetzt fertig, das Feature steht kurz vor Merch in den Master, 01:11:20.220 --> 01:11:22.840 dann kann man nochmal hingehen, okay, alle Finger weg. 01:11:22.840 --> 01:11:23.700 Okay. 01:11:23.700 --> 01:11:27.320 Zwei Leute setzen sich hin und räumen da dann nochmal die letzte Historie auf. 01:11:27.320 --> 01:11:31.400 Ist in der Firma natürlich besser abzusprechen, als es bei einem Open-Source-Projekt, 01:11:31.400 --> 01:11:35.140 wenn ich da irgendwie anfange, was zu rebasen und dann mache ich allen anderen was kaputt. 01:11:35.140 --> 01:11:41.620 Definitiv, aber bei einem Open-Source-Projekt, zumindest wie es mir bislang gegangen ist, 01:11:41.720 --> 01:11:44.960 ist es ja meistens so, dass du allein in einem Branch arbeitest. 01:11:44.960 --> 01:11:45.480 Ja, ja. 01:11:45.480 --> 01:11:48.840 Wenn du jetzt mit GitHub arbeitest, ja auch in deinem eigenen Repository. 01:11:48.840 --> 01:11:53.560 Und da kannst du ja erstmal rumrebasen, bis du schwachzwirst. 01:11:53.560 --> 01:12:02.340 Und kannst dann nachher dann in deinem Pull-Request, kannst du dann nachher dann den finalen Stand machen. 01:12:02.340 --> 01:12:05.640 Das wäre eine gute Überleitung zum Gesquasche. 01:12:05.640 --> 01:12:08.940 Zum Gesquasche, ja. 01:12:08.940 --> 01:12:11.420 Ich hätte noch eine Frage vorher. 01:12:11.720 --> 01:12:13.540 Weil mir das jetzt gerade wieder eingefallen ist. 01:12:13.540 --> 01:12:15.960 Ich hatte das auch mal auf der Liste drauf, habe es dann wieder weg. 01:12:15.960 --> 01:12:24.860 Hat das irgendwie was mit dem Befehl, also bringt da irgendwie, da gibt Befehl Re Re Re was. 01:12:24.860 --> 01:12:30.140 Weil ich habe das irgendwo bei mir im Hinterkopf, ich weiß nicht, ob ich dich jetzt eiskalt erwische. 01:12:30.140 --> 01:12:30.840 Total. 01:12:30.840 --> 01:12:34.240 Re Re Re schon gesehen, aber ohne Scheiß, ich weiß nicht, was er macht. 01:12:35.560 --> 01:12:38.040 Ich habe gerade nochmal nachgelesen, was es überhaupt heißt. 01:12:38.040 --> 01:12:40.180 Also es ist tatsächlich, es ist kein Quatsch. 01:12:40.180 --> 01:12:44.480 Reuse Recorded Resolution of Conflicted Mergers. 01:12:44.480 --> 01:12:46.800 Okay, dann müssen wir da jetzt auch nicht tiefer drauf einsteigen. 01:12:47.120 --> 01:12:51.660 Ich weiß, dass irgendjemand mal zu mir kam, ein Developer sagt, was, du hast hier das Problem 01:12:51.660 --> 01:12:54.200 hier mit bla und dann macht so, mach mal mal Git Re Re Re. 01:12:54.200 --> 01:12:58.580 Und ich so, das klingt jetzt erst mal wie ein Witz, also ein Befehl, der Re Re Re heißt. 01:12:58.580 --> 01:13:00.160 Ehrlich jetzt? 01:13:00.160 --> 01:13:01.020 Und das gibt es dann wirklich. 01:13:01.020 --> 01:13:05.060 Und okay, gut, dann können wir ja mal, das packen wir einfach mal, den Link dazu packen wir 01:13:05.060 --> 01:13:05.860 einfach mal in die Shownotes. 01:13:05.860 --> 01:13:08.920 Das könnt ihr dann in den Shownotes nachlesen und lernen, dass das genau macht. 01:13:08.920 --> 01:13:12.260 Dann nutze ich den Link nämlich mal, um zu verstehen. 01:13:12.260 --> 01:13:15.680 Also ich frage mich gerade, wann recordet er halt die Resolution? 01:13:15.680 --> 01:13:19.200 Aber ja, vielleicht hilft das. 01:13:19.200 --> 01:13:24.360 Also vielleicht merkt er ja, dass ich immer diese Klassennamen, die ich da fälschlicherweise 01:13:24.360 --> 01:13:25.740 geändert habe, anpassen muss. 01:13:25.740 --> 01:13:29.140 Und dann checkt er, dass er das einfach direkt macht. 01:13:29.140 --> 01:13:33.480 Also ich kann ja mal kurz den ersten Satz aus der Description vorlesen davon. 01:13:33.480 --> 01:13:39.060 Also in a workflow employing relatively long-lived Topic Branches, der Developer sometimes needs 01:13:39.060 --> 01:13:44.000 to resolve the same conflicts over and over again until the Topic Branches are done. 01:13:44.000 --> 01:13:46.340 Klingt irgendwie schon ein bisschen ähnlich. 01:13:46.340 --> 01:13:49.000 Nach dem, was ich vorhin beschrieben habe. 01:13:49.000 --> 01:13:51.880 Vielleicht ist das auch, müssen wir mal gucken. 01:13:51.880 --> 01:13:53.440 Können wir im Nachgang mal schauen. 01:13:53.440 --> 01:13:56.740 Genau, das schieben wir dann hinterher, nächste Folge. 01:13:56.740 --> 01:13:59.820 Genau, das schieben wir hinterher vielleicht irgendwann mal, nächste Folge oder so. 01:13:59.820 --> 01:14:03.180 Okay, gut, jetzt kommen wir zum Squashing, oder, Konstantin? 01:14:03.480 --> 01:14:10.880 Ich hatte das jetzt schon öfter, dass ich eben an irgendeinem GitHub-Repository mitgearbeitet 01:14:10.880 --> 01:14:15.960 habe und manche haben da, also manche akzeptieren das auch, wenn du da irgendwie zwölf Commits 01:14:15.960 --> 01:14:20.480 in einem Pull-Request hast und andere fahren halt knallhart die Linie, nee, ein Pull-Request, 01:14:20.480 --> 01:14:26.260 dann machen wir einen einzelnen Commit, der alles, also das komplette Feature dann enthält. 01:14:27.240 --> 01:14:32.500 Und da hatte ich jetzt dann eigentlich jedes Mal das Problem, das hinzubekommen mit dem Squashen. 01:14:32.500 --> 01:14:36.280 Also, dass ich eben mehrere Commits nehme und die zusammenpacke und dann nur noch ein Commit 01:14:36.280 --> 01:14:37.880 habe mit allen Änderungen, die die gemacht haben. 01:14:37.880 --> 01:14:38.660 Ja. 01:14:39.060 --> 01:14:42.780 Und ich weiß nicht so ganz, was ich da immer falsch mache. 01:14:42.780 --> 01:14:47.440 Also, man wählt ja dann aus, vielleicht, aber vorhin habe ich schon gedacht, als du gemeint 01:14:47.440 --> 01:14:52.840 hast, man muss, wenn man mit dieses Hat-5, also dass man fünf Commits zurückgeht, dass das 01:14:52.840 --> 01:14:59.160 eben exklusiv ist und dass da eben der letzte, also ich muss dann den da vornehmen, den Commit. 01:14:59.160 --> 01:15:02.760 Und das kann natürlich sein, dass das vielleicht auch schon mein Problem war, dass sonst halt 01:15:02.760 --> 01:15:05.800 irgendwelche Sachen nicht drin waren und ich dann den ersten Commit dann doch noch als 01:15:05.800 --> 01:15:07.600 einzelstehenden Commit hatte. 01:15:07.600 --> 01:15:11.540 Also, wenn das dein Problem ist, dass der erste Commit einzelstehend immer noch da war, 01:15:11.540 --> 01:15:13.280 dann ist das das Problem. 01:15:13.280 --> 01:15:13.780 Ja. 01:15:13.780 --> 01:15:18.120 Aber du hattest ja auch mal ... 01:15:18.120 --> 01:15:20.440 Ich hatte es aber auch schon so, dass ich ... 01:15:20.440 --> 01:15:23.640 Oder mal das Problem hast, dass Dinge dann einfach irgendwie kaputt gehen. 01:15:23.640 --> 01:15:28.040 Ja, also, es waren dann irgendwie alle Commits noch da und zusätzlich ein Commit, der dann 01:15:28.040 --> 01:15:32.540 die Commit-Message hatte, wo ich reingeschrieben habe, squashed everything together oder so, ja. 01:15:32.900 --> 01:15:35.680 Und der war dann aber noch da und ich weiß aber nicht, was in dem dann passiert ist, weil 01:15:35.680 --> 01:15:38.420 eigentlich war da sonst nichts geändert und die anderen Commits waren trotzdem noch 01:15:38.420 --> 01:15:38.900 da gestanden. 01:15:38.900 --> 01:15:44.600 Was ich dann gemacht habe, ich habe das Pro-Request zugemacht, weil ich mir nicht anders zu helfen 01:15:44.600 --> 01:15:50.340 wusste, habe das nochmal in einen neuen Feature-Branch angelegt bei mir, wo wirklich nur die Änderung 01:15:50.340 --> 01:15:51.640 drin war und nochmal committed. 01:15:52.140 --> 01:15:54.720 So blöd es ist, aber genau, richtig. 01:15:54.720 --> 01:16:00.120 Also, ja, weil ich mir einfach nicht anders zu helfen wusste, weil ich da nicht durchsteige, 01:16:00.120 --> 01:16:00.920 was da so passiert. 01:16:00.920 --> 01:16:05.400 Also, ich habe ja auch mal so ein Demo-Repository angelegt, da habe ich dir vorhin den Link geschickt, 01:16:05.400 --> 01:16:09.900 wo einfach irgendwie, das ist nur eine Readme in dem Repository und da habe ich fünf Commits 01:16:09.900 --> 01:16:12.160 gemacht mit Änderungen, wo ich eine Zeit hinzugefügt habe. 01:16:12.160 --> 01:16:16.980 Ich kann ja mal versuchen, was würde ich denn jetzt, normalerweise arbeite ich mit Source-Tree 01:16:16.980 --> 01:16:21.880 als GUI, aber wir können das gerne mal einfach über die, was die Command-Line machen. 01:16:21.880 --> 01:16:28.100 Du hast mich ja vor, im Moment, nicht vorgewarnt, du hast mich vorhin informiert, als wir darüber 01:16:28.100 --> 01:16:32.340 gesprochen hatten schon mal, dass du Source-Tree benutzt, da habe ich ja, weißt du was, ich 01:16:32.340 --> 01:16:35.560 da habe mir jetzt noch Source-Tree benutzt, da habe ich mal gerade, was der Konstantin da 01:16:35.560 --> 01:16:36.360 falsch gemacht hat. 01:16:36.360 --> 01:16:40.400 Ich habe es nicht hingekriegt, dann Squash zu machen. 01:16:40.400 --> 01:16:41.260 Okay. 01:16:41.260 --> 01:16:42.400 Es tut mir leid. 01:16:42.400 --> 01:16:46.860 Ich wüsste, tatsächlich ist das auch so. 01:16:46.980 --> 01:16:51.360 Ding, ich, manche Sachen mache ich nämlich dann auch tatsächlich über die Command-Line, 01:16:51.360 --> 01:16:54.240 weil ich einfach nicht weiß, wie man es in Source-Tree hingekriegt, weil das ist genau 01:16:54.240 --> 01:16:58.000 dieses Ding, du hast da schöne Menüsen so, das macht erstmal alles einfacher, aber du 01:16:58.000 --> 01:17:01.120 weißt halt nicht, was im Hintergrund passiert und du weißt manchmal auch nicht, wo du eben 01:17:01.120 --> 01:17:02.540 was findest, wenn du das Feature brauchst. 01:17:02.540 --> 01:17:08.440 Und es kann sein, dass ich das gar nicht über Source-Tree gemacht hatte, weil ich sehe 01:17:08.440 --> 01:17:11.940 da tatsächlich auch kein, wahrscheinlich habe ich eben, weil ich halt nicht wusste, was Rebase 01:17:11.940 --> 01:17:12.640 so genau macht. 01:17:12.640 --> 01:17:15.740 Vielleicht habe ich es auch versucht, über den Rebase zu machen und habe deswegen dann Sachen 01:17:15.740 --> 01:17:16.320 kaputt gemacht. 01:17:16.320 --> 01:17:20.620 Also mein Ansatz wäre auch tatsächlich ein Rebase. 01:17:20.620 --> 01:17:23.120 Wüsste nicht anders, wie ich die Sachen zusammen 01:17:23.120 --> 01:17:26.060 squashen könnte, ohne ein Rebase zu machen, ehrlich gesagt. 01:17:26.060 --> 01:17:32.080 Aber mein Ansatz wäre tatsächlich ein interaktiver Rebase, in dem Fall. 01:17:32.080 --> 01:17:39.380 Das machst du mit git rebase minus i und ja, dann kommt halt darauf an, wie sauber die 01:17:39.380 --> 01:17:44.260 Historie schon ist, aber jetzt in deinem Fall zum Beispiel, wenn du jetzt für so ein Open-Source-Projekt 01:17:44.260 --> 01:17:50.560 mit einem Pull-Request aufmachst, dann ist ja meistens kein anderer Branch da oder du hast 01:17:50.560 --> 01:17:53.860 keine Commits, die ein anderer gerebased hat und so und es ist alles schön sauber. 01:17:54.660 --> 01:18:00.180 Dann gehe ich meistens hin und sage dann git rebase minus i und dann keine Ahnung, origin slash master. 01:18:00.180 --> 01:18:04.580 Also nicht mal mein lokalen Master, weil ich weiß nicht, ob ich den jetzt mal aktualisiert habe. 01:18:04.580 --> 01:18:06.580 Ich nehme da immer sowas wie origin master. 01:18:06.580 --> 01:18:07.520 Ich probiere das einfach mal. 01:18:07.520 --> 01:18:10.960 Wenn du jetzt ein GitHub-Fork hast, dann hast du ja wahrscheinlich so ein Upstream-Remote 01:18:10.960 --> 01:18:12.020 noch hinzugefügt. 01:18:12.020 --> 01:18:15.680 Das ist ja einfach ein zweites Remote mit einem anderen Namen, nichts weiter. 01:18:15.680 --> 01:18:20.620 Dann würde ich jetzt sagen, git rebase minus i, upstream slash master zum Beispiel. 01:18:20.620 --> 01:18:29.840 Was dann passiert ist, es geht dein in Git-konfigurierter Editor auf, standardmäßig vim und vi. 01:18:29.840 --> 01:18:37.500 Da auch nochmal mein Tipp für alle, die mit vi nicht so gerne arbeiten, weil sie ihn nicht mehr 01:18:37.500 --> 01:18:38.240 verlassen können. 01:18:38.240 --> 01:18:43.940 Das kann man konfigurieren und zwar mit git config minus minus global für, ich möchte 01:18:43.940 --> 01:18:48.040 das für meinen ganzen Rechner tun, core.editor und dann kann ich einfach einen anderen Editor 01:18:48.040 --> 01:18:48.480 angeben. 01:18:48.480 --> 01:18:53.960 Bei mir ist es zum Beispiel Sublime, den müsste ich dann aber mit Parameter minus w angeben, 01:18:53.960 --> 01:18:57.840 weil dann git wartet, bis ich Sublime wieder geschlossen habe, beziehungsweise die Dateien 01:18:57.840 --> 01:18:58.840 in Sublime geschlossen habe. 01:18:58.840 --> 01:19:06.140 Ich wusste gar nicht, dass man da, das ist cool zu wissen, weil ich wusste nicht, dass man 01:19:06.140 --> 01:19:09.860 da Editoren angeben kann, die nicht auf der Kommandozeile laufen. 01:19:09.860 --> 01:19:14.580 Also ich habe da bei mir Nano angegeben, aber wenn man dann mit minus w und das, ah, das 01:19:14.580 --> 01:19:18.360 ist wirklich cool zu wissen, weil da kann ich da auch mein Vs Code nehmen oder sowas. 01:19:18.660 --> 01:19:23.520 Ja genau, ich bin ja ein Atommensch, aber ich habe ihn nicht genommen, weil er mir, auch 01:19:23.520 --> 01:19:26.200 wenn er relativ schlank ist, dann trotzdem so lange startet. 01:19:26.200 --> 01:19:31.440 Also da ist Sublime gefühlt immer noch umgeschlagen im schnellen Starten. 01:19:31.440 --> 01:19:35.000 Ich habe aber auch Sublime nur noch für diesen einen anwendungsvollen Rechner. 01:19:35.820 --> 01:19:39.720 Wenn ich auch ganz schnell irgendwo was hinschreiben will als Notiz, dann mache ich das auch 01:19:39.720 --> 01:19:40.480 schnell in Sublime. 01:19:40.480 --> 01:19:46.100 Genau, dann hatten wir es in unserer Editor-Folge auch, dass wir das auch so handhaben zum Teil. 01:19:46.100 --> 01:19:48.160 400 geöffnete Tabs. 01:19:48.160 --> 01:19:49.840 Ja genau, richtig. 01:19:49.840 --> 01:19:57.320 Ich habe jetzt hier gerade mal meinen Bildschirm geschert, beziehungsweise das Command-Fenster. 01:19:58.160 --> 01:20:01.560 Und das ist jetzt eben, also ich weiß gar nicht, ist das auch tatsächlich Wim, was 01:20:01.560 --> 01:20:05.160 da GIT unter Windows mitbringt oder irgendwie nur was, was so aussieht? 01:20:05.160 --> 01:20:10.780 Weiß gar nicht, wie das intern läuft oder ist das irgendwie über Sequen? 01:20:10.780 --> 01:20:11.780 Ja gut, okay. 01:20:11.780 --> 01:20:16.120 Aber es sieht jedenfalls so aus, wie so ein Wim-Fenster auch aussieht. 01:20:16.120 --> 01:20:18.280 Und was mache ich denn da jetzt genau? 01:20:18.280 --> 01:20:21.960 Was auch immer, wie du den Editor konfiguriert hast, es geht in den Editor auf und du siehst 01:20:21.960 --> 01:20:24.940 jetzt ganz viele Zeilen, in denen vorne immer Pick steht. 01:20:24.940 --> 01:20:27.280 Genau, Pick, dann der Hash und die Combit-Message. 01:20:27.280 --> 01:20:28.800 Die Combits, die er jetzt gefunden hat. 01:20:28.800 --> 01:20:32.340 Also in der Range, die du wie auch immer angegeben hast, hat er jetzt genau diese Combits 01:20:32.340 --> 01:20:32.680 gefunden. 01:20:32.680 --> 01:20:34.940 Genau, also ich sage nochmal kurz, was ich gemacht habe, um da hinzukommen. 01:20:34.940 --> 01:20:39.200 Also wie du es gesagt hast, ich hatte Git, Rebase, Midus-E und dann Origin-Main. 01:20:39.200 --> 01:20:40.540 Genau. 01:20:40.540 --> 01:20:44.220 Und was er jetzt quasi macht, ist erstmal, er pickt einfach alle Combits. 01:20:44.220 --> 01:20:46.340 Das ist quasi wie ein Cherry-Pick, was er da macht. 01:20:46.340 --> 01:20:53.060 Er geht jetzt quasi auf dein Ziel und wendet jetzt jeden dieser Combits da drauf an. 01:20:53.720 --> 01:20:58.340 Wenn du das jetzt nicht möchtest, kannst du jetzt das Kommando, was vorne steht, also 01:20:58.340 --> 01:20:59.980 das Pick, kannst du dann quasi ändern. 01:20:59.980 --> 01:21:07.300 Wenn der Editor aufgeht, unter den Combits drunter steht eine Liste von allem möglichen 01:21:07.300 --> 01:21:08.500 Kram, den man machen kann. 01:21:08.500 --> 01:21:11.480 Ich sage mal so, die häufigsten Sachen, die man da macht, ist halt Pick. 01:21:11.480 --> 01:21:12.600 Das ist halt der Standardfall. 01:21:12.600 --> 01:21:16.000 Dann gibt es sowas wie Reword, wenn ich die Commit-Message nochmal editieren will. 01:21:16.560 --> 01:21:20.500 Es gibt Edit, also quasi das Editieren des Commits. 01:21:20.500 --> 01:21:23.620 Da passiert nichts weiter, wie, dass der Rebase an der Stelle anhält. 01:21:23.620 --> 01:21:27.980 Und dann könntest du zum Beispiel nochmal irgendwie eine Datei ändern und mit Git-Commit-Amand, 01:21:27.980 --> 01:21:31.820 damit kannst du ja den letzten Commit, den du gemacht hast, nochmal anpassen, kannst du 01:21:31.820 --> 01:21:34.620 den nochmal ein bisschen fixen und kannst du den Log rauslöschen oder so. 01:21:34.620 --> 01:21:38.020 Und dann sagst du, Git-Rebase-Continue, dann geht es weiter. 01:21:38.020 --> 01:21:39.680 Dann kommt dann Squash. 01:21:39.680 --> 01:21:42.220 Das ist das, was du jetzt gerade vielleicht machen willst. 01:21:42.780 --> 01:21:43.960 Es gibt aber auch Fix-Up. 01:21:43.960 --> 01:21:48.300 Und Fix-Up ist nichts weiter wie Squash, nur, dass du nicht nochmal eine neue Commit-Message 01:21:48.300 --> 01:21:48.920 angeben musst. 01:21:48.920 --> 01:21:55.380 Das heißt, wenn du ohnehin die Commit-Message im ersten Commit schon passend hast und danach 01:21:55.380 --> 01:21:58.520 kommt nur noch Remove-Konsole-Log und Tests. 01:21:58.520 --> 01:22:00.560 Ja, ja, vor Gott, du Commit so und so. 01:22:00.560 --> 01:22:04.160 Ich habe auch einen Bug gefixt, den ich vorher nicht gesehen habe. 01:22:04.160 --> 01:22:06.400 Dann machst du vielleicht auch einfach einen Fix-Up. 01:22:06.400 --> 01:22:09.880 Und dann kannst du jetzt einfach hingehen in die Zeilen, die er dir oben reingeschrieben 01:22:09.880 --> 01:22:13.760 hat, vorne das Pick einfach wegmachen und dann das andere gewünschte Commando da hinschreiben. 01:22:13.760 --> 01:22:15.980 Also du kannst jetzt zum Beispiel aus allen 01:22:15.980 --> 01:22:18.080 ein F machen für Fix-Up 01:22:18.080 --> 01:22:19.260 oder Fix-Up hinschreiben. 01:22:19.260 --> 01:22:20.780 Wenn du gerne tischst. 01:22:20.780 --> 01:22:23.480 Den ersten musst du allerdings lassen, weil 01:22:23.480 --> 01:22:25.820 irgendeinen Commit müssen wir ja picken, den wir dann 01:22:25.820 --> 01:22:26.900 Ah, das ist dann der, den er 01:22:26.900 --> 01:22:28.860 Ah, jetzt habe ich schon wieder irgendwas 01:22:28.860 --> 01:22:31.580 irgendwas war jetzt gerade versaut, weil ich wahrscheinlich 01:22:31.580 --> 01:22:33.300 hier Einfügen aus Versehen aktiviert habe. 01:22:33.300 --> 01:22:35.700 Und jetzt habe ich glaube ich den Hash 01:22:35.700 --> 01:22:36.560 gerade kaputt gemacht. 01:22:36.560 --> 01:22:40.100 Solche Sachen passieren mir dann eben. 01:22:40.100 --> 01:22:47.100 Wenn man es versaut hat, der Escape-Hatch ist einfach alles löschen und Fenster schließen 01:22:47.100 --> 01:22:49.800 und dann gesagt, warte mal, da ist ja gar nichts zu tun. 01:22:49.800 --> 01:22:51.180 Okay, machen wir doch direkt mal. 01:22:53.180 --> 01:22:56.660 Man kann ich hier nicht, äh, ich kann, oh, ja, jetzt komme ich hier als, als 01:22:56.660 --> 01:22:59.080 Wimbleger, Szeniger, äh, ich kann nicht mal 01:22:59.080 --> 01:23:00.780 Steuerung A oder so, also, ähm, 01:23:00.780 --> 01:23:02.960 ihre Verbindung wird gehalten. 01:23:02.960 --> 01:23:05.000 Wenn ich übrigens sage, alles löschen, dann meine ich natürlich nur die 01:23:05.000 --> 01:23:05.640 Kommandos löschen. 01:23:05.640 --> 01:23:07.180 Also, okay, also das wäre, wäre wurscht. 01:23:07.180 --> 01:23:08.860 Okay, ich dachte, die muss dann leer sein quasi. 01:23:08.860 --> 01:23:11.220 Und jetzt würde ich, äh, 01:23:11.220 --> 01:23:12.820 so. 01:23:12.820 --> 01:23:16.620 Jetzt muss ich, äh, hier, 01:23:16.620 --> 01:23:17.720 äh, 01:23:17.720 --> 01:23:20.160 Q-Ausrufzeichen, ne, wie war es? 01:23:20.160 --> 01:23:21.020 Ausrufzeichen Q? 01:23:21.020 --> 01:23:21.200 VQ. 01:23:21.200 --> 01:23:22.300 VQ. 01:23:22.300 --> 01:23:24.500 Schreiben. 01:23:24.500 --> 01:23:26.080 Okay, jetzt machen wir das noch. 01:23:26.080 --> 01:23:27.980 Jetzt macht er nichts zu tun, sagt er an GitHub. 01:23:27.980 --> 01:23:28.360 Okay. 01:23:28.360 --> 01:23:30.300 Weil ich quasi alle Kommandos, es ist quasi, 01:23:30.300 --> 01:23:32.680 mach folgende Kommandos, ne, das ist eine Kommandoliste. 01:23:32.680 --> 01:23:36.220 Oder bei GitHub nennt sich das sogar To-Do-Liste. 01:23:36.220 --> 01:23:36.720 Ah ja. 01:23:36.720 --> 01:23:39.480 Du kannst es tatsächlich sogar auch noch editieren, wenn du schon mitten im 01:23:39.480 --> 01:23:40.380 Rebase drin bist. 01:23:40.380 --> 01:23:43.880 Kannst du dann, gibt's Rebase, Edit, To-Do, und dann kriegst du noch die 01:23:43.880 --> 01:23:46.920 restlichen Kommandos, die noch ausstehen, und kannst dann noch mal 01:23:46.920 --> 01:23:49.240 welche dabei schreiben oder doch noch mal ändern. 01:23:50.480 --> 01:23:51.780 Kannst du die wildsten Sachen machen. 01:23:51.780 --> 01:23:54.880 Jetzt hab ich hier zum Beispiel das Problem, ich kann, ich kann kein F eintippen. 01:23:54.880 --> 01:23:56.540 Warum kann ich das einfach? 01:23:56.540 --> 01:23:57.900 Kannst du erst drücken oder so, ne, zum Einfügen. 01:23:57.900 --> 01:24:01.860 Ach so, ist das, ah, ah, ah, ah, aha, okay. 01:24:01.860 --> 01:24:05.140 Also ich glaube, ich werde mir, 01:24:05.240 --> 01:24:06.800 gegen Software etwas getauscht. 01:24:06.800 --> 01:24:09.120 Ja, ich werde tatsächlich auch genau das tun. 01:24:09.120 --> 01:24:09.860 Okay. 01:24:09.860 --> 01:24:11.340 So. 01:24:11.340 --> 01:24:13.460 Und so müsste das jetzt aussehen. 01:24:13.460 --> 01:24:13.740 Genau. 01:24:13.740 --> 01:24:14.020 Ja? 01:24:14.020 --> 01:24:15.280 Ja, genau. 01:24:15.280 --> 01:24:18.140 Also was du jetzt quasi, ich hast es dann quasi in der ersten Zeit, da steht Pick, 01:24:18.140 --> 01:24:22.300 ich hab mein Feature gefixt, und darunter steht dann F oder Fix Up, 01:24:22.300 --> 01:24:29.200 Commit Hash, hab Konsole Lock gelöscht, hab noch Tests geschrieben, etc. 01:24:29.440 --> 01:24:29.620 Genau. 01:24:29.620 --> 01:24:36.580 Und dann speicherst du die Datei quasi und spendest deinen Editor und jetzt startet dann los. 01:24:36.580 --> 01:24:40.400 Und speichern mit, also schließen mit Speichern ist? 01:24:40.400 --> 01:24:41.700 WQ. 01:24:41.700 --> 01:24:42.460 Auch nochmal WQ? 01:24:42.960 --> 01:24:45.280 Ja, ich dachte, das war, ach so, ah, okay. 01:24:45.280 --> 01:24:49.120 Wir haben ja alles rausgelöscht, deswegen hat die Treebase gesagt, das ist nix. 01:24:49.120 --> 01:24:53.100 Ich guck mal kurz, wie es in SourceTree jetzt aussieht, da müsste ich ja jetzt schon sehen. 01:24:53.100 --> 01:24:54.380 Oder? 01:24:54.380 --> 01:25:03.460 Und wenn ich das jetzt, äh, nee, warte mal, kann ich das jetzt einfach pushen? 01:25:03.460 --> 01:25:03.840 Nee. 01:25:03.840 --> 01:25:06.540 Äh, ja, klar. 01:25:06.540 --> 01:25:06.920 Doch. 01:25:06.920 --> 01:25:07.620 Könntest du tun. 01:25:07.620 --> 01:25:12.500 Wenn du allerdings schon Commits von denen gepusht hast, die du jetzt weggekillt hast, 01:25:12.780 --> 01:25:15.060 dann musst du einen sogenannten Force-Push machen. 01:25:15.060 --> 01:25:20.580 Das ist das, wo alle immer sagen, Achtung, weil wenn du jetzt Force-Pushst und Commits 01:25:20.580 --> 01:25:25.480 verschwinden, die irgendein Kollege noch in seiner Historie drin hat, dann führt das halt 01:25:25.480 --> 01:25:27.640 zu Effekten, dass die wieder dann irgendwann wieder auftauchen. 01:25:27.640 --> 01:25:31.240 Also, wenn man Force-Pusht, muss man auf jeden Fall mit seinen Kollegen sprechen. 01:25:31.240 --> 01:25:32.340 Ja, okay. 01:25:32.340 --> 01:25:36.320 Und das ist auch so ein Stolperstein wieder, ich weiß nicht, woran das liegt, das müsste 01:25:36.320 --> 01:25:39.280 die neueste Source-Tree-Version sein, da ist Force-Push ausgegraut. 01:25:39.940 --> 01:25:40.920 Und ich weiß nicht, wieso. 01:25:40.920 --> 01:25:45.340 Und deswegen mache ich das dann auch immer, wenn ich irgendwas forcen muss, also manchmal 01:25:45.340 --> 01:25:47.060 auch Tags überschreiben. 01:25:48.900 --> 01:25:52.440 Dann muss ich das immer über die Command-Line machen, weil ich nicht weiß, wie das, warum das ist. 01:25:52.440 --> 01:25:53.720 Aber da geht es auch vorstanden. 01:25:53.720 --> 01:25:55.860 Genau, das funktioniert der Problem. 01:25:55.860 --> 01:25:58.800 Ich weiß nicht, was das, das muss irgendein Bug eigentlich in Source-Tree sein. 01:25:58.800 --> 01:26:01.220 Oder vielleicht kann es mir auch jemand erklären, dann gerne. 01:26:01.220 --> 01:26:05.920 Vielleicht musst du das auch mit, du musst erst den Namen des Repositories eintippen, erst 01:26:05.920 --> 01:26:06.920 anlocken oder sowas. 01:26:06.920 --> 01:26:08.640 Vielleicht, ja. 01:26:08.640 --> 01:26:10.380 Vielleicht ist das wirklich ein Sicherheitsfeed. 01:26:10.380 --> 01:26:11.120 Das kann sein, ja. 01:26:11.120 --> 01:26:15.340 Okay, und jetzt gucken wir mal in das Pull-Request. 01:26:15.340 --> 01:26:17.380 Yay! 01:26:17.380 --> 01:26:18.520 Cool. 01:26:18.520 --> 01:26:22.220 Ha, gut, dann kann ich das in Zukunft auch. 01:26:22.220 --> 01:26:27.200 Ich habe mir echt, ich habe mir schon Tutorials durchgelesen und irgendwie aus dieser Kombination 01:26:27.200 --> 01:26:32.620 an Wim und nicht so ganz wissen, was man da tut, bin ich dann echt gescheitert. 01:26:32.620 --> 01:26:34.360 Aber das freut mich jetzt, dass ich das jetzt hier bekomme. 01:26:34.360 --> 01:26:37.500 Was man da halt auch machen kann, wir hatten ja diese ganzen Pick-Kommandos, du kannst 01:26:37.500 --> 01:26:41.200 quasi auch die Reihenfolge von Commits ändern, ne, wenn du das tauschst einfach. 01:26:41.200 --> 01:26:47.240 Was da halt wichtig ist, dass du einen Commit nicht nach vorne schiebst, obwohl der auf 01:26:47.240 --> 01:26:48.600 andere Änderungen angewiesen ist. 01:26:48.600 --> 01:26:50.000 Ja, klar, sonst habe ich wieder diese ... 01:26:50.000 --> 01:26:53.140 Weil die Änderungen weg sind, weil die erst später reinkommen, ne. 01:26:53.140 --> 01:26:56.340 Das ist ganz wichtig. 01:26:57.200 --> 01:27:02.200 Das ist aber jetzt halt auch so ein Thema, an dem wir jetzt sind, wo es heißt, okay, 01:27:02.200 --> 01:27:04.580 da kannst du jetzt aber ganz schön viel falsch machen. 01:27:04.580 --> 01:27:07.960 Wenn du jetzt Commits löscht, dann verschwinden die plötzlich. 01:27:07.960 --> 01:27:11.200 Also wenn du jetzt eine Pick-Zeile löschen würdest, dann wird der nicht mehr gepickt, dann 01:27:11.200 --> 01:27:12.100 ist der weg, der Commit. 01:27:12.100 --> 01:27:18.500 Und da wird häufig dann von abgeraten, dass man es bitte nicht tun sollte, weil man viel 01:27:18.500 --> 01:27:19.360 kaputt machen kann. 01:27:19.360 --> 01:27:24.220 Aber in Git kannst du gar nicht so viel kaputt machen. 01:27:25.120 --> 01:27:29.300 Weil nur weil dein Label ja jetzt auf einen anderen Commit zeigt, heißt das noch lange 01:27:29.300 --> 01:27:30.920 nicht, dass der Commit nicht mehr da ist. 01:27:30.920 --> 01:27:39.080 Also der alte Commit, den du jetzt irgendwo reingesquasht hast, ist in der Datenbank immer 01:27:39.080 --> 01:27:39.540 noch da. 01:27:39.540 --> 01:27:46.820 Der wird erst bei so einer Garbage-Collection, die, keine Ahnung, alle zwei Wochen mal ausgeführt 01:27:46.820 --> 01:27:49.520 wird intern, wird der halt wirklich gelöscht. 01:27:49.520 --> 01:27:53.440 Und wenn du jetzt nicht mega viel Unglück hast, passiert das nicht jetzt in diesem Moment. 01:27:53.440 --> 01:27:55.060 Und das Ding ist halt noch da. 01:27:55.060 --> 01:27:58.220 Es gibt einen Befehl, der nennt sich Git RevLog. 01:27:58.220 --> 01:28:01.560 Der ist sehr hilfreich, weil RevLog ist quasi ein Log. 01:28:01.560 --> 01:28:06.220 Das zeigt dir an, wo dein Head gewesen ist. 01:28:07.280 --> 01:28:12.940 Und wenn du das jetzt bei dir ausführen würdest nach einem Rebase, dann siehst du die ganzen 01:28:12.940 --> 01:28:14.480 Sachen, die er für den Rebase gemacht hat. 01:28:14.480 --> 01:28:18.740 Und der Rebase fängt eigentlich immer mit dem Checkout an von der Zielbranche. 01:28:20.080 --> 01:28:23.480 Und wenn du jetzt den Commit da vornimmst, das ist quasi dein Stand, wie er vorher mal 01:28:23.480 --> 01:28:23.780 war. 01:28:23.780 --> 01:28:26.240 Oder dein Head war ja an diesem Punkt. 01:28:26.240 --> 01:28:27.620 Das ist quasi das, was da steht. 01:28:27.620 --> 01:28:31.760 Und jetzt könntest du zum Beispiel einfach hingehen und sagen, hey, alles war blöd. 01:28:31.760 --> 01:28:35.580 Da machst du Git Reset minus minus hart, weil du willst doch keine Änderungen behalten. 01:28:35.580 --> 01:28:39.340 Und gibst dann einfach den Commit Hash an und dann ist alles wieder so wie früher. 01:28:39.340 --> 01:28:44.540 Also es ist nicht so, dass du dich da komplett zerstörst. 01:28:44.540 --> 01:28:47.600 Cool. 01:28:48.020 --> 01:28:50.900 Das für mich ist auch nochmal so ein Ding, wo man sagt, ah, okay, wenn ich zurück 01:28:50.900 --> 01:28:53.620 kann, dann experimentiere ich auch gerne mal. 01:28:53.620 --> 01:28:58.120 Ja, das ist gut zu wissen, dass man einfach auch ein bisschen die Angst davor verliert, 01:28:58.120 --> 01:29:00.140 irgendwie was komplett zu zerstören. 01:29:00.140 --> 01:29:00.900 Genau. 01:29:00.900 --> 01:29:03.720 Ja, ich mache dann immer einen neuen Branch. 01:29:03.720 --> 01:29:04.800 Bitte? 01:29:04.800 --> 01:29:07.560 Ich schmeiße dann immer den Branch weg und mache nochmal neu. 01:29:07.560 --> 01:29:08.620 Ja, klar. 01:29:08.620 --> 01:29:11.620 Es ist halt blöd, wenn man das Pull-Request schon gestellt hat. 01:29:11.620 --> 01:29:13.080 Ja, es geht, ja, sowieso. 01:29:13.080 --> 01:29:17.920 Und das geht auch nicht immer, das ist dann manchmal eklig und dann speichere ich Changes irgendwo 01:29:17.920 --> 01:29:19.060 in einem anderen Editor und so. 01:29:19.060 --> 01:29:19.580 Das ist alles. 01:29:19.580 --> 01:29:23.960 Also empfehlen kann ich das nicht, aber das ist so the last resort bei mir. 01:29:23.960 --> 01:29:29.240 Ich glaube, wenn man sich ein bisschen tiefer auskennt im Git, dann muss man das vielleicht 01:29:29.240 --> 01:29:29.500 nicht. 01:29:29.500 --> 01:29:31.700 Deswegen, ich gelobe Besserung. 01:29:32.480 --> 01:29:39.260 Ja, aber zum Schluss zählt nur das Ergebnis, dass die richtigen Commits bei deinen Kollegen 01:29:39.260 --> 01:29:43.220 landen oder im Master Branch, damit das Projekt deployed werden kann. 01:29:43.220 --> 01:29:48.860 Wenn sie dann noch schön und aufgeräumt sind, das ist dann nochmal das Sternchen. 01:29:50.740 --> 01:29:54.460 Führt mich zu dem Punkt, wofür wir diesen ganzen Bums überhaupt machen. 01:29:54.460 --> 01:29:57.960 Wofür machen wir Versionsverwaltung eigentlich? 01:29:57.960 --> 01:30:00.780 Ich glaube, viele sehen das so als so ein Backup. 01:30:00.780 --> 01:30:02.500 Hey, das ist ein Backup, falls mal was schief geht. 01:30:02.500 --> 01:30:03.820 Aber eigentlich ist es ja viel mehr. 01:30:03.880 --> 01:30:09.600 Dokumentiere damit ja quasi die Geschichte unseres Projekts von der Software. 01:30:09.600 --> 01:30:11.860 Wie hat sich das entwickelt? 01:30:11.860 --> 01:30:13.100 Warum ist das so, wie es ist? 01:30:13.100 --> 01:30:15.700 Warum hat der das dahin gebaut? 01:30:15.700 --> 01:30:17.900 Und nicht anders. 01:30:19.340 --> 01:30:24.540 Da ist es halt wichtig, in meinen Augen wirklich zu gucken, dass auch die Historie halt sauber 01:30:24.540 --> 01:30:24.800 ist. 01:30:24.800 --> 01:30:26.940 Weil wenn sie sauber ist, kann man das auch gut nachvollziehen. 01:30:26.940 --> 01:30:31.580 Wenn ihr zum Beispiel Git-Blancen, wie ihr das Code nutzt, ist es cool, wenn da ein 01:30:31.580 --> 01:30:35.760 sinnvoller Commit-Summer steht und nicht nur Fixed-Bug. 01:30:35.760 --> 01:30:36.680 Ja, klar. 01:30:36.680 --> 01:30:40.420 Wenn du das jetzt zwar ja, dann wurde ein Bug gefixt, aber du weißt nicht, welcher. 01:30:40.420 --> 01:30:44.620 Was macht so eine gute Commit-Message aus? 01:30:44.620 --> 01:30:47.580 Ja, erzähl doch mal. 01:30:47.580 --> 01:30:49.140 Was du so verbreitet hast? 01:30:49.140 --> 01:30:52.320 Witzigerweise habe ich das jetzt, ich habe es jetzt gerade aufgeschrieben als Thema. 01:30:52.320 --> 01:30:54.920 Super, dann sprechen wir einfach gleich drüber. 01:30:54.920 --> 01:30:56.800 Was macht eine gute Commit-Message aus? 01:30:56.800 --> 01:31:00.560 Naja, also ich kann ja mal sagen, wie wir das bei uns machen. 01:31:00.560 --> 01:31:06.440 Oder ich weiß nicht, ob wir super diszipliniert sind an der Stelle, ob jede Commit-Message 01:31:06.440 --> 01:31:08.620 genauso aussieht, ob die immer dem Schema folgt. 01:31:08.620 --> 01:31:13.980 Aber wir schreiben die so, also wir schreiben an den Anfang der Commit-Message eigentlich immer 01:31:13.980 --> 01:31:16.880 die Ticket-Nummer, was für ein Ticket wir bearbeiten. 01:31:17.480 --> 01:31:23.000 Und wenn man ein cooles Tool hat, wie zum Beispiel Bitbucket oder GitLab, dann kann das auch 01:31:23.000 --> 01:31:26.520 direkt dann zu dem Ticket verlinken. 01:31:26.520 --> 01:31:29.740 Und dann bin ich von dem Ticket nur einen Klick entfernt. 01:31:29.740 --> 01:31:30.660 Also irgendwie Ticket-Nummer. 01:31:30.660 --> 01:31:36.540 Und dann beginne ich normalerweise mit einem Verb und sage halt, was habe ich denn gemacht? 01:31:36.540 --> 01:31:43.000 Also fix oder, keine Ahnung, add oder remove und so weiter. 01:31:43.000 --> 01:31:45.780 Also für uns da auch schon diese imperative Stimmung quasi. 01:31:45.780 --> 01:31:50.740 Irgendjemand hat mal gesagt, ich soll das so machen in der Vergangenheit. 01:31:50.740 --> 01:31:52.960 Ich weiß gar nicht mehr genau, wie ich dazu kam. 01:31:52.960 --> 01:31:57.460 Aber es gibt da ja tatsächlich einige Artikel im Netz, die einem genau die Grammatik vorgeben, 01:31:57.460 --> 01:31:59.120 wie so eine Commit-Message auszusehen hat. 01:31:59.120 --> 01:32:05.640 Ich weiß jetzt nicht, ob wir uns so streng daran halten, aber das hilft durchaus, wenn man sich an so ein gewisses Schema hält. 01:32:05.700 --> 01:32:08.000 Dann kann man auch sehr schnell erkennen, was hat der andere da gemacht. 01:32:08.000 --> 01:32:14.500 Und ja, es gibt bei mir aber auch Commit-Messages, die heißen einfach nur fix oder ha, ha, ha, wer das liest, ist doof. 01:32:14.500 --> 01:32:22.720 Ich meine, gerade wenn man so mitten in der Entwicklung von einem Feature ist und man eigentlich nur so einen Zwischenstand mal abspeichern will, 01:32:22.720 --> 01:32:27.200 bevor man in den Feierabend geht und man gar nicht so genau sagen kann, was man da jetzt gemacht hat, 01:32:27.200 --> 01:32:30.820 dann sind die auch nicht immer so aussagekräftig, bin ich ganz ehrlich. 01:32:30.820 --> 01:32:33.860 Weil die heißen dann auch immer WIP für Work and Progress. 01:32:33.860 --> 01:32:40.720 Weil das kann man einfach Gitcommit-M, WIP, damit brauche ich nicht mal, dass der Editor aufgeht, einfach raus damit. 01:32:40.720 --> 01:32:44.480 Aber jetzt, Moritz, jetzt weißt du, dass du das fix abbenutzen kannst, um das ... 01:32:44.480 --> 01:32:54.960 Und wie ich auch gelernt habe, ist WIP kennt GitLab offenbar auch und kann da und triggert dann keine neuen, also Pipelines oder irgendwie sowas. 01:32:54.960 --> 01:32:56.680 Irgendwie sowas gibt es da. 01:32:56.680 --> 01:33:02.400 Also wenn man GitLab verwendet, wir sind jetzt gerade dabei, darauf umzusteigen, habe ich jetzt gerade heute gehört, 01:33:02.540 --> 01:33:08.100 dass das irgendwie, wenn man WIP davor schreibt, dass er dann, glaube ich, dass das dann darauf reagieren kann und sagen kann, 01:33:08.100 --> 01:33:12.120 hey, dann triggere ich die Pipeline nicht, weil das ist ja dann Inno-Work-in-Progress, interessiert mich nicht. 01:33:12.120 --> 01:33:19.500 Es gibt ja auch, je nach Buildchain, wird dann der Change-Log entsprechend gefüttert, je nachdem, was da für Verben drinstehen. 01:33:19.920 --> 01:33:23.720 Wird das dann irgendwie gruppiert nach Fix und nach Features und so. 01:33:23.720 --> 01:33:28.720 Deswegen ist natürlich, wenn man sowas nutzt, muss man sich natürlich auch was auf ein System einigen. 01:33:28.720 --> 01:33:35.480 Ja, was sich da durchgesetzt hat, ist dieses Semantic Release nennt sich das, beziehungsweise das setzt auf etwas auf, was sich Conventional Commits schimpft. 01:33:36.480 --> 01:33:41.400 Dass man halt so eine Konvention einhält, dass man zum Beispiel mit Fix-Doppelpunkt anfängt, wenn man was gefixt hat. 01:33:41.400 --> 01:33:44.940 Oder mit Feed-for-Feature-Doppelpunkt, wenn man ein neues Feature einbaut. 01:33:46.360 --> 01:33:51.100 Oder halt unten im Code sowas sagt wie, Achtung, das ist ein Fat-Breaking-Change. 01:33:51.100 --> 01:33:58.160 Weil dann kann zum Beispiel deine Pipeline hingehen und automatisch Releases davon erstellen, nach dem Semantic-Versioning. 01:33:58.160 --> 01:34:08.800 Also, dass du wirklich weißt, muss ich jetzt hinten den Patch-Release hochzählen oder muss ich einen Feature, wie heißt das, Minor-Release hochzählen, die Minor-Version. 01:34:09.620 --> 01:34:14.560 Weil der halt einfach die Commit-Messages durchgehen kann und der weiß halt, wenn da Fix steht, wurde im Bug gefixt. 01:34:14.560 --> 01:34:17.660 Und damit kann man halt sehr viel automatisieren. 01:34:17.660 --> 01:34:24.240 Gerade mal geschaut hier, conventionalcommits.org, da wird das ein bisschen beschrieben. 01:34:24.240 --> 01:34:26.060 Würdest du das empfehlen, setzt ihr das bei euch ein? 01:34:26.060 --> 01:34:30.560 Wir setzen das mittlerweile sehr häufig bei uns ein in Projekten. 01:34:30.560 --> 01:34:38.140 Also wir haben auch mittlerweile einige Pipelines, die halt wirklich dann die Releases einfach raushauen, sobald was im Master ist. 01:34:38.620 --> 01:34:42.160 Und da setzen wir das dann halt ein, um zu entscheiden, was für eine Versionsnummer gemacht wird. 01:34:42.160 --> 01:34:45.080 Ah, cool. Also komplett automatisiert dann. 01:34:45.080 --> 01:34:54.060 Ja, aber es ist nicht immer komplett automatisierbar, weil du das vielleicht dann doch nicht auf Produktion schieben möchtest, weil der Kunde vielleicht auch nochmal drüber gucken möchte. 01:34:54.060 --> 01:34:58.780 Aber wir sind zumindest so weit, dass wir dann einen Release gemacht haben, das deployen wir dann auf Staging. 01:34:58.780 --> 01:35:04.360 Und wenn das dann freigegeben ist, kann das Release dann auf Produktion deployed werden. 01:35:05.660 --> 01:35:11.600 Aber ihr habt da gute Erfahrungen mitgemacht mit dem conventionalcommits, weil das sieht jetzt ein bisschen anders aus, als das, was ich so kannte. 01:35:12.120 --> 01:35:18.620 Aber es sieht durchaus sinnvoll aus, gerade wenn man so automatisiert bestimmte Dinge tun will, wie du gerade gesagt hast. 01:35:18.620 --> 01:35:20.160 Bestimmte Versionsnummern hochzählen. 01:35:20.160 --> 01:35:25.280 Bei Breaking Changes wird es dann wahrscheinlich mindestens eine Minor-Version oder Major, ich weiß es gar nicht genau. 01:35:25.280 --> 01:35:26.920 Genau, in Breaking Change machst du das Major-Version. 01:35:26.920 --> 01:35:28.060 Eine Major-Version. 01:35:28.060 --> 01:35:30.340 Kommt bestimmt aber auch nochmal darauf an, wie du es dir konfigurierst. 01:35:30.580 --> 01:35:35.280 Das ist ja letztendlich auch eine Toolchain-Geschichte, wie du es dann nutzt. 01:35:35.280 --> 01:35:41.600 Habt ihr da Tools, die einen dran hindern, eine falsche, in Anführungsstrichen, Commit-Message zu schreiben? 01:35:41.600 --> 01:35:43.900 Oder also die irgendwie das prüfen? 01:35:43.900 --> 01:35:46.080 Okay, also man kann auch quatschen. 01:35:46.080 --> 01:35:47.900 Also Husky zum Beispiel, damit kannst du es lösen. 01:35:47.900 --> 01:35:51.360 Husky ist ja so ein Commit-Hook-Ding auf JavaScript-Basis. 01:35:51.960 --> 01:35:55.720 Da kannst du das checken, setzen wir aber noch nicht ein. 01:35:55.720 --> 01:36:06.680 Also vielleicht mal, weil es, ja, es gehen auch manchmal so ein paar Sachen schief, dass dann man vielleicht fix geschrieben hat, obwohl es ein Feature ist. 01:36:06.680 --> 01:36:07.680 Oder umgekehrt. 01:36:07.680 --> 01:36:13.160 Und dann passiert halt ein falsches Release, was man nicht möchte. 01:36:13.160 --> 01:36:15.880 Ah, Husky, könnte ich auch noch nicht. 01:36:15.880 --> 01:36:17.680 Mensch, wir lernen noch so viel. 01:36:17.680 --> 01:36:21.100 Ja, ich führe auch so ein bisschen Buch gerade. 01:36:21.300 --> 01:36:22.380 Nur, dass du Bescheid weißt. 01:36:22.380 --> 01:36:26.680 Haben wir vielleicht Doppelungen am Ende, aber macht nichts. 01:36:26.680 --> 01:36:29.240 Wir sind auch bei der Commit-Message stehen geblieben. 01:36:29.240 --> 01:36:29.960 Genau. 01:36:29.960 --> 01:36:37.140 Ja, das mit dem Verb, imperative Stimmung oder wie man es nennen möchte, hat sich durchgesetzt. 01:36:37.140 --> 01:36:40.860 Also bei mir im Kopf kommt immer so ein This Commit will... 01:36:40.860 --> 01:36:45.100 Und dann geht es auf der Tastatur weiter, Add, was auch immer. 01:36:45.100 --> 01:36:50.300 Das ist so meine Gedankenstütze, die ich mir immer mache, damit ich das dann halt richtig formuliere. 01:36:50.640 --> 01:37:07.660 Was ich aber halt auch wichtig finde ist, also man spricht ja bei dieser ersten Zeile von der sogenannten Summary und wenn man freundlich zu Leuten ist, die Terminals benutzen, die nur 80 Zeichen bereit sind, dann guckt man, dass man sich auf 80 Zeichen beschränkt. 01:37:08.020 --> 01:37:14.140 Da wird es dann mit Ticketnummern davor schon wieder eng, weil die nehmen dann irgendwie einen wertvollen Platz weg. 01:37:14.220 --> 01:37:27.020 Und das ist dann auch die Commit-Geschichte, da denke ich manchmal so, hey, zähle ich jetzt 80 nach dem Fix-Doppelpunkt oder von ganz vorne, dann fängt man dann doch an, ein bisschen das aufzuweichen. 01:37:27.740 --> 01:37:41.720 Aber wie es Code hilft einem da ganz gut, das sagt nämlich Bescheid, ich weiß nicht genau, ob das jetzt genau 80 Zeichen zählt, aber ab einer gewissen Zeichenanzahl sagt es, hey, wenn du jetzt noch weiterschreibst, dann musst du zumindest mal in die nächste Zeile gehen, sonst wird das zu lang. 01:37:42.520 --> 01:37:45.360 Also ich könnte mir vorstellen, dass das in die ähnliche Richtung zielt. 01:37:45.360 --> 01:37:49.240 Bist du dir denn sicher, dass das dann noch als Summary gewertet wird? 01:37:49.240 --> 01:37:51.740 Das weiß ich nicht, ehrlich gesagt. 01:37:51.740 --> 01:38:03.500 Also dieses Format, was sich da so ein bisschen durchgesetzt hat, ist ja, dass du eine Zeile schreibst mit einer Summary, dann lässt du eine Leerzeile und darunter schreibst du dann eine ausführliche Beschreibung, warum du das gemacht hast. 01:38:05.820 --> 01:38:15.840 Warum du den Bug auf die Art und Weise löst, weil, ich sag mal, was ich gemacht habe, das kann ich auch sehen, wenn ich einen Diff auf der Summary machen, dann sehe ich, was du geändert hast. 01:38:15.840 --> 01:38:18.740 Aber manchmal ist auch die Frage, warum hast du es genau so geändert? 01:38:18.740 --> 01:38:19.860 Gibt es dann einen Grund für? 01:38:19.860 --> 01:38:29.380 Dann wäre es cool, wenn du den reinschreibst, damit der nächste, der das vielleicht dann wieder ändern wird, weiß, dass das bitte nicht umbaut auf eine andere Variante, mit der du schon gescheitert bist. 01:38:29.380 --> 01:38:32.320 Und dann quasi die gleichen Fehler nochmal wiederholt. 01:38:32.320 --> 01:38:39.220 Deswegen ist es ganz cool, wenn man da dann so eine Beschreibung macht und GitHub zum Beispiel oder auch GitLab, die verstehen das quasi. 01:38:39.220 --> 01:38:44.140 Die können die Commit Message entsprechend zerlegen und im Log zeigen die zum Beispiel nur dieses Summary an. 01:38:44.140 --> 01:38:48.340 Und in der Detailansicht siehst du dann auch diese Description. 01:38:48.340 --> 01:38:51.620 Und ich glaube, die kann dann sogar marktortformatiert sein, wenn ich mich nicht irre. 01:38:51.620 --> 01:38:57.760 Also da kann man sich in der Theorie, wenn man sich die Zeit nehmen möchte, kann man sich da richtig auslassen. 01:38:58.460 --> 01:39:07.280 Das ist interessant, so eine Information über dieses Warum und mit welchen Lösungen ich schon gescheitert bin, würde ich jetzt tatsächlich in den Code als Kommentar reinschreiben. 01:39:07.280 --> 01:39:10.420 Aber es in die Commit Message zu packen, ist auch ein interessanter Ansatz. 01:39:10.420 --> 01:39:15.200 Wäre nur mir vielleicht ein bisschen zu versteckt, dann tatsächlich beim einen oder anderen. 01:39:15.200 --> 01:39:17.480 Das ist, glaube ich, gut, wenn es direkt beim Code dabei steht. 01:39:18.160 --> 01:39:21.760 Ja, das ist auch wieder, ja, Ansichtssache. 01:39:21.760 --> 01:39:29.740 Also ich weiß gar nicht, ob ich überhaupt noch Kommentare in meinem Code habe, die nicht ESLint sagen, dass er da jetzt mal bitte nicht meckern soll. 01:39:29.740 --> 01:39:37.980 Also ich persönlich finde immer so, Code dokumentiert sich selbst ganz gut, wenn du von einem Fliegelfunktionsnamen machst, ganz schön aufreißt. 01:39:37.980 --> 01:39:46.900 Ja, manchmal macht es dann wahrscheinlich Sinn zu sagen, hier bitte das nicht löschen, sonst geht es kaputt. 01:39:46.900 --> 01:39:47.800 Und ich weiß nicht warum. 01:39:49.380 --> 01:39:50.840 Haben wir ja alle schon getragen. 01:39:50.840 --> 01:40:08.820 Ja, dieser Klassiker, was irgendwie vor einigen Jahren mal durchs Web ging, irgendwie so mit so einer Strichliste, wie viele Leute jetzt schon, also hier so bitte nicht anfassen, das versteht außer dem Autor keiner mehr und der ist schon lange nicht mehr im Unternehmen und dann so eine Strichliste, wie viele Leute es schon angefasst haben und daran gescheitert sind. 01:40:11.940 --> 01:40:12.640 Ja, genau. 01:40:12.640 --> 01:40:23.920 Ja, ich mache mir halt immer so den Gedanken, wenn jetzt jemand GitBlame verwenden würde, oder halt GitLens macht ja auch nichts anderes, bringt ihm das weiter, was ich hier schreibe. 01:40:23.920 --> 01:40:27.040 Das ist so, was ich mich dann so frage, wenn ich einen Commit mache. 01:40:27.040 --> 01:40:33.760 Und was ich dann halt versuche, ist keine überflüssigen Commits zu machen. 01:40:33.760 --> 01:40:41.800 Also wenn ich irgendeine Änderung mache, die ich zwei Commits später wieder rausschmeiße oder an Console.log rauslösche, was ich vergessen habe. 01:40:41.940 --> 01:40:49.860 Das sind so die Sachen, wo ich dann sage, hey, da habe ich auch mich selbst in Anspruch, das einfach dann mit einem Fix-Up dann zu beheben direkt. 01:40:49.860 --> 01:40:56.080 Also der Commit, der nachher in dem Projekt landet, schon gar kein Console.log mehr drin hat. 01:40:56.080 --> 01:41:01.280 Oder die Tests direkt mit in der Commit sind, der auch den Code einführt, der getestet wird. 01:41:01.280 --> 01:41:05.660 Also jetzt, wo ich weiß, wie das funktioniert, werde ich das mit Sicherheit auch sehr oft nutzen in Zukunft. 01:41:05.660 --> 01:41:09.300 Da bin ich dir echt dankbar, dass dieses Mysterium für mich jetzt gelöst ist. 01:41:09.660 --> 01:41:15.300 Was auch ganz praktisch ist, das praktizieren wir bei uns sehr häufig, das sind die sogenannten Fix-Up-Commits. 01:41:15.300 --> 01:41:20.760 Du kannst sagen, git commit – fix up und dann den Hash von dem Commit, den du fix upen möchtest. 01:41:20.760 --> 01:41:23.080 Was der dann macht, ist erstmal nur ein Commit. 01:41:23.080 --> 01:41:31.360 Der hat einen speziellen Namen, der fängt nämlich dann mit Fix-Up-Ausrufezeichen an und dann kommt die Message von dem Commit, den du gerne fix upen möchtest. 01:41:31.420 --> 01:41:37.060 Aber es ist erstmal nur ein Commit. Den kannst du pushen, dann hast du nichts gerebased, hackst deine Kollegen nicht ab, etc. 01:41:37.060 --> 01:41:42.360 Und dann kannst du zum Schluss hingehen und sagen, okay, du gehst jetzt hin und hast ein Get-Rebase-i, um aufzuräumen. 01:41:42.360 --> 01:41:51.320 Und der Parameter Auto-Squash geht dann hin und findet alle Fix-Ups und sortiert die direkt in die richtige Reihenfolge und schreibt vorne das F dran, für den Fix-Up zu machen. 01:41:51.320 --> 01:41:54.700 Und da werden die quasi alle in ihr Ziel-Commit erst dann reingestampft. 01:41:55.820 --> 01:42:01.660 Somit kannst du diesen Prozess des Rebase, der potenziell Kollegen abhängen kann, weit nach hinten schieben. 01:42:01.660 --> 01:42:15.240 Disclaimer, um zu weit nach hinten schiebst, desto höher ist natürlich wieder die Vakantität, desto auf Änderungen basierst die, weil du änderst ja dann die Reihenfolge, nicht das Einsortieren der Fix-Ups, dass das dann auch mal nach hinten losgehen kann. 01:42:15.240 --> 01:42:19.580 Aber gerade für so einen Konzonen-Lock-Löschen und so, funktioniert das super. 01:42:19.580 --> 01:42:21.260 Cool. 01:42:21.260 --> 01:42:22.780 Genau. 01:42:22.780 --> 01:42:25.420 Oh Gott. 01:42:25.820 --> 01:42:32.580 Ich muss gerade lachen. Ich habe gerade nochmal nach diesem Kommentar gegoogelt, den ich dann auch in Erinnerung hatte. Ich glaube, ich habe ihn gefunden. 01:42:32.580 --> 01:42:43.860 Dear Maintainer, once you are done trying to optimize this routine and have realized what a terrible mistake that was, please increment the following counter as a warning to the next guy. 01:42:43.860 --> 01:42:47.360 Und dann steht da, total hours wasted here, 42. 01:42:54.740 --> 01:43:04.500 Nach so einer Validierung, die ich mir ja immer so ein bisschen mitnehme, kann ich hingehen und einen zufälligen Commit-Name ihn auschecken und ist das Projekt dann lauffähig. 01:43:04.500 --> 01:43:09.600 Wisst ihr, was ich meine? 01:43:09.600 --> 01:43:10.900 Nee. 01:43:10.900 --> 01:43:12.260 Das wegt die Stille. 01:43:13.100 --> 01:43:20.820 Ja, du guckst dir dein Instagram an, ja, pickst zufällig irgendeinen Commit-Hash und funktioniert das Projekt dann. 01:43:20.820 --> 01:43:24.060 Also wenn du zum Beispiel deine Tests laufen lässt, laufen die durch. 01:43:24.060 --> 01:43:24.340 Mhm. 01:43:24.340 --> 01:43:28.880 Oder scheitern die, weil später erst ein Commit kommt, der die Tests anpasst oder so. 01:43:28.880 --> 01:43:29.460 Okay. 01:43:31.460 --> 01:43:39.060 Also das ist für dich dann quasi so die, um herauszufinden, ob du ein Fix abmachen solltest, weil das an sich alleine keinen Sinn macht, der Commit, oder? 01:43:39.060 --> 01:43:43.200 Ähm, quasi, ja. 01:43:43.200 --> 01:43:43.540 Okay. 01:43:43.540 --> 01:43:44.360 Genau. 01:43:44.880 --> 01:43:53.340 Was ich halt auch wichtig finde, oder was mir hilft, mir und meinen Kollegen ist, zu überlegen, was mache ich gerade für eine Änderung. 01:43:53.340 --> 01:44:04.680 Ich sag mal, wir kennen das ja alle, wir wollen ein Feature irgendwo einbauen und stellen fest, ja, das geht ja gar nicht, weil die Voraussetzung nicht geschaffen ist, dass ich da, keine Ahnung, was einbauen kann. 01:44:05.020 --> 01:44:10.780 Und dann fängst du an, erst mal Teile deiner App umzubauen, um dann das neue Feature einbauen zu können, ne? 01:44:10.780 --> 01:44:23.360 Und da gehe ich eigentlich ganz gerne hin und mache dann erst mal einen Refactor-Commit, der erst mal die App erweitert, also die Funktion bleibt dieselbe, aber die App ist jetzt in der Lage, das neue Feature aufzunehmen. 01:44:23.360 --> 01:44:26.240 Und dann mache ich einen zweiten Commit, der dann das neue Feature einführt. 01:44:26.240 --> 01:44:26.820 Okay. 01:44:26.820 --> 01:44:29.020 Hatte ich genau heute diesen Fall, ja. 01:44:29.020 --> 01:44:29.880 Interessant, ja. 01:44:29.880 --> 01:44:38.560 Ich sag mal, im besten Fall braucht halt ein Kollege, der an demselben Feature vielleicht arbeitet oder vielleicht sogar an einem anderen Feature arbeitet, auch genau diese Änderung. 01:44:38.560 --> 01:44:44.320 Und dann kann er einfach hingehen, git cherrypick nimmt sich diesen Commit und alle sind glücklich. 01:44:44.320 --> 01:44:59.000 Wenn du das alles in einen fetten Commit reinmachst, hast du erst mal das Problem, dass du Merch-Konflikte kriegen kannst, vermehrt, weil du halt umso mehr Änderungen du in einem Commit hast, desto höher ist die Wahrscheinlichkeit, dass der Konflikte kann durch Kollegen, 01:44:59.000 --> 01:45:00.460 Änderungen meiner Kollegen. 01:45:00.460 --> 01:45:06.360 Ja, und du hast halt voneinander isoliert. 01:45:06.360 --> 01:45:09.280 Das finde ich immer sehr praktisch. 01:45:09.280 --> 01:45:11.720 Ja, auf jeden Fall. 01:45:11.720 --> 01:45:14.820 Unsere Checkliste lichtet sich. 01:45:14.820 --> 01:45:18.580 Da habe ich noch... 01:45:18.580 --> 01:45:18.980 Ja, sagen wir mal noch. 01:45:18.980 --> 01:45:20.600 Ja, als nächsten Punkt hier. 01:45:20.600 --> 01:45:23.080 Das gehört eigentlich in einen eigenen Commit. 01:45:23.080 --> 01:45:28.480 Das war sowas, was aufkam bei uns im Vorgespräch und wie man das dann nachträglich anstellen würde. 01:45:28.840 --> 01:45:30.540 Und fixe das Ding jetzt wieder auseinander. 01:45:30.540 --> 01:45:36.520 Genau, also quasi der umgekehrte Fall von dem Squashen, sondern jetzt habe ich das eingecheckt und eigentlich stelle ich fest eben sowas, was du jetzt gesagt hast. 01:45:36.520 --> 01:45:39.780 Jetzt habe ich dann diesen Batzen eingecheckt und stelle eigentlich fest, das war jetzt blöd. 01:45:39.780 --> 01:45:41.320 Was mache ich denn dann? 01:45:41.960 --> 01:45:47.060 Ja, also wahrscheinlich gibt es 20 Lösungen, die das fixen. 01:45:47.060 --> 01:45:51.300 Meine Standardlösung ist da mal wieder der interaktive Rebase. 01:45:51.780 --> 01:45:55.040 Dann gehe ich an den Commit, der aufgeteilt werden soll, mache dann ein E dran für Edit. 01:45:55.040 --> 01:45:59.700 Dann geht Rebase hin, spult bis zu diesem Commit, bleibt dann stehen und ich bin auf der Kommandozeile. 01:45:59.700 --> 01:46:05.880 Und dann gehe ich hin, ich habe es eben schon mal erwähnt, ich mache ein Git Reset und setze mich ein Commit weiter zurück. 01:46:07.060 --> 01:46:16.760 Aber dann halt mit dem Standardverhalten, Minus Minus Mixed, der dann die ganzen Änderungen bei mir in meinen Working Directory legt. 01:46:17.280 --> 01:46:25.300 Und dann kann ich hingehen und kann dann die Sachen einzeln adden und dann den ersten Commit machen und dann adde ich den Rest und mache dann den zweiten. 01:46:25.300 --> 01:46:33.500 Man kann dann hingehen und sagen, ja, aber ich will ja doch die Commit Message behalten, weil das habe eigentlich nicht ich committet, sondern der Moritz. 01:46:33.500 --> 01:46:37.640 Und da soll jetzt nicht Michael dran stehen, weil ich möchte den Credit dem Moritz aber lassen. 01:46:38.340 --> 01:46:53.080 Dann kannst du mit Git Commit Minus Minus Reuse Message quasi den ursprünglichen Hash angeben und dann ist die ursprüngliche Message wieder drin, der Autor, das Datum, quasi eigentlich alles, was du so brauchst. 01:46:53.080 --> 01:46:59.000 Und ja, wenn man es so hart sehen möchte. 01:46:59.000 --> 01:47:01.740 Cool. 01:47:02.440 --> 01:47:13.620 Was auch sehr hilfreich ist, ich weiß nicht, wir haben es noch nicht erwähnt, du hast ja häufig das Ding, hey, die Sachen sollen in getrennte Commits, aber die sind beide in einer Datei. 01:47:13.620 --> 01:47:21.620 Ich sage mal, so GUIs, wie jetzt zum Beispiel auch GitHub Desktop, da hast du ja die Möglichkeit, so Dateien zu markieren, die Zeilen zu markieren, die du committen möchtest. 01:47:21.620 --> 01:47:24.000 Das ist natürlich auf der Konsole schwierig. 01:47:24.820 --> 01:47:30.820 Was da existiert, ist ein Modus, der nennt sich Patch für Git Add. 01:47:30.820 --> 01:47:33.940 Also du kannst sagen, Git Add minus P steht für Patch. 01:47:33.940 --> 01:47:41.940 Und was dann passiert, ist, dass quasi so ein interaktiver Client quasi aufgeht in deiner Kommandozeile, wo du jeden einzelnen Hang quasi siehst. 01:47:41.940 --> 01:47:47.680 Und kannst dann immer mit Y und N entscheiden, möchte ich den adden oder möchte ich ihn nicht adden. 01:47:47.680 --> 01:47:51.060 Und kannst dann so halt Teile der Datei auch adden. 01:47:51.060 --> 01:48:01.680 Im Endeffekt, die GUIs basieren wahrscheinlich darauf, nehme ich mal an, dass die sich halt das da raussaugen, anstatt da eigene Algorithmen, also über die Diffs darüber zu gehen. 01:48:01.680 --> 01:48:03.220 Könnte ich mir jetzt vorstellen. 01:48:03.220 --> 01:48:09.400 Wahrscheinlich, aber letztendlich ist es ja auch nur das Hinzufügen eines neuen Lobobjekts. 01:48:10.280 --> 01:48:21.340 Und ich sage mal, wenn du schon so einen GUI-Client hast, ich sage mal, dann die Hälfte eines Textes über einen anderen Text drüber zu kopieren und das zu adden, ist wahrscheinlich dann auch nicht mehr die Schwierigkeit. 01:48:21.560 --> 01:48:26.080 Ich weiß nicht, ob die jetzt git-add-p intern ausführen, könnte ich dir nicht sagen. 01:48:26.080 --> 01:48:31.360 Aber das nutze ich zum Beispiel auch sehr häufig, dass ich dann nur gewisse Sachen adde. 01:48:31.360 --> 01:48:39.520 Also zum Beispiel so, du baust irgendwie eine Methode ein und siehst 15 Zeilen weiter oben, hier ist ja der Code-Style gar nicht eingehalten. 01:48:39.520 --> 01:48:44.220 Das ist so für mich der Klassiker, wo ich dann einfach nur einen Commit mache, fix Code-Style. 01:48:44.860 --> 01:48:47.540 Und dann kommt aber der eigentliche Commit, der dann das neue Feature einbringt. 01:48:47.540 --> 01:48:50.060 Okay. 01:48:50.060 --> 01:48:54.680 Gehen wir noch einen Schritt weiter in der Liste oder hast du noch was dazu, Michael? 01:48:54.680 --> 01:49:08.780 Nee, ich wollte nur gerade nochmal darauf eingehen, ist es jetzt, sieht man es jetzt zu genau, wenn ich jetzt sage, hey, den Code-Style fix, den kommite ich jetzt einfach mit dem Feature mit. 01:49:08.780 --> 01:49:09.900 Was soll's, ne? 01:49:09.900 --> 01:49:11.900 Das ist nur die eine Zeile, die ich ändere. 01:49:12.580 --> 01:49:19.040 Was man sich da vor Augen führen muss, ist, wenn einer genau diese Zeile nachher blämt, steht dann da, hey, ich habe ein neues Feature implementiert. 01:49:19.040 --> 01:49:22.000 Obwohl diese Zeile mit diesem neuen Feature gar nichts zu tun hat. 01:49:22.000 --> 01:49:28.540 Und da finde ich es einfach besser, wenn er auch einfach nur da steht, Code-Style fix, weil dann weißt du, okay, ich muss noch weiter zurück in die Historie. 01:49:28.540 --> 01:49:31.440 Ja, das habe ich schon öfter gehabt. 01:49:31.440 --> 01:49:33.140 Und mich nicht wundern, was hat denn das mit diesem Feature zu tun? 01:49:33.140 --> 01:49:33.480 Ja, genau. 01:49:33.480 --> 01:49:40.720 Ja, sollen wir noch einen Punkt aus der Liste angehen? 01:49:40.720 --> 01:49:44.020 Ich glaube, wir haben noch was, wir haben noch zwei Sachen. 01:49:44.020 --> 01:49:49.760 Eine Sache, die sich so ein bisschen mit Organisation auch beschäftigt, war die Frage, die kam auch über Twitter. 01:49:49.760 --> 01:49:57.200 Wie stellt man ein alteingesessenes Team von einem File-Checkout-Check-In-Prozess auf einen Branch-Git-basierten Prozess um? 01:49:58.020 --> 01:50:04.640 Wo ich halt auch so erstmal dachte, das ist eigentlich ein Organisationsproblem und gar kein Git-Problem. 01:50:04.640 --> 01:50:08.740 Aber vielleicht können wir ja trotzdem kurz mal drüber reden. 01:50:08.740 --> 01:50:17.100 Also wie würdest du jetzt Git in einem Team einführen, das vorher was komplett anderes verwendet hat, um Versionsverwaltung zu machen? 01:50:17.100 --> 01:50:20.080 Vielleicht können wir uns so der Frage ein bisschen nähern. 01:50:20.080 --> 01:50:22.000 Also keine Ahnung, die machen halt vorher. 01:50:22.000 --> 01:50:24.020 Wurde das hier angegeben? 01:50:24.020 --> 01:50:25.780 Surround-SCM? 01:50:25.780 --> 01:50:27.100 Kenne ich nicht. 01:50:27.100 --> 01:50:28.860 Habe ich auch noch nie gehört. 01:50:28.860 --> 01:50:32.080 Ich kenne nur sonst SVN. 01:50:32.080 --> 01:50:33.120 Ja, genau. 01:50:33.120 --> 01:50:37.440 Wie die meisten, die bei Git gelandet sind, die kamen von SVN. 01:50:41.440 --> 01:50:43.660 Ich finde es schwierig zu beantworten. 01:50:43.660 --> 01:50:48.380 Also wenn ich jetzt mal an den Umstieg von SVN auf Git nachdenke. 01:50:48.380 --> 01:50:56.680 Ich sage mal, der Workflow, das Branching, war glaube ich das geringere. 01:50:56.680 --> 01:51:01.600 Also was erstmal verwirrend ist, ist, warum habe ich keine Version, keine Revisionsnummern mehr? 01:51:01.600 --> 01:51:03.020 Git hat ja so eine laufende Nummer. 01:51:03.020 --> 01:51:05.700 Da sind wir ja gerade schon drauf eingegangen. 01:51:05.700 --> 01:51:06.540 Das ist das Hashing. 01:51:07.500 --> 01:51:12.460 Ich denke, wichtig ist, das Team erstmal irgendwie so ein bisschen auf Git einzuüben, 01:51:12.460 --> 01:51:16.640 bevor man mit dem Projekt startet, also mit der Migration des Projekts startet. 01:51:16.640 --> 01:51:23.260 Dass man da halt erstmal guckt, dass jeder zumindest grundlegend weiß, wie ist der Git-Workflow. 01:51:23.260 --> 01:51:27.140 Dass ich Sachen in die Stage adde, daraus dann ein Commit mache. 01:51:27.140 --> 01:51:29.380 Wie funktioniert Branching? 01:51:29.380 --> 01:51:31.580 Das sind nur Labels und Commits etc. 01:51:34.080 --> 01:51:39.620 Aber ob jetzt der Prozess wirklich anders sein muss, wenn ich mit Branches arbeite. 01:51:39.620 --> 01:51:45.960 Also wenn ich jetzt einen langlaufenden Branch habe und da Risiko laufe, Merch-Konflikt zu bekommen, 01:51:45.960 --> 01:51:48.880 habe ich den nicht in Git genauso, wie ich ihn auch in SVN hätte? 01:51:48.880 --> 01:51:51.700 Ja, wahrscheinlich schon. 01:51:51.700 --> 01:51:52.720 Ja, jetzt meine Vermutung. 01:51:54.120 --> 01:51:56.360 Also letzten Endes ein Konflikt ist ein Konflikt. 01:51:56.360 --> 01:52:01.100 Also wenn du an der gleichen Coachstelle, wenn zwei Leute an der gleichen Coachstelle was machen, 01:52:01.100 --> 01:52:02.820 ist es egal, glaube ich, was du machst. 01:52:02.820 --> 01:52:03.940 Du wirst einen Konflikt haben. 01:52:03.940 --> 01:52:06.820 Also der muss gelöst werden. 01:52:06.820 --> 01:52:10.520 Und ja, also ich weiß es auch nicht. 01:52:10.520 --> 01:52:15.020 Ich habe auch mal die Transition mitgemacht von SVN zu Git. 01:52:15.860 --> 01:52:24.140 Und ich glaube, was mir geholfen hätte, wäre, wenn, also ich habe mir schwer getan damals damit, 01:52:24.140 --> 01:52:26.940 weil ich hatte den Eindruck, SVN nimmt einem ein bisschen mehr ab. 01:52:26.940 --> 01:52:29.000 Ich kann jetzt nicht genau sagen, woran ich das festmache, 01:52:29.000 --> 01:52:31.260 aber das Tooling, was ich damals verwendet habe, habe ich so gedacht, 01:52:31.260 --> 01:52:32.760 da muss ich weniger drüber nachdenken. 01:52:32.760 --> 01:52:36.640 Und bei Git sind dann halt so diese Rebase-Geschichten passiert, 01:52:36.640 --> 01:52:37.980 die ich jetzt auch gerade schon beschrieben habe. 01:52:37.980 --> 01:52:40.900 Das ist damals auch schon passiert, wo man dann so davor sitzt und erst mal so denkt, 01:52:41.300 --> 01:52:43.920 Okay, ich verstehe jetzt gerade gar nicht, was passiert. 01:52:43.920 --> 01:52:50.360 Und ich glaube, wahrscheinlich wäre so ein bisschen Theorie-Schulung am Anfang eine gute Idee, 01:52:50.360 --> 01:52:53.600 sodass man die Grundkonzepte versteht. 01:52:53.600 --> 01:52:58.040 Dann kommen auch diese Momente, wo man dann sagt, 01:52:58.040 --> 01:52:59.700 Moment, scheiße, was ist denn jetzt passiert? 01:52:59.700 --> 01:53:04.140 Ich komme mir hier ziemlich blöd vor und verzweifle irgendwie. 01:53:04.140 --> 01:53:05.620 Die kommen dann vielleicht auch weniger. 01:53:05.620 --> 01:53:08.840 Das ist jetzt einfach so ein Gedanke, den ich jetzt noch dazu hatte. 01:53:08.840 --> 01:53:12.440 Also mit SVN hatte ich das auch schon, dass dann irgendwie noch ein Clean-Up geholfen hat, 01:53:12.440 --> 01:53:14.260 weil sich irgendwas festgefahren hatte. 01:53:14.260 --> 01:53:17.720 Also da weiß ich, ob das jetzt seltener vorkam mit SVN. 01:53:17.720 --> 01:53:20.680 Von daher, ich glaube, das gibt sich nicht viel. 01:53:20.680 --> 01:53:28.020 Ja, also ich hatte auch, bei mir war der Umstieg auch erst mal schwierig, 01:53:28.020 --> 01:53:30.940 weil man nicht versteht, was man wirklich tun muss. 01:53:30.940 --> 01:53:33.660 Ich dachte auch, ich hätte Probleme mit Ad gehabt, 01:53:33.660 --> 01:53:38.200 aber jetzt hatte ich da nochmal nachgeguckt und SVN hatte eigentlich auch schon das Adden von Dateien. 01:53:38.200 --> 01:53:41.780 Deswegen hatte ich das gewundert, wo ich da Probleme hatte. 01:53:41.780 --> 01:53:46.300 Aber was mir letztendlich wirklich geholfen hat, war wirklich, wie schon Moritz sagt, 01:53:46.300 --> 01:53:48.200 mit der Materie mal auseinanderzusetzen. 01:53:48.200 --> 01:53:49.580 Wie funktioniert die Theorie? 01:53:53.740 --> 01:53:56.660 Ich weiß nicht, kann ich eine Buchempfehlung raushauen? 01:53:56.660 --> 01:53:57.480 Ja, klar. 01:53:57.480 --> 01:54:02.680 Auch wenn das Buch, ich glaube, das letzte Mal 2012 aktualisiert wurde. 01:54:02.680 --> 01:54:04.660 Solange der Inhalt immer noch aktuell ist. 01:54:04.660 --> 01:54:08.260 Ja, ein paar Kommandos haben sich ein bisschen geändert. 01:54:08.260 --> 01:54:10.300 Du musst ja zum Beispiel nicht mehr alles mit Checkout machen, 01:54:10.300 --> 01:54:12.900 da gibt es ja mittlerweile Switch und Restore und sowas. 01:54:12.900 --> 01:54:14.220 Aber das sind halt Details. 01:54:14.220 --> 01:54:17.940 Aber ich fand, die haben halt auch das mit den Tree-Objekten so ein bisschen ganz gut erklärt. 01:54:18.860 --> 01:54:22.520 Das war das Buch Version Control with Git von dem O'Reilly Verlag. 01:54:22.520 --> 01:54:24.980 Das fand ich eigentlich sehr gut. 01:54:24.980 --> 01:54:27.400 Und ich bin eigentlich alles andere als ein Bücherwurm. 01:54:27.400 --> 01:54:29.740 Und lesen ist echt nicht mein Ding. 01:54:29.740 --> 01:54:33.120 Aber das ist auch tatsächlich eins der wenigen Bücher, 01:54:33.120 --> 01:54:35.040 die ich von vorne bis hinten gelesen habe. 01:54:35.040 --> 01:54:39.320 Also es ist auch nicht so, dass es total trocken ist und einen langweilt. 01:54:39.320 --> 01:54:41.900 Das hat mir sehr gut geholfen. 01:54:41.900 --> 01:54:47.340 Und für die Leute, die es dann richtig wissen wollen, 01:54:47.500 --> 01:54:50.180 was ich ganz cool fand, war ein Vortrag, 01:54:50.180 --> 01:54:52.620 den hatte ich auf YouTube gesehen, von Tim Berglund. 01:54:52.620 --> 01:54:54.620 Der war damals bei GitHub. 01:54:54.620 --> 01:54:55.880 Ich glaube, da ist er heute nicht mehr. 01:54:55.880 --> 01:54:58.500 Der heißt Git from the bits up. 01:54:58.500 --> 01:55:01.700 Und da erklärt er auch so ein bisschen, 01:55:01.700 --> 01:55:04.120 wie die Internas funktionieren mit dem Hashing und so. 01:55:04.120 --> 01:55:07.160 Und da hat man auch so ein paar Aha-Effekte, 01:55:07.160 --> 01:55:11.320 wo man sagt, jetzt verstehe ich, wohin der Hase läuft. 01:55:11.320 --> 01:55:16.180 Und ich finde, dann funktioniert halt auch alles viel einfacher, 01:55:16.280 --> 01:55:18.840 weil man einfach versteht, was da jetzt hinten passiert. 01:55:21.460 --> 01:55:26.060 Aber einen wichtigen Punkt, finde ich, den wir noch nennen sollten für so einen Umstieg. 01:55:26.060 --> 01:55:29.080 Ich weiß nicht, wie es Surround-SCM macht, 01:55:29.080 --> 01:55:34.000 aber bei SVN war es ja so, dass man da ein zentrales Repository hat. 01:55:35.000 --> 01:55:38.100 Und das ist ja bei Git dann der krasse Unterschied, 01:55:38.100 --> 01:55:40.180 dass du da verteilte Repositories hast. 01:55:40.180 --> 01:55:47.900 Da hat ja jeder auf seinem Rechner ein Klon und zwar komplett des Repositories. 01:55:47.900 --> 01:55:51.140 Das heißt, wenn ich sage Git clone und irgendein Remote angebe, 01:55:51.140 --> 01:55:56.880 dann zieht er auch alle Dateien, die jemals existiert haben und packt die bei mir auf die Platte. 01:55:57.740 --> 01:56:07.320 Der schöne Nebeneffekt ist dann halt, ich kann sogar in Deutschland mit der Bahn fahren und kann mal einen Branch auschecken oder Commits machen, etc. 01:56:07.320 --> 01:56:11.360 Weil ich nicht angewiesen bin, dass ich eine Verbindung zu dem Remote haben muss. 01:56:11.360 --> 01:56:14.420 Und wenn die Verbindung wieder da ist, dann kann ich dahin pushen. 01:56:15.760 --> 01:56:18.540 Also ein Git Remote muss nicht direkt auch ein GitHub sein. 01:56:18.540 --> 01:56:21.360 Das kann theoretisch einfach ein Verzeichnis auf der Festplatte sein. 01:56:21.360 --> 01:56:25.840 Also ich könnte theoretisch hingehen und sagen, Git clone, irgendein Verzeichnis auf der Festplatte angeben 01:56:25.840 --> 01:56:32.560 und dann habe ich quasi ein Remote geklont und kann dann so auch vielleicht mal Experimente machen. 01:56:32.560 --> 01:56:37.300 Was mir vorher noch eingefallen ist, ist bei SVN, korrigiert mich, wenn ich falsch liege, 01:56:37.300 --> 01:56:39.420 aber da gab es auch keine Staging Area, oder? 01:56:39.420 --> 01:56:44.560 Also das bin ich zu hundertprozentig sicher, aber ich glaube, das war mehr so, 01:56:45.260 --> 01:56:47.680 Das war nämlich was, was ich erst lernen musste bei Git. 01:56:47.680 --> 01:56:52.240 Das ist das, was diese Staging Area ist, dass es quasi so ein Zwischenzustand ist. 01:56:52.240 --> 01:56:58.040 Ich markiere etwas, was ich jetzt committen möchte und das ist aber dann noch nicht committed. 01:56:58.040 --> 01:57:01.680 Also so ein Zwischenschritt, also im Vergleich zu SVN ein Zwischenschritt. 01:57:01.680 --> 01:57:06.180 Also das war für mich, glaube ich, wichtig, auch um irgendwie so ein bisschen zu verstehen, wie das Ganze funktioniert. 01:57:06.180 --> 01:57:07.860 Ja, das war auch meine Erinnerung. 01:57:07.860 --> 01:57:12.460 Ich habe nur die Tage nochmal ein bisschen rumgegoogelt und dann dachte ich, Moment, es gibt da ein SVN-Ad. 01:57:12.460 --> 01:57:15.140 Und dann habe ich gedacht, ich verstehe es nicht. 01:57:15.260 --> 01:57:17.880 Gab es das früher, gab es nicht? Es ist einfach schon so lange her. 01:57:17.880 --> 01:57:22.320 Also ich habe ja letztens erzählt, dass ich wieder SVN nutzen musste wegen unserem WordPress-Plugin, 01:57:22.320 --> 01:57:25.280 weil das da in deren Struktur immer noch benutzt wird. 01:57:26.240 --> 01:57:38.620 Aber ich habe dann auch tatsächlich Tortoise-Git als Client genutzt, als GOI und da gibt es, ich bin mir sicher, es ist wieder eine Woche her, dass ich es genutzt habe und schon wieder vergessen. 01:57:38.620 --> 01:57:40.020 Aber ich glaube, da gibt es keine Staging. 01:57:40.020 --> 01:57:45.280 Also du wählst dann halt die Dateien aus und dann, wenn du dir dann eincheckst, dann gehen die direkt auch zum Server. 01:57:45.280 --> 01:57:46.840 Also da gibt es nicht nochmal einen Zwischenschritt. 01:57:47.700 --> 01:57:56.040 Ja, aber ich finde, da merkt man auch so ein bisschen, dass Git da die Möglichkeit schafft, dass du wirklich deine Commits designen kannst. 01:57:56.040 --> 01:57:59.920 Dass du wirklich überlegst, okay, welche Erinnerung packe ich da jetzt wirklich rein? 01:58:00.540 --> 01:58:03.840 Und dann nachher dann deine Commit-Message dazu schreibst. 01:58:03.840 --> 01:58:08.700 Das finde ich, fand ich anfangs schwierig mit dieser Staging-Area. 01:58:08.700 --> 01:58:09.760 Ich habe es auch nicht verstanden. 01:58:09.760 --> 01:58:15.000 Aber mittlerweile mag ich das sehr, das Konzept. 01:58:15.000 --> 01:58:19.660 Also ja, wenn man es mal verstanden hat, dann hilft es einem sehr. 01:58:19.660 --> 01:58:21.960 Eben genau, was du gerade gesagt hast, Commits Design. 01:58:21.960 --> 01:58:29.900 Ich habe jetzt vielleicht hier irgendwie fünf Files angepasst, weiß aber, dass die einzelnen, ich möchte eigentlich unterschiedlich beschreiben, 01:58:29.900 --> 01:58:33.240 weil ich mache unterschiedliche Sachen eigentlich und das kann ich dann nochmal auseinanderklamüsern. 01:58:33.240 --> 01:58:35.640 Ziemlich einfach, indem ich einfach nur die ersten, ja. 01:58:35.640 --> 01:58:41.280 Du vermeidest das, was wir vorhin besprochen haben, dass du feststellst, ah, das hätte ich vielleicht doch lieber so. 01:58:41.280 --> 01:58:46.600 Weil du guckst dir nochmal genau an, bevor du dann wirklich auf Commit klickst, schaust nochmal durch die Datei. 01:58:46.600 --> 01:58:50.420 Dann stellst du fest, ah, okay, da ist jetzt nochmal ein Hang drin, den sollte ich nochmal rausmachen und so. 01:58:50.420 --> 01:58:54.540 Also das hilft wirklich, ja, dann auch sauberer zu arbeiten und schöner zu arbeiten. 01:58:54.800 --> 01:59:00.800 Ja, was vielleicht auch nochmal ein guter Hinweis ist, er hat ja irgendwie gesagt, langlaufende Feature-Branches. 01:59:02.540 --> 01:59:10.580 Es ist ein Modell, das habe ich jetzt schon ewig nicht mehr benutzt und zwar nennt sich das Successful-Git-Branching-Modell. 01:59:10.580 --> 01:59:15.980 Das ist eigentlich, das ist ein Artikel und da ist Git-Flow raus entwachsen, so eine Skript-Sammlung. 01:59:16.680 --> 01:59:20.660 Weil das ist quasi so ein Modell, wie kann man mit Feature-Branches umgehen. 01:59:20.660 --> 01:59:25.260 Man hat dann so einen Develop-Branch, der quasi der aktuelle Entwicklungszweig ist. 01:59:25.260 --> 01:59:28.600 Daraus bilden sich quasi dann die Features, die wieder in den Develop reingemerged werden. 01:59:28.600 --> 01:59:33.740 Daraus wird dann wieder ein Release-Branch gemacht, wo dann das Release dann gestaltet wird. 01:59:33.740 --> 01:59:37.380 Da kann man dann hingehen und sagen, okay, ich mache nochmal Commits für dieses Release. 01:59:38.060 --> 01:59:45.220 Und zum großen Finale wird das dann in den Master-Branch gemerged und da getaggt, wenn man dann das Release abschließt. 01:59:45.220 --> 01:59:47.200 Und das wird dann auch nochmal in den Develop gemerged. 01:59:47.200 --> 01:59:50.780 Das kann man vielleicht auch nochmal verlinken, vielleicht hilft das dem einen oder anderen. 01:59:50.780 --> 01:59:55.940 Obwohl das heutzutage nicht mehr so häufig benutzt wird, weil die meisten mittlerweile nach diesem GitHub-Flow gehen. 01:59:55.940 --> 02:00:01.620 Du zweigst vom Master ab, machst dein Feature fertig und mergst den Master zurück. 02:00:01.620 --> 02:00:06.880 Also das sieht man ja sehr häufig mittlerweile, dass die Projekte eigentlich direkt in den Master mergen. 02:00:07.380 --> 02:00:09.300 anstatt noch Releases zu designen und so. 02:00:09.300 --> 02:00:16.880 Aber ich kann mir gut vorstellen, gerade bei großer Software, wo man vielleicht auch noch alte Versionen supporten muss, 02:00:16.880 --> 02:00:21.260 dass da dieses Branching-Modell hilft. 02:00:21.260 --> 02:00:27.080 Okay, dann kommen wir eigentlich schon zum allerletzten Punkt auf der Liste. 02:00:27.080 --> 02:00:37.260 Gibt es noch irgendwelche geheimen oder unbekannten, wenig genutzten Commands, die praktisch sind und die wir jetzt noch nicht besprechen? 02:00:37.380 --> 02:00:41.820 Ich hoffe, ich habe sie alle strategisch gut verteilt gehabt. 02:00:41.820 --> 02:00:43.980 Ich wollte gerade sagen, also ich habe schon ganz viel. 02:00:43.980 --> 02:00:48.080 Der Punkt ist eigentlich überflüssig, weil ich habe schon so viel gelernt und für mich war vieles unbekannt. 02:00:49.340 --> 02:00:58.640 Ich scrolle gerade nochmal durch meine Notizen, ob wir irgendwas übersprungen haben, weil es jetzt im Gesprächsfluss so entstanden ist. 02:00:58.640 --> 02:01:02.620 Aber ich denke, all die Sachen sind gekommen. 02:01:02.860 --> 02:01:09.400 Also ich finde halt so dieses Git-Add-P für das Partially-Adden für mich eine ganz gute Sache. 02:01:09.400 --> 02:01:12.000 Fix-Up-Commits finde ich eine super Sache. 02:01:13.480 --> 02:01:16.860 Dann halt interaktiver Read-Base mit dem Editieren von Commits. 02:01:16.860 --> 02:01:19.680 Das sind so die Dinge, wo ich denke, ja. 02:01:19.680 --> 02:01:31.080 Dann hätte ich vielleicht an der Stelle noch eine kleine Sache, die mir wieder eingefallen ist, die ich ein einziges Mal verwendet habe, die ein Kollege von mir mir gezeigt hat. 02:01:31.080 --> 02:01:32.680 Und zwar Git-Bisect. 02:01:33.200 --> 02:01:36.180 Ja, ich habe super nachgedacht, ob ich es noch erwähnen soll. 02:01:36.180 --> 02:01:37.360 Das ist geil, oder? 02:01:37.360 --> 02:01:43.300 Wie gesagt, ich habe es noch einmal gebraucht und es hat damals auch mein Problem tatsächlich nicht gelöst. 02:01:43.300 --> 02:01:45.320 Das weiß ich noch. 02:01:45.320 --> 02:01:51.160 Ich weiß auch nicht genau, warum nicht, weil eigentlich hätte es mein Problem lösen müssen. 02:01:51.160 --> 02:01:53.880 Möchtest du oder soll ich? 02:01:53.880 --> 02:02:00.660 Ich kann es nur ganz grob auf einem sehr hohen Level, also von sehr weit oben erzählen. 02:02:00.660 --> 02:02:02.640 Du weißt vielleicht besser, wie es funktioniert. 02:02:03.100 --> 02:02:05.320 Ich nutze es jetzt auch nicht jeden Tag. 02:02:05.320 --> 02:02:08.180 Nein, ich bin ehrlich, ich habe es schon sehr lange nicht mehr genutzt. 02:02:08.180 --> 02:02:16.240 Aber was es letztendlich macht, ist, also der Job dieses Commands ist es eigentlich, einen Commit zu finden, der was kaputt gemacht hat. 02:02:16.240 --> 02:02:27.520 Und was du letztendlich machst, ist, du gibst ihm die Range an, die er checken soll, indem du sagst, hey, da hinten, da weiß ich noch, da hat es funktioniert. 02:02:28.160 --> 02:02:33.400 Und kleiner Funfact am Rande, wie ich dieses Head-Tilde-1 angeben kann. 02:02:33.400 --> 02:02:41.700 Da kann ich auch, glaube ich, mit Head, ich meine, ich muss ein Head-Zeichen machen und geschweifte Klammern, da kann ich sogar eine Time-Range angeben. 02:02:41.700 --> 02:02:47.060 Das ist jetzt in meinen Recherchen, ich kannte das vorher auch nicht, aber ich dachte, wofür brauche ich das? 02:02:47.900 --> 02:02:52.220 Wo du sagen kannst, hey, vor fünf Tagen, also five days ago und so. 02:02:52.760 --> 02:02:54.780 Ja, aber es ergibt total Sinn. 02:02:54.780 --> 02:02:57.840 Vielleicht darfst du, dass du weißt, gestern ging es noch. 02:02:57.840 --> 02:02:58.600 Da hat es doch noch funktioniert. 02:02:58.600 --> 02:02:59.480 Ja, genau, genau. 02:02:59.480 --> 02:03:01.280 Total logisch. 02:03:01.280 --> 02:03:08.980 Also letztendlich, du markierst einen Commit, wo es nicht mehr ging, wo es noch ging und hast halt den Commit heute, wo es nicht mehr geht. 02:03:08.980 --> 02:03:12.680 Und was der quasi macht, ist, der checkt dann für dich aus. 02:03:12.880 --> 02:03:17.560 Und zwar ist das, glaube ich, eine Binary-Search, die hat am Macht, deswegen heißt es wahrscheinlich auch BISEC. 02:03:17.560 --> 02:03:19.500 Genau, ja, so steht es in der Doku. 02:03:19.500 --> 02:03:24.600 Und du gehst dann halt immer hin und sagst dem Kommando, ob es jetzt auf diesem Commit geht oder nicht geht. 02:03:24.600 --> 02:03:27.820 Und du checkt ja für dich was Neues aus, dann sagst du wieder geht, geht nicht. 02:03:27.820 --> 02:03:28.820 Ja, cool. 02:03:28.820 --> 02:03:36.700 Und im Optimalfall landest du dann zum Schluss bei dem einen Commit, der den fehlerhaften Code dann hingeführt hat. 02:03:36.700 --> 02:03:42.660 Du kannst sogar so weit gehen, dass du es nicht manuell machst, sondern ihm noch einen Command mitgibst, 02:03:42.720 --> 02:03:43.480 was er ausführen soll. 02:03:43.480 --> 02:03:49.260 Also wenn du zum Beispiel fleißig Tests geschrieben hast, könntest du quasi das Laufen deiner Tests quasi mit angeben. 02:03:49.260 --> 02:03:56.840 Und dann, je nachdem, was er für den Statuscode zurückgibt, 1 oder 0, weißt dann BISEC, ob das erfolgreich war oder nicht. 02:03:56.840 --> 02:03:59.440 Und dann musst du dich eigentlich nur zurücklehnen und zugucken. 02:03:59.440 --> 02:04:03.140 Und irgendwann sagt er dir hier, das ist der Commit, wo der Fehler reingekommen ist. 02:04:03.140 --> 02:04:07.160 Oder es ist der erste Commit, bei dem deine Tests fehlschlagen. 02:04:07.160 --> 02:04:12.700 Genau, das ist nämlich noch der Punkt und das ist auch das, warum ich vermute, dass es bei mir damals, 02:04:12.720 --> 02:04:20.340 nicht zum Ergebnis geführt hat, ist, man kann ja etwas über mehrere Commits hinweg kaputt machen. 02:04:20.340 --> 02:04:24.580 Und dann gibt es einen Punkt, wo es dann kaputt geht, also wo dann quasi der Test fehlschlägt. 02:04:24.580 --> 02:04:29.080 Aber vielleicht haben andere Sachen vorher schon dazu geführt, dass es dann irgendwie langsam kaputt gegangen ist. 02:04:29.160 --> 02:04:37.160 Das war dann nur so quasi das eine Bit, das quasi gekippt ist, was dann den Test hat fehlschlagen lassen oder das Feature kaputt gemacht hat. 02:04:37.160 --> 02:04:43.900 Aber ja, genau. Aber das ist, das fand ich einmal, das fand ich extrem krass, dass es sowas gibt und irgendwie eine sehr, sehr gute Idee. 02:04:44.060 --> 02:04:50.320 Weil das ist bei der Fehlersuche immer interessant, auch mal zu gucken, wo ist das denn jetzt überhaupt kaputt gegangen. 02:04:51.960 --> 02:05:00.960 Auf jeden Fall, coole Idee, das Kommando. Also ich finde es, ja, macht total Spaß, sowas zu sehen. 02:05:00.960 --> 02:05:01.980 Ja. 02:05:03.360 --> 02:05:14.760 Aber man muss erst mal wissen, dass es das gibt. Da hätte ich nie, also wenn ich, wenn das nicht ein Kollege von mir gesagt hätte, ah ja, macht doch mal Git Bisect, wäre ich nie drauf, ich hätte nicht mal danach gesucht, ob es sowas gibt. 02:05:14.760 --> 02:05:15.140 Ja, klar. 02:05:15.140 --> 02:05:15.720 Ja. 02:05:16.500 --> 02:05:24.960 Es ist so ein typisch verstecktes Kommando, wo man erst mal, wo man vielleicht gar nicht drauf kommt, dass es sowas geben könnte. Also jetzt wisst ihr es. 02:05:24.960 --> 02:05:28.180 Es ist doch schön, dass wir jetzt dazu beitragen konnten, dass es in die Welt getragen wird, oder? 02:05:28.180 --> 02:05:36.240 Genau, hier. Morgen drucken wir Fanshirts. Git Bisects-Fangruppe, ja. 02:05:36.240 --> 02:05:38.420 Ja, demnächst in unserem Merchandising-Shop. 02:05:39.420 --> 02:05:50.720 Was ich noch ganz cool finde, das ist wahrscheinlich auch nichts, was jeder braucht. Es gibt, das ist aber ein Skript, was du dir dazu installieren kannst, und zwar nennt sich das Git-Filter-Repo. Ich schiebe dir gleich mal den Link, Boris. 02:05:50.720 --> 02:06:05.000 Das ist ganz cool, wenn man mal in der Situation war, dass man gesagt hat, boah, Mono-Repo, das ist doch das Ding. Und irgendwann denkt man sich, ja, war doch nicht so das Ding. Ich hätte das doch ganz gerne wieder aufgeteilt. 02:06:05.560 --> 02:06:17.060 Vielleicht möchte man ja seine History behalten. Und dieses Git-Filter-Repo ist so eine Skriptsammlung letztendlich, wo du dann einfach die Möglichkeit hast, zu sagen, was für Commits sollen rausgefiltert werden. 02:06:17.060 --> 02:06:27.240 Da kann der Verzeichnisse noch neu schreiben, dass du zum Beispiel das, was vorher unter Packages, Slash, was auch immer lag, dann direkt im Root liegt und so Geschichten. 02:06:28.820 --> 02:06:39.460 Ja, das habe ich jetzt schon so zwei-, dreimal eingesetzt, wo man dann Repositories zerlegt hat, weil man sie jetzt doch vielleicht in GitHub einzelt haben möchte, damit dann die Pipelines besser funktionieren. 02:06:39.460 --> 02:06:46.220 Oder man das direkt nach Netlify pushen kann, das weiß ich nicht. Ja, das fand ich auch eigentlich ganz cool. 02:06:49.360 --> 02:06:52.080 Cool. Dann sind wir, glaube ich, so weit durch, oder? 02:06:52.080 --> 02:06:56.480 Mensch, das war ein Ritt. Ich glaube, das muss ich mir noch dreimal anhören, um alles zu verstehen. 02:06:56.480 --> 02:07:01.680 Ja, ich habe noch nie so viel gelernt in unserer eigenen Folge wie diesmal. Ja, echt cool. 02:07:01.680 --> 02:07:03.860 Danke kurz, sehr kurz zur Sendung. 02:07:03.860 --> 02:07:08.900 Bitte? Sehr kurze Sendung. Aber wir sind jetzt bei zwei Stunden zehn gleich. 02:07:08.900 --> 02:07:11.020 Etwas über zwei Stunden schon, ja. 02:07:11.300 --> 02:07:25.300 Gut, dann, ich würde jetzt, ich muss seit ungefähr einer Stunde schon, ganz dringend mal wohin, entweder macht ihr weiter oder wir machen eine kurze Pause und machen dann mit dem nächsten Punkt weiter. 02:07:25.300 --> 02:07:30.100 Guck mal, spiel doch den Jingle ein und geh dann und dann macht Michael das, was dann kommt. 02:07:30.100 --> 02:07:32.680 Okay, und ich beeile mich, weil das will ich nämlich natürlich auch noch hören. 02:07:32.680 --> 02:07:35.160 Genau, dann beeile dich. 02:07:35.160 --> 02:07:36.260 Bin ich gleich wieder da. 02:07:36.260 --> 02:07:53.260 Ja, der Michael hat ein Geilteil mitgebracht und wir wissen gar nicht, was es ist und wir lassen uns jetzt einfach davon überraschen. 02:07:53.260 --> 02:08:00.900 Ja, also ein ganz persönlicher Geilteil. Das ist ja bei vielen Leuten sehr unterschiedlich, was sie geil finden. 02:08:01.700 --> 02:08:10.200 Bei mir war es ein YouTube-Video von einem YouTuber, der sich Sebastian, ich glaube, man spricht das Lake aus, Largway geschrieben. 02:08:10.200 --> 02:08:13.000 Der macht eigentlich so Unity-Zeug. 02:08:13.000 --> 02:08:17.340 Ich gucke denen aber immer total gerne zu, auch wenn ich nie was mit Unity mache. 02:08:17.340 --> 02:08:21.660 Einfach, um zu sehen, wie er es macht und wie er mit Algorithmen da rangeht und so. 02:08:22.280 --> 02:08:36.820 Und er hat jetzt letztens eine Ameisensimulation gebaut und ich war total fasziniert, wie nachher diese Ameisen, also er simuliert quasi, wie die mit Pheromonen umgehen, wenn sie auf der Suche nach Nahrung sind, wenn sie Nahrung gefunden haben. 02:08:36.820 --> 02:08:46.360 Und wie sich dann plötzlich dieses System entwickelt von 500 Ameisen, die dann nachher alle gezielt zu Nahrungsplätzen laufen, fand ich total faszinierend. 02:08:47.120 --> 02:08:49.720 Und ja, packen wir auf jeden Fall die Shownotes. 02:08:50.780 --> 02:08:52.800 Genau, ich schaue es mir gerade an. 02:08:52.800 --> 02:08:56.900 Also ich habe gerade mal den Anfangsscreen mir angeschaut. 02:08:56.900 --> 02:08:58.600 Das sieht schon faszinierend aus. 02:08:58.600 --> 02:09:02.880 Und wenn ich das richtig sehe, codet er so einmal durch, diese ganze Geschichte. 02:09:02.880 --> 02:09:06.040 Oh ja, das wird sehr interessant, wenn man mal ein bisschen weiterklickt. 02:09:06.040 --> 02:09:08.740 Ich bin jetzt gerade mal irgendwie so bei zu neun Minuten gesprungen. 02:09:08.860 --> 02:09:17.360 Da wird das schon interessant, weil die dann, man sieht da ganz viele Ameisen rumwuseln in so einem Bereich, der beschränkt ist. 02:09:17.360 --> 02:09:19.220 Also so irgendwie so eine Art Ameisenbau. 02:09:19.220 --> 02:09:24.400 Und dann sieht man auch, die laufen irgendwo hin und sammeln da was ein und bringen es woanders hin. 02:09:24.400 --> 02:09:30.060 Und also man sieht irgendwie so eine Ameisenstraße und das scheint irgendwie alles da mit Code realisiert zu sein. 02:09:30.060 --> 02:09:31.400 Echt sehr faszinierend. 02:09:31.400 --> 02:09:32.620 Stimmt. 02:09:32.620 --> 02:09:37.160 An der ich mich selbst wiedergesehen habe, war, du erzählst gerade so einen Ameisenbau. 02:09:37.160 --> 02:09:40.720 Und er erzählt so, dass er das in einem älteren Projekt schon mal gemacht hat. 02:09:40.720 --> 02:09:44.380 Und er hat jetzt diesen Code entsprechend angepasst und auch noch eingebaut, 02:09:44.380 --> 02:09:48.640 dass man jetzt mit einem Pinsel noch was hinzufügen kann in das Labyrinth und rausnehmen kann. 02:09:49.240 --> 02:09:54.100 Und ja, er weiß, er hätte das in Paint in zwei Minuten malen können, aber ... 02:09:54.100 --> 02:10:00.000 Ja, aber dann wäre es nicht so geil. 02:10:00.000 --> 02:10:05.820 An der Stelle sei nochmal verwiesen auf eine Folge, ich weiß nicht mehr genau, welche Nummer das war, 02:10:05.820 --> 02:10:08.900 wo ich auch mal ein bisschen was über Unity erzählt habe, weil wir haben, 02:10:08.900 --> 02:10:13.420 ich habe auch mal ein bisschen was mit Unity gebastelt, einfach mal so, um ein bisschen auszuprobieren. 02:10:13.420 --> 02:10:18.700 Vielleicht weiß da Konstantin, der uns, der wieder da ist, vielleicht noch, welche Folge das war. 02:10:19.060 --> 02:10:24.360 Ich suche schnell in unserer geheimen Suche nach Unity und habe aber gleich, ich habe ganz viele. 02:10:24.360 --> 02:10:28.220 Nummer drei, Nummer vier, Nummer fünfzehn, Nummer achtzehn, Nummer neunzehn. 02:10:28.220 --> 02:10:28.980 Nein, das kann nicht sein. 02:10:28.980 --> 02:10:30.440 Das kann nicht sein. Die Suche muss kaputt sein. 02:10:30.440 --> 02:10:31.140 Das kann nicht sein. 02:10:31.140 --> 02:10:34.980 Ich hätte jetzt vermutet, es ist zwei Folgen her, wo du das erzählt hast. 02:10:34.980 --> 02:10:36.100 Ich glaube, es ist noch länger. 02:10:36.100 --> 02:10:37.880 Und für dich wäre wahrscheinlich auch der Rest des Kanadens interessant. 02:10:37.880 --> 02:10:39.960 Unity Engine Nummer achtzehn. 02:10:39.960 --> 02:10:41.800 Nummer achtzehn, ja. 02:10:41.800 --> 02:10:45.360 Genau, wir sind jetzt bei 25, es ist noch ein bisschen länger her. 02:10:45.360 --> 02:10:49.700 Also ich erinnere mich, also es muss auf jeden Fall im November gewesen sein, letztes Jahr. 02:10:49.700 --> 02:10:50.760 Genau, das kommt hin, ja. 02:10:50.760 --> 02:10:51.780 Folge Nummer achtzehn. 02:10:51.780 --> 02:10:55.640 Ja, jetzt hast du es leider schon verpasst. 02:10:55.640 --> 02:10:58.960 Ja, ich freue mich jetzt aufs nochmal durchhören, was ich ja eh immer mache. 02:10:58.960 --> 02:11:02.200 Und jetzt nehme ich dann auch sogar noch neue Informationen mit, während ich das tue. 02:11:02.200 --> 02:11:03.680 Ich glaube, es ist was für dich. 02:11:03.960 --> 02:11:04.680 Auf jeden Fall. 02:11:04.680 --> 02:11:08.780 Ich weiß nämlich, du hast schon öfter coole Sachen empfohlen und Sachen, die vielleicht 02:11:08.780 --> 02:11:09.800 in eine ähnliche Richtung gehen. 02:11:09.800 --> 02:11:12.060 Ich glaube, das könnte was für dich sein. 02:11:12.060 --> 02:11:12.780 Ich bin gespannt. 02:11:12.780 --> 02:11:16.660 Ja, dann soll ich mit meinem Geilteil noch weitermachen? 02:11:16.660 --> 02:11:17.580 Ja, bitte. 02:11:17.580 --> 02:11:18.680 Seid ihr am Ende. 02:11:18.680 --> 02:11:23.960 Ja, meins greift auch nochmal direkt auf das Thema GitHub zurück. 02:11:24.520 --> 02:11:28.640 Und da bin ich zufällig gar nicht mal aktiv auf der Suche, sondern zufällig über Twitter 02:11:28.640 --> 02:11:30.100 drauf gestoßen. 02:11:30.100 --> 02:11:36.180 Und zwar ist das, also erstmal, es ist von Mary Rose Cook. 02:11:36.180 --> 02:11:38.480 Der Name hat mir vorher nichts gesagt. 02:11:38.480 --> 02:11:44.380 Und die hat zunächst mal in 600 Worten beschrieben, was Git ist. 02:11:44.740 --> 02:11:50.560 Also ganz kurz zusammengefasst mit einem Beispiel, quasi auf dem Dateisystem, was da so passiert. 02:11:50.560 --> 02:11:53.060 Gibt aber auch noch einen längeren Artikel dazu. 02:11:53.060 --> 02:11:59.740 Und im Anschluss hat sie in tausend Zeilen JavaScript Git nachprogrammiert. 02:11:59.740 --> 02:12:00.620 Quasi. 02:12:00.620 --> 02:12:00.900 What? 02:12:00.900 --> 02:12:05.500 Ja, und zwar nicht, um das jetzt irgendwie abzulösen und da was Eigenes zu bauen und das produktiv 02:12:05.500 --> 02:12:11.160 einzusetzen, sondern um es selbst zu verstehen und aber eben halt auch jetzt kommentiert, also 02:12:11.160 --> 02:12:14.720 wirklich super kommentiert den Code für andere, um zu verstehen, was da auf dem Code ist. 02:12:14.720 --> 02:12:16.020 auf Dateiebene stattfindet. 02:12:16.020 --> 02:12:19.480 Also schon die Funktionsnamen, so wie die Git-Commands auch tatsächlich lauten. 02:12:19.480 --> 02:12:24.180 Nur, dass du halt genau siehst, welche Datei wird da angepackt und was genau wird da reingeschrieben 02:12:24.180 --> 02:12:24.440 und so. 02:12:24.440 --> 02:12:25.800 Also das fand ich ziemlich cool. 02:12:25.800 --> 02:12:30.480 Ich habe es jetzt noch nicht komplett durchgearbeitet, aber es sieht sehr cool aus und sehr clean. 02:12:30.480 --> 02:12:33.940 Auch rechts den Code und links dann die Kommentare dazu, was da genau passiert. 02:12:33.940 --> 02:12:36.260 Also sieht es sehr interessant aus. 02:12:36.260 --> 02:12:41.480 Und die lange Version, also das kommt natürlich auch alles in die Shownotes rein, die lange Version 02:12:41.480 --> 02:12:46.480 aus 6.000 Wörtern, die nennt sich Git from the inside out und die gibt es einmal als Text 02:12:46.480 --> 02:12:50.320 zum Nachlesen, aber auch als Talk auf YouTube und das packe ich natürlich auch rein. 02:12:50.320 --> 02:12:55.580 Ja, das ist nicht, also es geht nicht ganz so identif wie jetzt Rebase und Squash und so, 02:12:55.580 --> 02:12:59.680 ist da glaube ich jetzt nicht enthalten, aber so, also was da in dem Git-Ordner zum Beispiel 02:12:59.680 --> 02:13:03.200 passiert, wo wir es jetzt ja auch vorhin drüber hatten mit den Hashes und sowas, auch da geht 02:13:03.200 --> 02:13:09.180 sie drauf ein und das ist ein sehr interessanter Ansatz, um sowas zu erläutern, finde ich. 02:13:09.180 --> 02:13:11.820 Also kenne ich jetzt auch noch nicht von was anderem. 02:13:11.820 --> 02:13:16.940 Also das wirklich anhand von Code nachgeschrieben, sich anzuschauen. 02:13:16.940 --> 02:13:21.940 Ich glaube, das führt schon dazu, dass man ein relativ tiefes Verständnis bekommt, was 02:13:21.940 --> 02:13:23.260 da abläuft. 02:13:23.260 --> 02:13:25.700 Ja, das war es auch schon. 02:13:25.700 --> 02:13:30.700 Ich habe gerade herausgefunden, warum in unserer Suche nach Unity so viele Ergebnisse kommen. 02:13:30.700 --> 02:13:31.060 Wegen Community? 02:13:31.060 --> 02:13:33.240 Wegen Community, genau. 02:13:33.240 --> 02:13:39.740 Ja, also eigentlich funktioniert die Suche ja dann schon ganz gut. 02:13:39.740 --> 02:13:43.800 Ich hätte halt dann nur erwartet, dass das, wo Unity wirklich alleine steht, dann ganz 02:13:43.800 --> 02:13:44.420 oben kommt. 02:13:44.420 --> 02:13:47.440 So cool ist die WordPress-Suche dann offenbar doch nicht. 02:13:47.440 --> 02:13:53.820 Vielleicht kommt aber auch dann da Community zweimal vor bei dem ersten Ergebnis und ... 02:13:53.820 --> 02:13:57.440 Nee, ich glaube, die sortiert tatsächlich einfach nur nach Folge aufsteigend. 02:13:57.440 --> 02:13:58.560 Also beziehungsweise absteigend. 02:13:58.560 --> 02:13:59.840 Ja, das kommt tatsächlich nur einmal. 02:13:59.840 --> 02:14:00.600 Okay, gut, ja. 02:14:00.600 --> 02:14:05.280 Ach so, stimmt, klar, natürlich die neueste zuerst sozusagen. 02:14:05.280 --> 02:14:06.880 Deswegen, ja, genau. 02:14:06.880 --> 02:14:08.540 Alright. 02:14:08.540 --> 02:14:12.040 Dann kommt jetzt unser fehlender ... 02:14:12.040 --> 02:14:13.380 Schluss-Jingle, ja. 02:14:13.400 --> 02:14:18.120 Und dann ziehen wir jetzt echt durch. 02:14:18.120 --> 02:14:19.180 Zwei Stunden 15. 02:14:19.180 --> 02:14:23.300 Mensch, Michael, vielen Dank, dass du dabei warst. 02:14:23.300 --> 02:14:25.040 Ja, das war eine große Freude. 02:14:25.040 --> 02:14:29.840 Also ich glaube, du hast uns auf jeden Fall sehr weitergeholfen, vielleicht auch dem 02:14:29.840 --> 02:14:31.740 ein oder anderen Hörer oder Hörerin. 02:14:31.740 --> 02:14:32.820 Ja, davon gehe ich draus. 02:14:32.820 --> 02:14:33.440 Hoffen wir mal. 02:14:33.440 --> 02:14:40.440 Ich glaube, es ist keine Schande, deine Ausführungen mehrfach zu hören, behaupte ich jetzt mal, 02:14:40.440 --> 02:14:43.000 bis man es vielleicht verstanden hat und sich noch ein bisschen Literatur 02:14:43.000 --> 02:14:47.940 nebenher zurechtzulegen, weil das, ich glaube, es geht teilweise schon ziemlich in die Tiefe 02:14:47.940 --> 02:14:48.900 von Git. 02:14:49.580 --> 02:14:53.960 Aber ich glaube, es lohnt sich, wenn man ein bisschen tiefer einsteigt, um eben genauso komische 02:14:53.960 --> 02:14:58.800 Probleme zu vermeiden, die, wie ich es schon beschrieben habe, die bei mir immer auftauchen. 02:14:58.800 --> 02:15:03.040 Und dann, dass man am Ende auch einen schönen Git-Graph kriegt. 02:15:03.040 --> 02:15:07.740 Das ist ja scheinbar die große Kunst, ist am Ende die gerade Linie zu haben. 02:15:07.740 --> 02:15:10.780 Nein, nein, nein, nein, nein, ich wollte gerade sagen, es ist kein Graph, eine Linie. 02:15:10.780 --> 02:15:12.240 Ja, genau. 02:15:12.240 --> 02:15:15.100 Also bei Git-Graph kommt die Linie am Ende. 02:15:19.260 --> 02:15:21.560 Ja, Mensch, hast du noch was? 02:15:21.560 --> 02:15:24.360 Irgendwas noch vergessen, was du noch sagen willst? 02:15:24.360 --> 02:15:25.260 Deine Mutter grüßen? 02:15:25.260 --> 02:15:27.920 Genau, also der Gast hat das letzte Wort. 02:15:28.680 --> 02:15:31.380 Ich fürchte, Mama weiß nicht, was ein Podcast ist. 02:15:31.380 --> 02:15:41.400 Ich bin ruhig, habe alles gesagt, was ich sagen wollte, hat mich total gefreut, mal dabei 02:15:41.400 --> 02:15:48.140 zu sein, nicht immer nur am anderen Ende zu sitzen und zuzuhören und ja, hat mir sehr 02:15:48.140 --> 02:15:48.800 viel Spaß gemacht. 02:15:48.800 --> 02:15:49.920 Uns auch? 02:15:49.920 --> 02:15:50.200 Cool. 02:15:50.200 --> 02:15:50.700 Dann. 02:15:50.700 --> 02:15:51.600 Vielen Dank. 02:15:51.940 --> 02:15:56.560 Lass dich schon mal die Outro-Musik einplätschern und bis zum nächsten Mal. 02:15:56.560 --> 02:15:57.120 Bis dann. 02:15:57.120 --> 02:15:57.500 Ciao. 02:15:57.500 --> 02:15:58.440 Tschüss. 02:16:14.440 --> 02:16:20.440 Tschüss. 02:16:20.440 --> 02:16:20.440 Tschüss. 02:16:20.440 --> 02:16:22.440 Tschüss.