00:00:00Hallo zusammen. Mein Name ist Scott Chacone. Ich bin der CEO von Git Brother.
00:00:02Ich werde eine kurze Demo des neuen Git Brother CLI machen.
00:00:06Wenn ihr also mit der Kommandozeile vertraut seid
00:00:08und Git Brother programmatisch nutzen wollt,
00:00:11dann ist das neue Git Brother CLI eine ziemlich coole Sache.
00:00:14Fangen wir also direkt an. Okay. Wir starten mit einem Repository.
00:00:18Ich habe hier dieses kleine Rust-Projekt,
00:00:20und wir gehen jetzt den Workflow des Git Brother CLI durch.
00:00:23Es ist im Grunde ein direkter Ersatz für Git. Sobald es installiert ist,
00:00:27habt ihr den Befehl „but“. Das ist eure Hauptschnittstelle anstelle von Git.
00:00:32Ihr könnt „but“ oder „but status“ ausführen. Das ist nur die Kurzform.
00:00:35Und es wird euch den Status anzeigen.
00:00:38Das ist der Ausgabe von „git status“ sehr ähnlich.
00:00:41Wir sehen hier vier modifizierte Dateien.
00:00:44Ein paar sind unversioniert, ein paar wurden geändert.
00:00:47Also neue und modifizierte Dateien, aber die „but“-Ausgabe,
00:00:50der Status, zeigt euch einfach eine Liste von vier Änderungen an.
00:00:55Das sind Dinge, die ihr geändert habt. Ihr könnt sie also committen,
00:00:59wie auch immer ihr wollt. Wir führen jetzt einfach „but commit“ aus.
00:01:02Es wird ein temporärer Branch erstellt. Probieren wir das mal aus.
00:01:05Wenn wir wieder „but status“ ausführen, sehen wir alle Änderungen zusammen.
00:01:11Wir können auch „but status -F“ oder „--files“ ausführen.
00:01:15Das zeigt die Dateien an, die in diesem Commit geändert wurden.
00:01:18Aber sagen wir mal, wir wollen gar nicht alles in einen Commit packen.
00:01:21Manche betreffen Clod, eine ist die Readme,
00:01:24und eine sind Änderungen am Kern. Das sind eigentlich drei separate Änderungen.
00:01:28Wir wollen also drei separate Commits. Machen wir das rückgängig.
00:01:31Wir können einen Commit mit „uncommit“ rückgängig machen.
00:01:36Jetzt sind wir zurück. Wir haben hier immer noch diesen temporären Branch.
00:01:40Den können wir löschen, wenn wir wollen, aber nutzen wir ihn einfach weiter.
00:01:44Ich benenne ihn um. Ich nenne den Branch „Clod stuff“.
00:01:48Jetzt habe ich hier einen neuen Branch und kann Dinge darauf stagen,
00:01:53ähnlich wie bei „git add“. Sagen wir: „but stage G0“ und „H0“.
00:01:58Das sind die Kurzcodes für diese Dateien.
00:02:01Man kann natürlich auch den kompletten Pfad ausschreiben,
00:02:04aber wir versuchen, den schnellen Weg so einfach wie möglich zu machen.
00:02:08Diese sind nun auf dem Branch „Clod stuff“ gestaged, und ich committe mit „-O“.
00:02:12Das bedeutet: nur das, was gestaged ist. Wenn ich nur „commit“ ausführe,
00:02:15würde alles committet – sowohl das Gestagte als auch das Ungestagte.
00:02:18Das ergibt mehr Sinn, wenn wir mehr Branches haben,
00:02:20aber committen wir das erst mal. Jetzt haben wir einen Branch mit einem Commit
00:02:25und ein paar ungestagte Änderungen.
00:02:28Hier wird es jetzt interessant, denn im Gegensatz zu Git ...
00:02:31Sagen wir, ich möchte diese Readme-Datei committen,
00:02:34sie hochladen und einen Pull Request (PR) dafür eröffnen.
00:02:37Normalerweise müsste ich, wenn ich auf diesem „Clod“-Branch bin,
00:02:41diesen Branch stashen, die Readme hinzufügen, committen
00:02:44und sie dann für einen Pull Request hochladen.
00:02:45Aber bei Git Brother können wir parallele Branches haben.
00:02:50Ich kann sagen „but branch new readme“, und ihr seht einen neuen Branch,
00:02:55der abzweigt, und ich kann die Datei stagen.
00:03:00Ich kann diese Datei committen.
00:03:01Wenn ich mir die geänderten Dateien ansehe,
00:03:07habe ich diesen Commit mit den zwei Clod-Sachen.
00:03:09Und ich habe diese Readme mit der einen Änderung. Und noch mal:
00:03:11Ich kann dasselbe machen. Ich kann „commit“ sagen,
00:03:17„-c“ steht für „create“, um so einen neuen Branch zu erstellen. Ich sage ...
00:03:21Schauen wir mal, was wir eigentlich geändert haben. Ich hab's vergessen. Ah,
00:03:25dieser Read-Befehl. Okay.
00:03:27Das nimmt das letzte uncommittete Element oder alles, was gerade offen ist,
00:03:32erstellt einen neuen Branch und committet es dort hinein.
00:03:35Jetzt sehen wir, dass wir drei Branches haben.
00:03:38Sie sind alle unabhängig voneinander.
00:03:39Alle diese Änderungen befinden sich noch in unserem Arbeitsverzeichnis.
00:03:42Wir haben das Arbeitsverzeichnis überhaupt nicht verändert.
00:03:44Wir erstellen die Commits quasi nur im Speicher.
00:03:46Jetzt kann ich „but push“ ausführen und werde gefragt: „Was willst du pushen?“
00:03:50„Willst du alle pushen?“ Jeder hat einen unveröffentlichten Commit.
00:03:53„Oder nur einen?“ Pushen wir nur die Readme.
00:03:57Sagen wir, das ist der einzige Teil, der gerade wirklich fertig ist.
00:03:59Wir wählen ihn aus und er wird hochgeladen.
00:04:02Wenn wir uns den Status erneut ansehen,
00:04:03sehen wir am Status-Symbol, dass dieser hier hochgeladen wurde.
00:04:06Die anderen sind nur lokal vorhanden.
00:04:08Git Brother ist sehr mächtig beim gleichzeitigen Arbeiten an mehreren Branches.
00:04:11Es unterstützt aber auch „Stacked Branches“ (gestapelte Branches).
00:04:13Schauen wir uns an, wie man etwas Neues erstellt,
00:04:17basierend auf einem unserer bereits getätigten Commits,” indem wir
00:04:19darauf einen Stacked Branch aufbauen.
00:04:20So können wir den unteren mergen und am oberen weiterarbeiten.
00:04:23Sagen wir, wir wollen einen Stacked Branch erstellen.
00:04:26Dieser Read-Befehl soll reviewt und gemergt werden,
00:04:30aber wir wollen trotzdem schon weiter daran arbeiten.
00:04:32Das ist der perfekte Punkt für einen Stacked Branch statt eines unabhängigen Branches,
00:04:35weil eine Abhängigkeit besteht. Das machen wir so:
00:04:38„but branch new -a“ für den Ankerpunkt,
00:04:42welcher „SC read command“ ist. Und wir nennen ihn „SC read more“.
00:04:46Wenn wir uns das jetzt ansehen,
00:04:48sehen wir, dass dieser Branch obenauf gestapelt ist.
00:04:50Lass uns das mal bearbeiten.
00:04:52Wir sehen, dass hier 10 Nachrichten genommen und angezeigt werden.
00:04:57Machen wir daraus 20 Nachrichten. Und das hier ändern wir auch.
00:05:02Wir sehen die Änderung und ein Schloss-Symbol, weil wir eine Datei
00:05:09bearbeiten, die wir bereits woanders committet haben.
00:05:11Sie ist an einen spezifischen Commit gebunden.
00:05:13Wir können sie nur darauf committen, da sie Code ändert, der dort eingeführt wurde.
00:05:16Mit dem „diff“-Befehl können wir die Änderungen sehen.
00:05:20Das ist eine gute Art, die geänderten Code-Blöcke zu prüfen. Committen wir das.
00:05:25Okay.
00:05:28Um zu zeigen, wie leicht man Commits verschieben kann,
00:05:32werde ich Folgendes demonstrieren:
00:05:33Mit „status -F“ sehen wir alle Dateien.
00:05:37Teilen wir das Ganze. Wir haben bereits „push“ gesehen,
00:05:40was zum Remote-Server hochlädt,
00:05:42aber wir können auch „PR“ sagen, was einen Pull Request öffnet. Wir sagen also:
00:05:46„Für welche davon wollen wir Pull Requests öffnen?“
00:05:48Öffnen wir einfach Pull Requests für alle.
00:05:50Es wird ein Editor für jeden einzelnen geöffnet und gefragt:
00:05:54„Was soll die PR-Beschreibung sein?“ Ich mache es mir einfach.
00:05:57Jetzt haben wir all diese PRs. Da sie nun offen sind,
00:06:01sehen wir oben diese Nummern. Nummer eins, Nummer zwei ...
00:06:04Das sind die PR-Nummern und die zugehörigen Nachrichten.
00:06:06Wir haben einfach jedes Mal dieselben verwendet.
00:06:08Mit dem Befehl „-V“ (für verbose/ausführlich) sehen wir
00:06:10auch die URLs für jeden einzelnen davon.
00:06:12Schauen wir uns mal einen an.
00:06:14Das ist der PR für die Readme. Wir sehen,
00:06:18dass er nur einen Commit und nur die Änderung an der einen Datei enthält. Isoliert.
00:06:23Hier ist der gestapelte PR.
00:06:24Wenn wir uns das ansehen, erkennen wir,
00:06:28dass ein Stack (Stapel) erstellt wurde. Der erste,
00:06:30also der untere PR, zielt auf „main“ ab.
00:06:35Und der zweite, zu dem wir hier springen können, zielt auf den ersten PR ab.
00:06:39Es wird also ein korrekter Stacked Branch erstellt.
00:06:41Schauen wir mal, was passiert, wenn wir etwas integrieren.
00:06:43Gehen wir zu diesem Readme-Pull-Request. Wir sagen: „Okay,
00:06:46sieht gut aus. Ich merge es.“ Das ist jetzt im Upstream.
00:06:49Wenn wir „but pull --check“ ausführen, wird das geprüft.
00:06:55Wir können auch „but fetch“ ausführen; das wird oft automatisch erledigt.
00:06:57Und es wird hin und wieder im Hintergrund ein Fetch ausgeführt.
00:07:00Vielleicht habt ihr das gesehen, während wir Befehle ausgeführt haben.
00:07:02Da stand: „Habe Hintergrundprozess gestartet“. Aber wir sehen, dass dieser hier
00:07:06integriert wurde. Wir sehen es im Upstream. Wenn wir also „but pull“ ausführen,
00:07:10holt es sich die neuen Informationen.
00:07:13Es wird unsere anderen Branches rebasen und diesen integrierten
00:07:16Branch entfernen. Wir sehen, dass er lokal gelöscht wurde.
00:07:19Wenn wir jetzt schauen: Der eine ist fertig,
00:07:22die anderen wurden auf den neuesten Stand rebased und wir können sie wieder hochpushen.
00:07:25Und wenn ihr irgendwann
00:07:29wieder normal mit Git arbeiten wollt, sagt ihr „but tear down“.
00:07:33Das wird einen eurer Branches auswählen.
00:07:36Es nimmt einfach den ersten Branch, auf dem ihr wart,
00:07:39aber ihr habt immer noch alle Branches, an denen wir gearbeitet haben.
00:07:43Nur kann Git selbst immer nur auf einem sein. Jetzt seid ihr also wieder auf einem.
00:07:47Ihr könnt „setup“ und „tear down“ nutzen, um in den Git-Brother-Modus und wieder heraus zu wechseln,
00:07:50wenn ihr an mehreren Branches oder mit normalen Git-Tools arbeiten wollt.
00:07:55Aber selbst im Git-Brother-Modus funktionieren die meisten
00:08:00Git-Befehle noch. Ihr könnt „git show“ auf einem davon ausführen. Genau gleich.
00:08:04Oder „git log“ – funktioniert immer noch.
00:08:08Alle Lesebefehle klappen prima: Show, Log, das alles.
00:08:13Es ist nur das Committen, das wir hier für euch verwalten. In diesem Fall
00:08:16könnt ihr auch direkt einen Checkout machen. Git Brother merkt das
00:08:21und wird alles, was es getan hat, sozusagen zurückziehen.
00:08:24Und alles sollte wieder beim Alten sein.
00:08:26Als Letztes zeige ich noch, dass alle diese Befehle
00:08:30eine „--json“-Version haben. Wenn ihr „status --json“ ausführen wollt,
00:08:34könnt ihr das tun. Oder wenn ihr „show“ für einen Commit ausführen wollt –
00:08:41fast alle Befehle unterstützen das.
00:08:44Ihr seht alle Befehle mit „but help“. Fast jeder dieser
00:08:48Befehle hat eine „--json“ oder „-J“ Option.
00:08:52Das bedeutet, ihr könnt sie ganz einfach skripten. Interessanterweise
00:08:56geht das auch bei „diff“, und man erhält eine JSON-Version des Diffs,
00:09:00was ich ziemlich cool finde.
00:09:01Das war eine gute Einführung in Git Brother und was es im Vergleich zu Git kann.
00:09:05Aber noch mal: Ihr könnt das in jedes Git-Repository einbinden.
00:09:08Führt „but setup“ aus und nutzt all diese Befehle.
00:09:12Ihr habt JSON-Ausgaben, könnt mehrere Branches verwalten,
00:09:15Stacked Branches nutzen, eure
00:09:17GitHub-Integration und PR-Verwaltung machen.
00:09:20Alles ist sofort einsatzbereit; einfach „but“-Befehle nutzen, fertig.
00:09:24Wann immer ihr zu Git zurückkehren wollt –
00:09:26obwohl die meisten Git-Befehle in dieser Umgebung ohnehin funktionieren –,
00:09:29könnt ihr es einfach mit „tear down“ beenden oder einen Branch auschecken.
00:09:33Probiert es am besten heute noch aus.
00:09:35Unter [gitbrother.com/cli](https://www.google.com/search?q=https://gitbrother.com/cli) könnt ihr es herunterladen und testen.
00:09:39Schaut in unserem Discord vorbei und sagt mir eure Meinung. Danke.