 Gut, dann fangen wir mal an. Das Thema ist ja GIT Q&A. Bevor ich anfangen, will ich mal gerne so eine Frage machen, wer denn GIT schon kennt und da das da mit der Selbsteinschätzung, der kennt GIT so ein bisschen komisch ist, würde ich mal sagen so auf einer Skala von 1 Anfänger bis 5 Vollprofi, wer würde sich als 1 Anfänger bezeichnen oder hat keine Ahnung? Okay, 2, 3, 4, 5. Dann darfst du jetzt die Session machen. Ne, gut, also es gibt ein paar Anfänger und viele, die sie so als ja schon mittelmäßig gut bis sehr gut bezeichnen. Von denen, die sich jetzt mit Anfänger gemeldet haben, weiß jeder, was GIT ist oder gibt es jemanden, dem nicht noch erklären muss, was Versionsverwaltung und GIT im Speziellen ist? Keiner. Okay, das ist schon mal gut. Wenn man GIT verwenden will, muss man sich eine Binary installieren, die gibt es für Windows und Linux und weg und damit kommt zum Beispiel auf einem Windows-System immer so ein Ding, das nennt sich GIT-Bash, damit kann man loslegen und mit GIT arbeiten. Es gibt zu GITs auch verschiedenste GUIs, also es gibt von GIT sogar selbst eine GUI, ich finde die grauenhaft. Also rudimentärste Software überhaupt, ich kann hier ein Report Store anlegen, das gibt es sogar so eine Ansicht, wo man dann sieht, was sich geändert hat, würde ich nicht unbedingt empfehlen. Wenn man in einigermaßen sinnvolle IDE verwendet, sowas wie Sublime Text oder PRPS-Dorm oder Visual Studio Code oder sonstiges, ist da oft schon irgendwie ein GIT-Klein drin und die sind in der Regel auch ziemlich gut. Also den von PRPS-Dorm liebe ich mittlerweile, weil der ja ganz, ganz viele Sachen schon drin hat, die man früher entweder nur auf Terminal-Ebe machen konnte oder eben ganz kompliziert anders. Ich verwende mittlerweile das Terminal bei GIT nur noch ganz selten, wenn ich sehr ausgefallene Befehle mache oder wenn ich nicht ganz genau weiß, wie ich es in PRPS-Dorm eine bestimmte Funktion machen kann. Gibt es glaube ich nicht für Windows? Gibt es? Okay. Ne, aber ich habe schon die verwendet. Was ich schon verwendet habe, ist Source Tree. Finde ich sehr, sehr gut. An manchen Stellen ist sogar besser als PRPS-Dorm, weil gerade der Patch-Mode da sehr viel besser ist. Ich kann wirklich einzelne Zeilen markieren und die auf den Index packen. Das geht bei PRPS-Dorm nur pro Chanc. Also ich kann mittlerweile pro Chanc sagen, den auf den Index oder nicht, aber ich kann nicht sagen diese zwei Zeilen vom Chanc und den Rest nicht. Also da ist Source Tree noch etwas überlegen. Jetzt vor ein paar Tagen kam irgendwie Sublime Merch raus, also von den Entwicklern von Sublime Text GIT-Client. Der ist irgendwie vom Aussehen ähnlich wie Source Tree. Sagt aber, dass das sehr, sehr schnell ist, dass der einzige Nachteil an Source Tree ist, recht langsam und gibt es nicht für Linux, also nur für Windows und Mac. Finde ich aber als kostenfreien GIT-Client echt gut. Es gibt von Github eine GUI, die speziell mit Github zusammenarbeitet. Man kann glaube ich auch normale Getreepus damit laden und damit arbeiten, aber man merkt, es ist sehr an dem Workflow von Github irgendwie orientiert. Wichtig ist halt, dass man die Basics von Github versteht und was da dahinter steckt. Und zwei Ressourcen, die ich da absolut empfehlen kann, ist zum einen die Dokumentation von Adlächien. Als Hintergrund Adlächien hat es unter anderem die Plattform Bitbuckets erzeugt und die hatten früher einen eigenen GIT-Server für Self Hosted-Lösungen, das nannte sich Stash. Das heißt mittlerweile glaube ich Bitbucket Server. Ist nicht genau wie Bitbucket, ist sogar in einer anderen Programmiersprache geschrieben, aber die sind halt auch, was so GIT angeht, sehr fit. Genau, das ist der Hersteller von Source Tree. Also die haben wirklich sehr, sehr gute Anleitung, die haben auch so kleine Tools, wo man mal GIT lernen kann. Und ich finde einfach auch die Visualisierung sehr so gut gemacht. Wir können hier zum Beispiel mal in diese Collaboration Using Branches reingehen und man sieht halt hier schon, die verwenden sehr auf diese Grafen zum Visualisieren und auch mal mit verschiedenen Farben, dass man sieht, welcher Branch jetzt wohin geht. Und ich finde es einfach sehr, sehr gut visualisiert. Also wenn man irgendwie mal eine Referenz braucht, auf der man ein bestimmtes Thema nochmal nachlesen kann, ist Adlächien.com.git eine ganz gute Anlaufstelle, wo man sowas nochmal lernen kann. Und auch viele von den Adlächien-Mitarbeitern haben sehr viel auf ihren eigenen Blocks über GIT geschrieben. Zum Beispiel irgendwie eine GIT-Config mit ein paar schönen Alliassen, die dann irgendwas irgendwie GIT-Block besser aussehen lassen oder die gemirrschte Branches, lokal löschen oder so Sachen. Also die haben immer noch sehr, sehr viele Ressourcen, die jetzt nicht unbedingt in offiziellem Doku stehen. Genau, eine andere Quelle, die ich absolut empfehlen kann, ist dieses GIT Cheat-Cheat. Das gibt es sogar auch in verschiedenen Sprachen, unter anderem in Deutsch. Und da sieht man alle Elemente, die so ein GIT-Repository hat. Und das ist auch meistens das erste Mal, wenn Leute, die GIT schon verwendet haben, Dinge sehen, die sie noch nie so gesehen haben. Also zum Beispiel diesen Slash ganz links, den kennen viel nicht. Und man hat halt hier diese verschiedenen Ebenen, aber also die Arbeitskopie ist der lokale Ordner, den man auf der Festplatte hat. Das, was lokales Repository heißt, ist alles, was in dem Punkt GIT-Ordner ist, wenn man irgendwie einen Pull oder einen Push macht. Das, was dann da global landet oder wenn man Komit gemacht hat, was dann da landet. Und das, was hier Remote Repository ist, ist das, was meistens GIT-HUB ist. Also vielleicht für die Beginner, GIT ist nicht gleich GIT-HUB. GIT-HUB ist einfach nur eine Repository Hosting und Kolloperationsplattform. Also da kann man GIT-Codes, also GIT-Repositories, abladen und kann dann da über Dinge diskutieren und kann so Dinge machen wie ein Pull Request. Was auch kein Feature direkt jetzt von GIT ist, sondern eher so ein Workflow-Tool, was eben GIT-HUB oder GIT-LAB oder Bitbuck hat einem anbieten. Und auf diesem Cheatsheet ist es ganz gut gemacht. Wenn man jetzt auf eine von diesen Ebenen draufklickt, dann sieht man alle Befehle, die man von dieser Ebene ausmachen kann, zu den anderen Ebenen. Also das typische Beispiel ist, man hat ein GIT-Add. Also man fügt eine Datei auf den Index hinzu, um sie danach committen zu können. Dann haben wir hier GIT-Comet minus A. Das ist das, wenn man nicht immer erst auf den Index und dann committet, sondern wenn man sagt, okay, committe mit vorher hinzufügen auf den Index. Dann haben wir hier Pull und Push und Reset Hard und sonstiges. Und dann aber auch zum Beispiel in die andere Richtung zum Stash. Das heißt, wenn man auf den Stash hingeht, dann sieht man auch wieder, wir haben die gleichen Sachen, die zur Arbeitskopie gehen, aber wir haben zum Beispiel auch hier ein Befehl Stash Branch, der dann im lokalen Repository einen Branch anlegt mit den Änderungen, die auf dem Stash sind. Das ist zum Beispiel so ein Befehl, den kennen auch viele nicht, aber so. Stash ist so eine Art flüchtiger Zwischenspeicher, könnte man sagen. Also nehmen wir mal an, du arbeitest jetzt gerade an irgendeinem Projekt, hast irgendwie Veränderungen gemacht bis gerade auf irgendeinem Branch und dann ruft ein Kollege ganz hektisch an und sagt, ah, da ist irgendwie ein Fehler auf Master, du musst mal schnell ein Patch schreiben. Jetzt bist du so mitten in der Arbeit und das, was du jetzt gerade geändert hast, soll nicht verloren gehen. Jetzt kannst du natürlich sagen, okay, ich mache jetzt ein Commit auf dem Branch, auf dem ich gerade bin oder mache einen neuen Branch auf irgendwie so Temp und schiebt es da drauf und merkt es dann nachher davon runter. Das ist irgendwie blöd. Stash ist einfach eine Möglichkeit zu sagen, alles, was gerade geändert ist, bitte mal parken und wieder auf den letzten Stand zurück, auf dem ich war. Also den letzten Stand von dem Branch, auf dem ich gerade bin oder vom Master, was auch immer. Und dann ist seine Working Copy wieder sauber und da kannst du irgendwas arbeiten und dann kannst du zum Beispiel irgendwie Master auschecken oder den Branch, an dem der Kollege gerade arbeitet, dann kannst du den fixen, dann machst ein Commit und push das Ganze und dann mit Stash Pop holt man es vom Stash runter, also man fügt es wieder in die eigene Kopie ein und löscht auch gleich vom Stash. Weil man kann auf dem Stash auch mehr als eine Zwischenversion speichern. Weil wenn man selten ist, ist aber möglich. Das heißt, wenn man da gerade drin ist und sagt, verdammt, ich muss jetzt mal was anderes machen, dann kann man das so in die Zwischenablage und dann wieder zurück. Ist manchmal echt extrem praktisch. Genau, wenn man gerade bei den ganzen Gits Befehlen sind, will ich mal ein paar Vorstellen, die vielleicht manche nicht kennen. Es gibt zum Beispiel hier bei Git Add, das ist auch wenn man mit der Maus drüber geht, sieht man unten immer so eine kleine Erklärung. Da gibt es einen Zusatzbefehl, der nennt sich Patch Mode. Also Git Add minus P, der ist jetzt hier da, der den ich dokumentiert. Da kann man von mehreren Änderungen, die man in der Datei hat, einzelne Änderungen auf den Index packen. Also wenn man sagt, man hat in der Datei viele Zeilen Code geändert und will jetzt aber nur ein paar davon committen, dann kann man eben mit diesem Patch Mode, einzelne Änderungen hinzufügen. Da wird man gefragt, willst du diese Änderungen hinzufügen, dann sagst du ja oder nein und so weiter. Das ist zum Beispiel ein Befehl, der hier leider auch nicht erklärt wird. Ein anderer, der mir gerade auffällt, der ist glaube ich nirgends drin. Nee, also auch die Referenz ist nicht ganz vollständig, es sind die wichtigsten. Es gibt einen Befehl, der nennt sich Bisect. Und zwar hat er so den Hintergrund, wenn man irgendwie längere Zeit an einem Repository gearbeitet hat und man stellt irgendwann fest, da ist ein Fehler. Und jetzt will man feststellen, wann kam denn dieser Fehler rein mit welchem Commit und wie kann ich ihn rückhängig machen. Dann könnte man das natürlich hingehen und jeden einzelnen Commit nacheinander zurückgehen, um den Fehler zu finden, was sehr mühselig ist. Und dieser Bisect Befehl ermöglicht einem das schneller zu finden. Man sagt, die Version, die ich gerade habe, ist kaputt und die Version weiß ich, da hat es noch funktioniert. Und dann macht Git eine binäre Suche. Das heißt, der teilt einfach die Anzahl der Commits in die Hälfte, checkt diesen Commit aus, dann kann man testen, funktioniert es oder funktioniert es nicht. Also man sagt dann Git ja, ist kaputt oder nein, ist nicht kaputt. Und dann nimmt da wieder die Linken oder rechte Hälfte je nachdem. Das heißt, man ist sehr, sehr schnell an der Stelle, wo man dann den Fehler gemacht hat. Das ist so ein Befehl, den findet man in wenigstens Dokumentation, aber es ist so ein Befehl, wo du sagst, wenn du wirklich mal so ein Fehler hast oder willst du wissen, wann hat sich denn das geändert und willst nicht durch 100 Commits durchgehen, dann ist es echt praktisch. Also so ein Befehl kann man sich mal merken. Bicect heißt ja, der ist ja nicht drauf. Ja, genau, also es gibt in der offiziellen Seite git-scm.com, gibt es auch eine Dokumentation. Das Problem hier ist nur, die ist extrem technisch an manchen Stellen. Also es ist eine sehr detaillierte Dokumentation, teilweise auch mit langen Erklärungen und Beispielen. Also hier sieht man jetzt so ein Beispiel für git-bicect. Man sagt, hier git-bicect start. Und dann sagt man hier mit bad, die Version, auf die ich gerade bin, ist schlecht. Und mit bisect good kann man sagen, jetzt in dem Fall ein tech, in der Version was gut. Und dann sagt da hier bisecting, also 357 revisions. Roughly 10 steps. Also er kann schon so, die nähere Suche kann ungefähr abschätzen, wie viele Schritte man braucht, um bis zur Lösung zu kommen. Und dann nimmt er halt den mittleren Commits und dann fragt er, wer da, oder dann testet man und dann sagt man, gut oder schlecht. Und dann sagt er halt wieder, okay, jetzt habe ich noch die Hälfte, 337 und so weiter. Und irgendwann sagt man dann 30 select und dann hat man gesagt, okay, jetzt hier, das ist der, der böse ist. Und dann kann man dann den reverten oder irgendwie ein patch schreiben oder sonst was. Also das ist echt ein ziemlich schöner Befehl, wenn man mal schnell auf eine Fiedersuche gehen will. Genau. Von den Empfängern weiß jeder, was github ist. Wofür das da ist und wie man es benutzt. Ja, alle nicken, können wir gucken. Also neben github gibt es auch noch andere Plattformen. Es gibt zum Beispiel github.com, ist in letzter Zeit sehr populär geworden, nachdem github von Microsoft aufgekauft wurde. Das fanden manche nicht so toll. Ich persönlich sehe da kein großes Problem dabei. Auch vor dem Hintergrund, wenn man über das Microsoft, einer der größten Contributor zu Open Source Software ist, was man jetzt nicht so denkt, weil das ja alles proprietär ist, wenn man an Windows und Office denkt. Aber zum Beispiel Visual Studio Code, was ich ja schon erwähnt hatte, ist komplett Open Source, also die Community Variante davon. Und ich glaube auch nicht, dass github da jetzt irgendwie großartig sich verändert. Aber manche fanden es nicht so toll und sind deswegen zu GitLab gewechselt. Wie gesagt, es gibt noch Bitbucket von Adleschen. Und die Idee von diesen Plattformen ist, dass man die Zusammenarbeit an Projekten irgendwie in die Öffentlichkeit tragen kann. Und wir hatten ja vorgestern diesen Hackathon zum Plug-in-Kollektiv und gestern den Contributor Day. Und so ein Konzept, was bei github und GitLab immer so ein bisschen für Verwirrung sorgt, sind Forks und Branches und Pulled Requests oder bei GitLab heißen die Merch Requests. Und wie genau die funktionieren. Also die Idee dahinter ist einfach, wenn man an einem Projekt mitarbeitet, dann hat man nicht unbedingt die Rechte an diesem Preco zu ändern. Und dann gibt es halt bei github den Workflow eines Forks. Das heißt, man macht ein Kopie davon, dass man dann unter seinem eigenen Benutzernamen kann dann Code darin ändern und kann dann so genannten Pulled Requests stellen. Also man kann sagen, lieber Entwickler von diesem Projekt, ich habe hier mal was verbessert, möchtest du vielleicht diese Verbesserung in deinen Code übernehmen. Und dann kann er halt entscheiden, ob er das macht oder nicht. Das ist gerade für die Theme- und Plug-in-Entwickler unter euch vielleicht spannend. Also bei mir ist es mittlerweile so, dass alle neuen Plug-ins von mir immer auf github gehostet sind, die alt noch nicht alle. Weil der Vorteil davon ist, dass wirklich jeder kontributen kann. Also wenn man sie nur in dem offiziellen Subversion Repository von WordPress hat, dann könnten sie in Support-Forum meines Plug-ins vielleicht schreiben, ich habe hier einen Fehler in Zeile 128, da fehlt noch ein Komma oder kannst du mal hier oder da oder gib mir mal da eine E-Mail-Adresse, damit ich dir ein Patch per E-Mail schicken kann, damit du den appellieren kannst. Das ist alles ein bisschen blöd. Und deswegen habe ich zum Beispiel entschieden zu sagen, ich hoste meine ganzen Plug-ins auch auf github, damit eben Leute relativ vielleicht damit arbeiten können. Der Nachteil dabei ist, wenn ich jetzt diese Plug-ins von github ins Plug-in Directory kriegen will, muss ich so einen Umweg gehen und das irgendwie wieder in den Subversion Repository kriegen, um das dann wieder per Subversion zu kommen. Das ist so ein bisschen nervig. Und deswegen muss ich gestehen, dass ich meine Plug-ins auch nicht so häufig aktualisieren, zum Beispiel die Informationen, bis zu welcher WordPress Version funktioniert mein Plug-in. Weil einfach dieser Workflow so ein bisschen blöd ist. Genau. Jetzt hat man eine Frage, was sind so eure Bauchschmerzen bei github? Gibt es irgendwie Dinge, die ihr nicht versteht, Workflow, die ihr nicht versteht, Probleme, die ihr mal gefunden habt oder vielleicht tolle Tricks, die man mal teilen könnte? Wollte es ja so ein bisschen als Q&A machen. Github Rebase. Also die Frage war, wie ist das mit Github Rebase? Das ist der Grund, wenn man ein Pull request aufgemacht hat und dann zu einem Konflikt kommt, weil zum Beispiel eine Datei unbenannt wurde, eine Ordnung unbenannt oder eine Datei verschoben. Wie kann man den eigenen Pull request reparieren? Ich habe jetzt, glaube ich, leider kein Repo, wo das der Fall ist. Nee, das beim Plug-in-Kollektiv haben wir korrigiert. Also oft ist es so, wenn man so ein Pull request hat, dann kann es eben vorkommen, dass ganz am Ende nicht steht, wie hier Merge PullQuest, sondern statt hier der Snow-Konflikt, es gibt ein Konflikt. Du musst den beheben. Kann ich mal gucken, ob vielleicht in dem zweiten Pull request einer ist, ist keiner. Maya schaut gerade mal, ob sie einen hat. Man muss dazu sagen, dass solche Konflikte unter gibt sehr viel seltener sind als unter Subversion. Nichtsdestotrotz passieren sie sehr, sehr häufig. In welchem Projekt ist es? Ja, 161. Genau. Da gibt es schon wieder ein Konflikt. Interessant. Genau, also jetzt haben wir hier Konflikting-Pfiles. Um einen Konflikt zu beheben, kann man zwei Dinge machen. Man kann entweder einen Merge machen oder, was Sören eben meinte, ein Rebase. Wir können ja gerade mal auf die Dokumentation von Atlaschen gehen und uns mal die Unterschiede zwischen Merge und Rebase raussuchen. Nee, da ist die Suche. Warte mal, hier Merge-Konflikt. Weil die visualisieren das immer ganz schön. Wobei, da fällt mir gerade ein Git-With-Gitlands. Ach ja, genau. Git pur. Es gibt so eine coole Variante Git zu erklären. Und zwar hat sich da eine Entwicklerin mal die Mühe gemacht, Dinge in Git zu erklären, indem sie Ketsin verwendet. Und zu erklären, was ist ein Merge, was ist ein Branch? Und es gibt hier so ein schönes Ding. Der Unterschied zwischen Merge und Rebase. Ich weiß nicht, ob man das jetzt hier so gut erkennen kann. Aber die Idee hinter Merge und Rebase ist, also man sieht das hier bei Git-Merge, also es gibt hier eben die Kätzchen. Und da bekommt das Kätzchen hier irgendwie eine Fliege und das andere Kätzchen bekommt ein bisschen Farbe. Und der Merge ist... Ach so, ja, warte mal, ich kann es mal... Also man sieht, das ist jetzt hier der Branch. Tabby heißt der. Und hier kommt eine Schleife oder Fliege, wenn ihr nach dem was nehmt. Und hier kommt dann noch ein bisschen Farbe ins Spiel. Und jetzt werden diese beiden Änderungen zusammengefügt und in einem Merge passiert es so, dass ein neuer Commit entsteht. Und in diesem Commit werden diese beiden Variationen zusammengeführt. Das heißt, man hat dann am Ende ein Kätzchen mit einer Schleife und der Farbe. Das ist so, wie ein Merge funktioniert. Bei einem Rebase ist es jetzt so, man hätte diesen Branch und statt einen Commit zu erzeugen, in dem beide Änderungen zusammengefügt werden, verschiebt man die Commits ans Ende von den anderen. Das heißt, man hat hier oben diesen Master Branch, wo das Kätzchen schon eine Fliege hat. Und dann kommt auf diesen Stand die Änderung der Kopf wird eingefärbt und dann wird der Körper und der Schwanz eingefärbt. Das heißt, man verändert die History von diesem Branch und hängt die neuen Commits ans Ende des aktuellen. Der Vorteil dabei ist, es entsteht kein neuer Merge-Commit. Das heißt, die History ist etwas sauberer. Und gerade, wenn man so einen Pull request hat, wo in der Zwischenzeit sehr viel auf Master passiert ist. Also, man hat einen Pull request aufgemacht und der ist drei Monate alt. Und auf Masters sind mittlerweile 200 Commits passiert, aber im eigenen Pull request ist nur ein Commit, dann ist die Wahrscheinlichkeit sehr, sehr groß, dass man einen Rebase machen kann. Das heißt, man sagt, ich nehme den aktuellen Stand von Master, wie er jetzt gerade ist und hänge meine Änderung hinten dran. Und da ist auch die Wahrscheinlichkeit sehr hoch, weil es geht dann einfach feststellt, was ist so der letzte Stand von Master und was ist die Änderung, die ich machen will und geht erkennt dabei auch oft, dass eine Datei einfach nur umbenannt wurde und kann dann diese Änderung an die richtigen Zeile einfügen. Die Alternative wäre eben, dass man einen Merge-Commit macht und dann entsteht in dem eigenen Branch erst mal die ganze Liste von den Commits, die auf Master passiert sind, plus dann diesen einen neuen Merge-Commit. Aber über beide Varianten kann man diesen Konflikt aufheben. Wir können jetzt einfach mal versuchen, diesen Pull-Quest hier zu reparieren. Schauen wir mal, ob das klappt. Ja, ja, ich mach's kurz an. So, ich klone mir jetzt einfach mal das Repo hier. Also, hier kein SSH hinterlegt. So, machen wir das mal auf. Anti-Spambi. Und wo war jetzt der Konflikt? Anti-Spambi PRP zum Beispiel. Ach ja, genau. Ich müsste jetzt erstmal noch den Fork von Maya an mir holen. Ach nee, das war jetzt falsch ausgetauscht. Da fehlt auch noch. So, jetzt. Sieht jedem klar, was ich hier mache. Also, Maya hatte ein Fork von diesem Repository gemacht. Und ich kann mir jetzt getRemote... Aber ich habe mir gerade die Well kopiert. Eigentlich sollte er das finden. Hä? Findet den Fehler. Richtig. Ach ja, richtig. Danke. Geklont, aber noch nicht im Ordner gewesen. Deswegen jetzt sagt er, not a Git Repository. Ach ja, jetzt habe ich den Namen. Nee, also ich... Man kann in einem Git Repository mehrere Remotes haben. Remote ist das hier, Remote Repositories. Das heißt, das ist ein Repository, zum Beispiel in dem Fall beide auf GitHub, zudem ich Änderungen hinschieben könnte oder von dem ich Änderungen holen. Und jetzt hole ich mir von dem anderen Remote erstmal alle Branches mit Fetch. Und jetzt sehe ich hier die ganzen Branches, die Maya in ihrem Fork hat. Und jetzt kann ich hier den Ali-Branch mir auschecken. Das war, glaube ich, der Richtige. So, jetzt bin ich auf diesem Ali-Branch. Und jetzt können wir diesen Konflikt, wie gesagt, auf zwei Weisen auflösen. Wir können entweder ein Rebase machen oder ein Merch. Wir können ja mal gerade gucken. Es gab hier vier Komits. Und wahrscheinlich ist nur der letzte Komits ein Konflikt, weil ich hatte gestern oder vorgestern auch dran mitgearbeitet. Da war es noch okay. Das heißt jetzt nicht, dass Maya Schuld ist, sondern eher, wie auch immer, in Plug-in-Kollektiv was aktualisiert hat, halt halt dadurch ein Merch-Commit verursacht. Was ich jetzt hier mache, ich merge mir jetzt Origin Master hier rein. Oder wollte dann Rebase. Wer ist für Merch? Genau, das können wir jetzt einfach mal gucken. Also, sie hat am 24.Nummer, wenn wir 2017 den Branch aufgemacht. Und was? Das ist aber echt lange her. Ach ja, stimmt. Also, da wir jetzt sehen, der Branch ist schon sehr, sehr alt. Und Antis Bambis, eins von denen Plug-ins, wo wir sehr viel machen, ist wahrscheinlich die schlechtere Variante Merch zu machen, weil einfach sehr viele Komits zwischendrin waren. Das heißt, in dem Fall würden wir ein Rebase machen und versuchen, diese vier Komits hinten dran zu hängen. Also, wir machen hier diese schöne Variante. Also, wir machen jetzt hier ein Rebase. Und jetzt holt sich, geht erstmal den aktuellen Stand von Origin Master und dann versucht er, die vier Komits hinten dran zu hängen. Und jetzt sehen wir hier schon Konflikt. Es gab hier in der CSS-Style-Mins-CSS einen Fehler. Dazu ist wahrscheinlich zu sagen, dass das wahrscheinlich mit Sass gemacht ist. Genau, es gibt hier eine Styles und eine Styles-Min. Und das Problem ist jetzt einfach, dass die neue Minifizierte Version Fehler hat, was bei Minifizierten Versionen meistens passiert. So, und das ist immer so, oben hat man den Teil aus dem Original Repository und unten hat man den Teil aus dem eigenen. Jetzt müsste man diesen Komits aufräumen. Jetzt müssen wir es mal gerade mal gucken. Ach ja, genau. Wir sehen das auch hier unten im Terminal, wenn wir das auf Termal-Ebene machen. Wir sind jetzt gerade in einem Detached-Head, weil ich einen Tag ausgeschickt habe von Maya und bin gerade im Re-Basing beim ersten von drei Komits. Das heißt, da hat er jetzt eine Pause gemacht und da ist jetzt sehr viel aufgetaucht. Jetzt müssen wir versuchen, den zu beheben. Jetzt muss ich mal gerade gucken, wie denn hier die Minifizierung überhaupt passiert ist. Ich hoffe mal, dass da irgendwie, nee, da ist kein Grunt, kein, ja. Man sieht leider nicht, wie derjenige, der den Codes geschrieben hat, das Ganze minifiziert hat. Im Optimal verwehr es hier irgendwie ein Gruntfalt drinnen oder ein NPM mit einer Minifizierungsfunktion. Die fehlt jetzt ja leider, was natürlich ziemlich blöd ist, weil wir könnten jetzt, ein Komposer, nee, wie das generell in dem Projekt minifiziert wurde. Was haben wir hier? Ist Brain Monkey, ist glaube ich, kein Minifizier, oder? Nee. Ja, das ist natürlich jetzt doof. Also, keine Ahnung, wie das jetzt hier minifiziert wurde. Jetzt haben wir praktisch das Problem, also Maya hat wahrscheinlich im CSS was geändert, oder das gucken wir uns einfach mal an? Was hat sich? Aber 2017 war Särge schon nicht mal dabei. Das hat einer von uns verbrochen. Ja, was wurde hier an der Min CSS irgendwas geändert, sonst gibt es ja keinen Konflikt. Ich guck mal also, im ersten Komet nicht, im zweiten Komet hat sie in das Style CSS was geändert und nicht, doch in der Min hat sie auch was geändert. Nee, die haben irgendwie, die war vorher, das ist komisch. So, wir machen das jetzt einfach. Bei so minifiziert Dateien ist der Trick, also gerade auch wenn man mit Sass arbeitet, die kompilieren ja irgendwie in der CSS Datei heraus, ob die jetzt minifiziert ist oder nicht. Wer meinen Tipp einfach, man nimmt eine von den beiden Versionen, nehmen wir jetzt einfach mal die Version von Maya. So, dann speichern wir das. Wenn wir uns ein Git Status machen, dann sieht man immer, was müsste man jetzt machen, um diesen Fehler zu beheben. Also, ich habe ja einen Unmerged Perth, diese Style CSS, wenn ich die mit Add auf ein Index hinzufüge, dann habe ich den Fehler behoben. So, um den Fehler jetzt wichst, zu beheben, geben wir einfach mal hin und nehmen hier die Style CSS, die Normale, und nehmen wir einfach so ein Online-Mini-Fire, weil wir das keinen haben. Wo sind wir jetzt hier? Das fügen wir jetzt hier ein. Da hat sich ein bisschen mehr geändert, irgendwie. Okay, irgendwie sind da die Fonts rausgeflogen. Die lassen wir mal noch drinnen. Nehmen wir mal nur den Teil hier. Das sieht ja irgendwie nach ein bisschen Änderung aus, könnte passen. Also, im klassischen Fall würde man dann halt den Mini-Fire verwenden oder wenn man SAS verwendet, einfach den SAS-Compile nochmal anschmeißen und sagen, erzeug mir mal die Datei neu. Deswegen geht auch sogar ganz viel dazu über zu sagen, die minifizierten Dateien oder komplierten Dateien, die kubind ich gar nicht erst ins Repository, weil das Dateien ist immer knallt. Oder man sagt, wenn man SAS verwendet, dann hat man die komplierte Datei drin, aber die dann nicht in der Minified-Version, sondern in der Expanded-Version, damit es eben nicht ständig knallt. Frage? Genau, also man könnte es dann lokal klonen auf dem Live-System oder man könnte halt, wenn man zum Beispiel GitLab verwendet, könnte man sagen, der GitLab Server erzeugt dann aus dem Repository jedes mal ein Bild und da würde dann einfach dieser Minifizierer drüber laufen. Genau, also wir haben jetzt diesen Fehler behoben und jetzt machen wir GitAdd und dann machen wir GitRebaseContinue und dann geht es weiter. So, jetzt haben wir wieder ein Konflikt. Es ist wieder die Style-CSS. Schauen wir mal rein, was da ist. Ah-ha. Copy-Genders removed from min. Okay. Schauen wir mal rein, was hier jetzt passiert ist. Das war so, gell? Das ist ja eine tolle Änderung. Also eigentlich habe ich hier nur ein Zeilenobruch entfernt. Also ich pushe das gleich nicht, vielleicht haben wir irgendwas falsch gemacht, jetzt gucken wir mal noch mal in GitStatus rein. Na, das ist interessant, die Style-CSS würde gelöscht, auch interessant. Ja. So, vielleicht haben wir jetzt beim dritten Glück uns keinen Kopf, jetzt ist mal die PAP-Datei. Ja, das ist ein gutes Beispiel. Das ist halt so dieses Problem, wenn man so long-running Branches hat, die irgendwo über ein Jahr rumlegen, dann ist die Wahrscheinlichkeit, dass da irgendwas passiert, relativ groß. Deswegen ist es bei Git eigentlich oft so, dass so ein Branch nur ein, zwei Tage lebt, im besten Fall, oder sogar nur eine halbe Stunde. Also man ist da sehr schnell beim Branching und Merging, also im Gegensatz zu Subversion, wo allein ein Branch erzeugen teilweise, eine Mittagspause lang dauert. Geht es hier relativ schnell? Deswegen sollte man Branches nach Möglichkeit relativ schnell integrieren. Wenn man natürlich irgendwie an so einem großen Projekt mitarbeitet, ist das nicht unbedingt immer begeben. So, was haben wir hier? Der Konflikt. Konflikte fangen immer an mit diesen Pfeilen hier. Dann kommt der Commit-Name oder Branchesname, von dem Originalzweig. Und dann kommen hier mehrere Ist-Gleichzeichen und dann kommt so das Ende. Das heißt, in dem Fall ist jetzt hier der Unterschied und da wurde die MIN-CSS rausgenommen und du hast dann die normale Style-CSS reingeladen, weil du wahrscheinlich keine Änderung gesehen hast. So, das nehmen wir jetzt hier raus. Das nehmen wir auch raus. Das heißt, wir haben uns eigentlich entschieden, nicht die minifizierte Version zu nehmen. Das Schönste ist, dann können wir gleich noch einen zweiten Fall machen. Und dann gibt es Status, damit wir uns noch mal angucken. Also hier Modified, dann fügen wir die hinzu und dann machen wir Rebase Continue. Was habe ich gerade vergessen? Eigentlich musste das gar nicht. Das Problem ist manchmal, wenn man eine Änderung macht und in der Änderung nichts mehr passiert. Genau, das ist das Schöne. Wenn man irgendwie nicht weiter weiß, dann macht man einfach den Befehl mit minus minus help. Meistens öffnet sich dann das Ganze im Browser. Genau, und jetzt haben wir glaube ich diesen Fall KeepEmpty. Also ich habe jetzt eine Änderung gemacht, die effektiv nix macht. Ich habe zwar was hinzugefügt, aber es passiert eigentlich nix. Und jetzt kann ich hier sagen KeepEmpty. Das heißt, ich mache jetzt ein Commit in dem Rebase, wenn man kein Inhalt hat. Oder okay, kann auch sein, dass Container weglassen muss. Macht er nicht. Dann skipen wir den einfach. Wenn sowieso nix passiert. So, jetzt kommen wir nochmal, geht Status. Wir sind jetzt hier auf diesem Branch und haben den Merch Commits gelöst. Was man jetzt auch machen kann, wir haben jetzt hier festgestellt, da ist eigentlich relativ wenig passiert. Wir haben jetzt noch ein paar Changes angucken. Was ist da so insgesamt passiert, dass sich gar nicht so viel. Man kann bei Git einen sogenannten interaktiven Rebase machen. Und zwar ist das Vorgehen da, dass er einen Rebase immer auf irgendeinen Commits oder Branch oder Tech macht. Und dann kann man für jeden Commit entscheiden, will ich den annehmen, will ich ihn ignorieren oder will ich ihn mit einem anderen zusammenfügen. Also, wenn ich jetzt hier in Git, oops, Rebase minus Interactive mache auf Origin Master. Wir haben übrigens eben gesehen, wir haben drei Commits im Rebase gehabt. Wir haben aber hier vier Commits. Woher kommt das? Das kommt daher, dass alle Merch Requests automatisch gelöscht werden. Weil der Merch Request selbst eigentlich keinen Inhalt hat. Das ist nur in Zusammenführung von zwei Strengen. Das heißt, wenn ich ein Rebase mache, dann werden die ganzen Merch-Commits gelöscht. Das ist ganz sinnvoll, wenn man zum Beispiel den eigenen Branch sehr häufig merkt von Master, damit man den letzten Stand von Master drin hat, damit nicht so einen schnellen Konflikt passiert. Kann man mit diesem interaktiven Rebase oder generell mit dem Rebase sagen, nehmen wir diese ganzen Merch-Commit wieder raus. So, jetzt machen wir hier mal ein interaktiv Rebase. Den Befehl finde ich wirklich gut, weil da einfach so, wenn man, gerade in den Pulling Quests, gibt es dann auch, dann fängt man an zu diskutieren und dann sagt man, könntest du das noch machen, könntest du das noch machen. Und dann nehmen wir ganz, ganz viele kleine Commits dran, die eigentlich so vom Inhalt hier keine große Relevanz haben. Irgendwas, was man gemacht hat, was man geändert hat, was irgendwie an sich eine Änderung ist, die wichtig ist. Und hier der Message ist, keine Ahnung, vielleicht einfach nur die Commit-Nachricht geändert. Und was ich jetzt hier bei dem interaktiv Rebase machen kann, ich sage, den ersten pick ich und dann ist hier unten eine Anleitung, was ich noch machen kann. Und beim zweiten kann ich sagen, den Squash ich. Dann kann ich einfach nur S sagen. Dann speichere ich den Datei. Und jetzt werden diese beiden Commits zusammengehügt von Git. Und jetzt wird gefragt, was ist jetzt der neue, die neue Commit-Nachricht für den neuen Commit entsteht und dann nehme ich jetzt einfach nur die zweite Nachricht. So, das ist nicht, warum das jetzt so lang dauert. So, wollen wir uns jetzt mit Git-Status das Ganze angucken? Okay, sehen wir nix. Genau, also man würde jetzt aber normalerweise sehen, wenn ich auf dem Branch wäre, ich hätte jetzt noch einen Commit und den könnte ich jetzt pushen. Also das ist so, wie man ein Rebase einsetzen kann, um so ein Merch-Konflikt zu lösen. Das heißt, wenn ich das jetzt zurückpushen würde nach GitHub, mache ich jetzt nicht, weil ich will es mir noch mal genau angucken, was da passiert ist. Dann würde halt hier vorne in der Conversation dann unten nicht mehr stehen. Ist defekt, sondern ist resolved. Das Schöne ist, wenn ich jetzt Zugriff auf dieses Repo hätte, könnte ich auch direkt sagen, ich resolve den in GitHub. Das heißt, das, was ich jetzt so lokal gemacht habe, mit zu entscheiden, was ist der richtige Fall, das kann ich mittlerweile direkt in GitHub machen. Und da geht ja auch die einzelnen Commits durch und kann dann direkt in GitHub das Resolven machen, das ist sehr praktisch. Jetzt mit dem Minifizieren und mit Sass kumpelieren, ist dann natürlich blöd. Das geht da nicht, aber wenn es so ein einfacher Fehler ist, kann man das direkt in GitHub machen. Noch andere Fragen? Nein, wir haben noch eine viertel Stunde. Genau, ich habe hier, wenn ich nochmal reingehe, ich habe in, ich habe ja einen, also, ich zeige nochmal kurz. Was wir hier sehen, ist die lokale Working Copy und das lokale Repository. Und GitRemotes kann man mehrere haben, beliebig viele. Und ich habe jetzt hier einmal das sogenannte Origin, das ist meistens für mich irgendwie so ein Clone von GitHub macht, so das Hauptziel. Und das hier unten ist ein Branch, ein anderer Fork. Das ist ganz offen, wenn man zum Beispiel irgendwas, wenn man selbst so ein Fork macht, dann hat man Origin ist der eigene Fork und den anderen nennt man meistens Upstream, also das Original Text. Das ist nicht ungewöhnlich, dass man mehrere Remotes in einem Report. Ja, also, okay, müssen gleich Schluss machen, aber die Frage beantragt. Also der Fall, wo es am häufigsten vorkommt, ist, nehmen wir jetzt nochmal das Beispiel hier, Maya hat einen Fork gemacht von dem Plug-in-Kollektiv Anti-Spambi. Und wenn sie jetzt die Änderung haben, will die im Plug-in-Kollektiv passiert sind, auf Master zum Beispiel, dann muss sie Plug-in-Kollektiv als zweiten Remote hinzufügen. Und dann macht sie einen Pull von Upstream Master, vom Plug-in-Kollektiv, und macht einen Push nach Origin Master, also ihren eigenen Fork. Das ist so der Weg, wenn man es macht. Das heißt, man holt sich aus einem Remote die Änderung, die landen dann hier, deswegen sieht man hier auch Push und Pull, und dann schiebt man sie aufs eigene. Gut, Maya sagt, ich muss Russe machen.