00:00:00Hallo zusammen, ich bin Scott, der CEO von GitButler.
00:00:02Heute werde ich euch einige der coolen Funktionen von GitButler zeigen und euch
00:00:05einen allgemeinen Überblick geben, was dieser Git-Client alles kann.
00:00:07Ich habe hier ein Beispielprojekt. Ein kleiner Twitter- bzw. X-Klon namens "Y".
00:00:12Ich werde jetzt einige Änderungen hinzufügen, die ich bereits vorbereitet habe, und wir werden
00:00:16sehen, wie man Commits erstellt, Branches anlegt, parallele Branches nutzt und
00:00:20wie man Stacked Branches erstellt. Wenn ich Dateien bearbeite, sieht man etwas Ähnliches
00:00:25wie bei der Ausgabe von "Git status", die anzeigt, welche Dateien im Arbeitsverzeichnis geändert wurden.
00:00:30Was wollt ihr damit machen? Wie wollt ihr sie committen? Hier können wir sie prüfen.
00:00:34Ich kann in mein CSS, die Sidebar oder die Index-Datei schauen. Da sind ein paar kleine Änderungen,
00:00:39die ich gemacht habe. Nun möchte ich einen neuen Branch erstellen und diese Änderungen dort
00:00:45committen. Es gibt verschiedene Wege, das zu tun. Ich kann einfach auf "Commit to new branch"
00:00:49klicken oder hier explizit einen neuen Branch erstellen. Ich erstelle einen unabhängigen Branch,
00:00:54keinen abhängigen Branch. Zu den Stacks kommen wir gleich noch.
00:00:57Man gibt einen Namen ein, erstellt den Branch, und nun gibt es verschiedene Möglichkeiten. Man kann
00:01:03einfach Sachen committen. Ich kann zum Beispiel nur diese application.css-Datei committen,
00:01:08indem ich sie entweder in die Lane ziehe oder den Commit direkt von hier aus starte.
00:01:15Man kann entweder eine kurze Nachricht in dieses kleine Feld schreiben oder es ausklappen
00:01:19und hier eine ausführliche Commit-Nachricht verfassen. Halten wir es erst mal einfach.
00:01:27Ich kann auch entscheiden, was genau in diesen Commit kommt. Ich habe hier drei Dateien.
00:01:34Ich kann nicht nur sagen, dass ich eine Datei nicht will, sondern auch in die Datei gehen und nur spezifische Zeilen wählen.
00:01:39Aber für den Moment committen wir einfach alle Änderungen. Oder wisst ihr was, machen wir
00:01:44zwei verschiedene Commits. Die Sidebar-Sachen will ich hier nicht dabei haben. Also: "Front-end fixes",
00:01:48und dann ein weiterer Commit: "Sidebar fixes". Jetzt habe ich zwei Commits in diesem neuen Branch.
00:01:55Ich bin ein bisschen faul, also lasse ich Claude Code diese Arbeit für mich erledigen. Ich ändere
00:01:59das Design von Blau auf Rot und dann schauen wir uns an, wie wir einen separaten Branch dafür erstellen,
00:02:04getrennt von meinen Frontend-Fixes. Das scheint fertig zu sein. So sah die Website vorher aus.
00:02:09Wie ein kleines Twitter-Ding. Wenn ich die Änderungen jetzt anwende, haben wir ein schickes rotes Design
00:02:14und meine Frontend-Änderungen sind auch drin. Man sieht hier: Das sind unabhängige
00:02:18Branches. Wenn ich den Stack für die Frontend-Fixes deaktiviere, bleibt es rot, aber die Fixes sind weg.
00:02:25Das habe ich hier gemacht. Ich kann sie wieder hinzufügen. Und jetzt sind sie wieder da.
00:02:34Oder dasselbe umgekehrt: Ich deaktiviere das rote Theme, und es ist nicht mehr rot. Aktivieren wir es wieder.
00:02:43Jetzt haben wir zwei verschiedene Branches. Das Coole daran ist: Wenn ich das zu GitHub pushe,
00:02:48sind diese Änderungen voneinander getrennt. Aber sie sind beide gleichzeitig aktiv.
00:02:52Es ist wie Git-Branches, nur dass man an mehreren gleichzeitig arbeiten kann.
00:02:57Wenn ich also weiter an etwas in der Sidebar arbeite, erscheint es hier. Und ich kann
00:03:04verschiedene Dinge tun. Ich kann es hier reinziehen und den Commit sogar ergänzen (amend).
00:03:10Ich könnte es auch als neuen Commit auf diesem Branch speichern. Jetzt haben wir zwei parallele Branches.
00:03:14Schauen wir uns einen anderen Weg an. Nehmen wir an, das rote Theme hängt von den
00:03:18Frontend-Änderungen ab. Ich möchte also erst das Frontend mergen, bevor ich mir
00:03:24die roten Sachen anschaue, oder alles zusammen mergen. Machen wir diesen Commit rückgängig.
00:03:29Wir machen ein "Uncommit" und erstellen stattdessen einen Stacked Branch.
00:03:37Also: Uncommit, Stack deaktiveren. Jetzt fügen wir hier einen neuen abhängigen Branch hinzu.
00:03:42Man klickt auf "New Branch" und wählt "Dependent Branch". Eine andere Möglichkeit ist diese:
00:03:47Man sagt "Create dependent branch" und fügt die Frontend-Fixes als Basis hinzu. Nennen wir ihn
00:03:51"sc_red_theme". Jetzt sieht man, dass diese Branches gestapelt (stacked) sind. Ich kann das nehmen
00:03:58und in diesen Branch committen. Wenn man solche Stacked Branches hat, kann man sie zu GitHub pushen.
00:04:06Das ist sehr einfach. Wenn die GitHub-Integration eingerichtet ist, kann man auch
00:04:11einen Pull Request erstellen. Wenn ich einen Pull Request erstelle, zum Beispiel für das rote Theme,
00:04:16wird bei einem Stacked Branch automatisch ein Hinweis in die PR-Beschreibung eingefügt,
00:04:20dass dieser Branch von einem anderen Ziel-Branch abhängt. Man muss dann
00:04:25entweder alle zusammen mergen oder die Frontend-Fixes vor dem roten Theme. Das ist eine
00:04:30sehr elegante Methode für Stacked Branches. Wenn ich mir diesen PR jetzt anschaue, sind beide
00:04:34in einem Stack verknüpft. Das ist Teil zwei im Stack, das ist Teil eins, und sie
00:04:39bauen aufeinander auf. Eine weitere coole Sache ist das, was wir
00:04:43"Assigning to branches" nennen. In diesem Fall habe ich zwei Lanes und drei Branches. Zwei davon
00:04:48sind gestapelt, einer ist unabhängig. Wenn ich Änderungen vornehme, kann ich
00:04:54Hunks (Code-Blöcke) zuweisen. Ich kann Änderungen einem bestimmten Branch zuordnen, während ich weiterarbeite.
00:05:00Jede Lane hat also ihren eigenen, unabhängigen Staging-Bereich. Es ist so, als würde man
00:05:05"git add" ausführen, nur dass man mehrere unabhängige Staging-Bereiche gleichzeitig hat.
00:05:09Probieren wir das aus. Ich füge ein neues Feature hinzu: einen kleinen Bereich auf der Admin-Seite.
00:05:14Ich packe das in einen eigenen Branch, im selben Arbeitsverzeichnis, in einem
00:05:19neuen, unabhängigen Branch, und kann einen PR eröffnen, der nur diese Änderungen enthält.
00:05:24Okay, so sah das Admin-Dashboard vorher aus. Ich habe einige Änderungen bei den
00:05:31letzten Neuanmeldungen gemacht. Ich habe diese zwei Änderungen hier und möchte sie
00:05:37dieser Lane zuweisen. Wenn ich nun weitere Änderungen mache, werden sie unter "unassigned" landen,
00:05:43falls das System sie nicht zuordnen kann. Wenn sie im selben Hunk liegen, bleiben sie automatisch in der zugewiesenen Lane.
00:05:47Machen wir mal ein paar Änderungen im Admin-Controller. Nur ein simpler Kommentar, aber
00:05:55schauen wir mal, was passiert. Da der Admin-Controller dieser Lane bereits zugewiesen war,
00:06:00muss ich ihn nicht erneut stagen. Das Programm merkt: "Das gehört auch zu dieser Änderung"
00:06:05und fügt es dort ein. Erstellen wir einen neuen Commit dafür. Ich starte den Commit erneut.
00:06:10Ich kann das Feld wieder vergrößern für eine ordentliche Nachricht. Ich kann auch KI nutzen,
00:06:15um Commit-Nachrichten zu generieren, falls ich einen Entwurf brauche, den ich dann bearbeiten kann.
00:06:19Die KI analysiert die Änderungen und liefert einen guten Startpunkt. Okay,
00:06:23jetzt haben wir einen Commit für die neue Admin-Seite. Wir haben diesen Stacked Branch
00:06:27hier an der Seite und ich kann auch dafür unabhängig einen PR pushen und erstellen. Wenn ich
00:06:31das tue und mir den PR anschaue, sehen wir: Obwohl alle diese Änderungen
00:06:37gleichzeitig in meinem Arbeitsverzeichnis liegen, wurden sie in verschiedene
00:06:42Branches aufgeteilt. Ich kann also gezielt nur die Admin-Sache sehen. Es wurden wirklich nur
00:06:48die Admin-Seiten bearbeitet, in einem eigenen Branch und Commit behalten, ohne
00:06:55mit der restlichen Arbeit in meinem Verzeichnis vermischt zu werden. Alles bleibt getrennt.
00:06:58Das ist das Schöne an der Arbeit mit parallelen und gestapelten Branches in GitButler.
00:07:02Es gibt viele Dinge, die in normalem Git recht schwierig wären. Ich zeige euch ein paar davon.
00:07:06Zum einen können wir Commits von Branch zu Branch verschieben. Wenn ich diesen
00:07:11Commit für die Neuanmeldungen in den Branch für das rote Theme verschieben will,
00:07:15kann ich ihn einfach per Drag-and-Drop rüberziehen und den alten Stack löschen. Jetzt ist der
00:07:20Commit hier drüben. Wenn ich Commits zusammenführen (squash) will, ziehe ich diesen einfach
00:07:26nicht nur auf den darunterliegenden, sondern auf irgendeinen Commit im Stack.
00:07:30Ich kann die Admin-Sache nehmen und zu den Sidebar-Fixes schieben oder sie verschieben,
00:07:36also weiter unten im Stack platzieren oder in einen anderen Commit squashen. Und wie man sieht,
00:07:41sind die Admin-Sachen jetzt auch in den Sidebar-Fixes. Wir können auch das Gegenteil tun: Commits aufteilen.
00:07:47Das machen wir, indem wir einen leeren Commit einfügen und dann Änderungen hineinverschieben.
00:07:52Ich kann überall im Stack einen leeren Commit einfügen, hier zum Beispiel darunter. Ich kann die
00:07:58Nachricht jetzt schreiben oder erst Dateien hineinziehen. Schauen wir uns diese Dateien an.
00:08:02Wir haben den Admin-Controller und die Sidebar-Sache. Nehmen wir diesen Admin-Index und ziehen
00:08:08ihn in den mittleren Commit. Jetzt enthält dieser Commit nur den Admin-Index, während die Sidebar-Fixes
00:08:13immer noch die anderen Dateien enthalten: Admin-Controller und Sidebar. Ich kann auch nur Hunks
00:08:20verschieben. Jetzt enthält dieser Teil die Sidebar-Fixes und der andere Teil den Rest der
00:08:30Sidebar-Fixes. Und wenn ich möchte, kann ich danach die Commit-Nachricht ändern.
00:08:34Das führt uns zu einem weiteren Punkt: Das Bearbeiten von Commit-Nachrichten ist extrem einfach.
00:08:41Abgesehen vom Verschieben, Zusammenführen oder Aufteilen kann ich einfach zurückgehen
00:08:46und sagen: "Ich möchte das in 'Teil zwei' ändern". Das System führt automatisch ein Rebase für alle
00:08:53darauf aufbauenden Commits durch. Man kann Commits auch direkt bearbeiten, und dafür
00:08:57gibt es ein paar sehr schnelle Wege. Nehmen wir an, jemand gibt mir Feedback und sagt:
00:09:01"Statt Margin-Top 0 möchte ich dort 10 Pixel haben" oder so.
00:09:06Wie bearbeitet man nun einen Commit, der nicht nur vier Commits zurückliegt, sondern in einem anderen Stack ist?
00:09:13Mit GitButler ist das kinderleicht. Gehen wir rein und machen die Änderung.
00:09:16Hier ist es, ändern wir es auf 10 Pixel. Inline-CSS ist einfach das Beste. Das ist die Änderung,
00:09:23die ich hier gemacht habe. Sie ist gesperrt, weil wir einen Hunk bearbeiten, der bereits geändert wurde.
00:09:28Es muss also irgendwo in diesen Branch. Wir konnten es nicht in einen separaten parallelen Branch packen.
00:09:32Aber wie machen wir das? Der einfachste Weg ist, die Datei einfach zu nehmen und
00:09:39in diesen Commit zu ziehen. Wenn wir uns den Commit jetzt ansehen, sind die 10 Pixel drin,
00:09:46wir haben es modifiziert und den Rest der Commits darauf neu aufgebaut. Der andere Weg,
00:09:51den wir schon gesehen haben, ist, es in einen temporären Commit zu speichern
00:09:55und diesen dann einfach hier hinein zu squashen. Das führt im Wesentlichen zum
00:10:02selben Ergebnis: Wenn wir nachschauen, beträgt der Margin jetzt 10 Pixel. Und die letzte spannende
00:10:07Möglichkeit ist der sogenannte "Edit Mode". Tun wir so, als hätten wir noch nichts gemacht.
00:10:12Wir haben immer noch die 0 Pixel und wollen das bearbeiten. Wir können direkt in den Commit gehen
00:10:20und auf "Edit commit" klicken. Wenn man das macht, passiert etwas Interessantes.
00:10:25Es ist ähnlich wie ein "Detached Head Checkout" in Git, falls ihr das schon mal gemacht habt. Es
00:10:30checkt diesen Commit in seinem damaligen Zustand aus. Man kann ihn beliebig bearbeiten, und wenn man
00:10:36den Modus beendet, wird alles andere wieder darauf aufgesetzt. Wir machen unsere Änderung erneut.
00:10:39Das System erkennt die Modifikation an der Datei, wir speichern und beenden. Und wieder
00:10:46wird alles per Rebase aktualisiert. Die Änderung ist nun dort gespeichert. Man kann also
00:10:52einen Commit direkt editieren, die Änderung machen und den Commit ergänzen (amend), oder einen
00:10:57neuen Commit machen und ihn squashen. Es gibt viele Wege, die Änderungen in GitButler zu manipulieren.
00:11:01Als Letztes zeige ich euch die sogenannte "Operations History" (Vorgangshistorie).
00:11:05Das ist etwas, das in Git ohne Reflog-Kenntnisse extrem schwer ist. Ich glaube,
00:11:10jeder hat ein bisschen Angst davor, aber alles, was man in GitButler tut, wird in einem Protokoll gespeichert.
00:11:15Man kann in die Timeline schauen und zu jedem beliebigen Zeitpunkt in der Vergangenheit zurückkehren.
00:11:21Hier ist der Button für die Historie. Wir sehen all die verschiedenen Dinge, die wir heute gemacht haben.
00:11:26Und ich kann zu absolut jedem Punkt zurückspringen. Wenn ich zum Beispiel zurück will,
00:11:30bevor ich mit dieser 10-Pixel-Sache angefangen habe, kann ich hierher gehen und sehe:
00:11:37Das war der Zustand direkt davor. Oder ich kann sogar ganz zum
00:11:42Anfang dieser Session zurückgehen. Was dabei nicht rückgängig gemacht wird, ist das,
00:11:47was bereits zu GitHub gepusht wurde. Hier sehe ich diese Upstream-Commits,
00:11:52aber ich gehe zurück zu dem Punkt, bevor ich überhaupt irgendetwas committet hatte.
00:11:56Ich kann diesen Branch sogar löschen und ganz von vorne anfangen. Und das Beste: Selbst
00:12:01dieses Rückgängigmachen kann ich rückgängig machen. Wenn ich hier den Revert-Snapshot
00:12:05wiederum rückgängig mache, sind wir wieder da, wo wir waren. Wir können also jederzeit
00:12:11zu jedem beliebigen Punkt in der Zeit zurückkehren. Man muss also nie Angst vor seinen Aktionen haben.
00:12:16Wenn man in einem komischen Zustand landet oder einfach zum Stand von vor 10 Minuten zurück will,
00:12:22öffnet man die Timeline, geht zurück, klickt auf Revert und fertig. Das war also ein schneller
00:12:26Überblick über GitButler: Rebaser, Commit-Editor, parallele Branches, Stacked Branches –
00:12:32alles ganz einfach ohne weitere Tools. Ladet es euch runter, sagt uns im Discord,
00:12:36was ihr davon haltet, und viel Spaß damit!
00:12:41was ihr davon haltet, und viel Spaß damit.