Git work Trees gibt es eigentlich schon seit 2017, aber
mit KI Coding Assistenten erleben Sie gerade ein Revival.
Wir erklären, was Work Trees sind, warum sie praktisch sind,
zum Beispiel für parallele KI Agenten und wie du sie in der
Praxis nutzt. Außerdem sprechen wir über
Fallstricke, Best Practices zum Beispiel mit Cursor und Co.
Und wann sich der Einsatz wirklich lohnt viel Spaß mit
dieser Folge. Und damit herzlich Willkommen zu
Folge 147 des To do Developer Podcasts, diesmal wieder mit
einer Themenfolge der ersten Themenfolge in diesem neuen
Kalenderjahr und Euch begrüßen wie immer.
Robin Manuel Thiel und ich malte lantin Ich bin Strategic
Solutions Engineer bei Github und Robin Manuel ist Director AI
und Cloud beim E Commerce Software Unternehmen Jtl.
Den Podcast machen wir aber in unserer Freizeit und alle
Erfahrungen, die wir hier teilen, basieren auf echten
Kundenprojekten und den eigenen Developer Erfahrungen.
Da haben wir heute auch wieder ein ganz spannendes Thema aus
dem eigenen Alltag mitgebracht, weil du hattest gerade im Intro
schon gesagt, das Feature Get work Trees gibt es seit 2017,
aber ich persönlich habe erst 2025 überhaupt davon erfahren,
weil ich nie ein Use Case dafür hatte, aber jetzt gibt es ein
Use Case, du hast ja darüber gesprochen, dass man es gerade
bei AI Assisted Coding häufig einsetzt, da gehen wir gleich
nochmal. Im Detail drauf ein, aber
zunächst vielleicht wie immer der Dank an euch aus der
Community, die uns hier so tatkräftig unterstützt.
Genau, ihr habt uns nämlich wieder Kaffee ausgegeben.
Ganz lieben Dank dafür, wobei wir das dieses Mal glaube ich in
T für den Malte eintauschen. Ihr hört es so ein bisschen, der
Malte ist eingeschlagen und hört das Kratzen in seiner Stimme,
aber er bleibt hier für uns standhaft und nimmt diese
Podcast Folge auf. Ganz, ganz lieben dank dir,
malte und ganz ganz lieben dank auch an die lieben Spenderinnen
und Spender aus der Community. Wir haben 5 Kaffee von Wolfram
bekommen, vielen Dank 2 Kaffee von Lukas und 3 Kaffee von Mar
Holl ganz ganz lieben dank dafür und seht es uns nach, wenn wir
den vielleicht diesmal in Husten und Bronchialtee für den Malte
eintauschen. Vielen Dank dafür.
Und dann noch kurz die Information für diejenigen, die
an unserer Umfrage teilgenommen haben.
Schaut mal in eure E Mail Inbox, gegebenenfalls den Spamfilter.
Wir haben in den letzten Tagen die E Mails verschickt.
Und euch darüber informiert, dass ihr einen 5€ Gutschein für
unseren Shop bekommen habt. Und wir haben natürlich auch die
5 Personen informiert, die sich besonders viel Mühe bei ihrem
Feedback gegeben haben und haben für diese.
Ein ganz besonderes Gimmick erstellt, das werden wir in den
nächsten Tagen rausschicken und dann halten wir es auch mal hier
in die Kamera. Wir wollen jetzt nicht die
Überraschung verderben, von daher zeigen und reden wir
darüber erst wenn es soweit ist. Aber damit lass uns ins Thema
einsteigen und über geht Work Trees sprechen.
Das Thema hast du ja aufgebracht, du hattest mir
zwischen Weihnachten und Neujahr eine Nachricht geschrieben, hey,
ich habe hier schon die nächste Folge vorbereitet, ich habe mich
nämlich ganz viel mit Work Trees beschäftigt, warum hast du die
eigentlich gebraucht? Genau.
Bei mir war es ähnlich wie bei dir.
Ich kannte das Feature auch gar nicht vorher oder habe es
zumindest noch nie vorher verwendet und.
Und bei mir ist so die Zeit zwischen den Jahren immer
nerding Time und ich habe an irgendwelchen hobbyprojekten
Zeit rumzubasteln und so war es auch dieses Jahr.
Ich habe es ja bestimmt auch schon ein oder andere Male im
Podcast erwähnt, ich habe so 23 Apps im App Store und eine davon
ist die Local Calendar Sync und das ist eine App, die gab es
ursprünglich nur für Mac OS, die synchronisiert verschiedene
Kalender miteinander, sodass man zum Beispiel private Termine als
Blogger in den Arbeitskalender eintragen kann oder umgekehrt
und. Und da gab es immer mal wieder
den Wunsch, und das ist völlig logisch und nachvollziehbar, die
auf Smartphone oder in dem Fall jetzt auf ios zu portieren.
Das hat 2 Gründe, einmal haben mehr Leute gerade auch irgendwie
noch im im Arbeitskontext ein iphone als ein Mac und der viel
logischere Grund ist natürlich, dass das iphone ja wirklich 24
7. Eingeschaltet ist
Internetverbindung hat Strom hat und dadurch natürlich viel
konstanter im Hintergrund diese Termine synchronisieren kann,
denn das ist so ein bisschen der Witz bei der App, dass es keinen
Server gibt, worüber das dann irgendwie alles passiert lokal
auf dem Gerät alles passiert mit höchsten Privacy Standards und
so weiter oder gar nicht zu viel Werbung dafür machen.
Wenn es jetzt bei irgendjemandem Interesse geweckt hat, schaut es
euch natürlich trotzdem gerne anlocalcalendarsync.com gibt es
natürlich den Link auch in den Shownotes.
Aber warum wir auf das Thema kommen, ist, weil ich das Ding
natürlich nicht alleine geschrieben habe, sondern weil
ich das mit ganz viel KI Hilfe gebaut habe, in meinem Fall.
Ich bin jetzt die KI meiner Wahl, jetzt gerade ändert sich
bei mir auch ständig, ist Cloud Code und in diesem Kontext von
Cloud Code habe ich ganz ganz viele Features und ganz ganz
viele Sachen bei dieser Portierung eben von der KI
übernehmen lassen und dabei hat mir ganz viel Git work Trees
geholfen, denn wir sind schon. In dieser Zeit angelangt, wo die
KI mir zu langsam programmiert, obwohl sie natürlich 1000 mal
schneller programmiert als ich das machen würde.
Ich sitze vorm Computer und langweile mich und warte, bis
Cloud Code mir quasi irgendwas ausspuckt und um dann jetzt hier
die Arbeit quasi von mehreren Agenten zu parallelisieren, das
habe ich jetzt erstmal so wirklich in der Praxis auf
meinem Rechner gehabt. Dafür habe ich get work Trees
verwendet. Und du bist ja jetzt in einer
Situation, wo die Agenten lokal auf deiner Maschine ausgeführt
werden. Du nutzt zwar Remote Models,
aber die Agenten laufen lokal bei dir, das bedeutet du kannst
auch nicht ohne weiteres die auf unterschiedlichen Branches
arbeiten lassen, wie es bei Remote Agents der Fall wäre.
Also wenn du einen Remote Agent hätte, würde dieser ja.
Einen eigenen Klon erstellen von dem Repo dort einen Brunch
anlegen und dann das Ganze irgendwie in Richtung eines
Repositories pushen und dann irgendwie ein Pull request
anlegen. Aber das kannst du natürlich,
sofern du nicht das Repository mehrmals auf deine Maschine
klonst. Ohne dieses Feature, über das
wir heute sprechen, gar nicht so einfach umsetzen.
Genau das ist ja der Punkt. Diese Remote Agents, die haben
ja quasi für jede Instanz so was wie einen eigenen kleinen
Computer oder einen Dockercontainer, in dem sie ganz
isoliert arbeiten. Das Problem ist und alle die mit
Git arbeiten wissen das man kann ein Git repository auschecken,
man kann aber nur einen Branch gleichzeitig ausgecheckt haben
und genau das ist eigentlich das Feature was git work tree löst.
Mit git work Tree kann ich nämlich mehrere Branches
parallel ausgecheckt haben und dann auch an mehreren Branches
parallel arbeiten und. Das brauche ich spätestens dann,
wenn ich eben selber kann. Als Mensch habe ich ja meistens
nur eine Fokus Stränge, Mensch kann ich ja gar nicht so oft
parallel arbeiten, aber wenn ich natürlich 345 KI Agenten dann
345 Features arbeiten lasse, alle parallel lokal auf meinem
Rechner. Dann ist es sehr wohl von von
Vorteil, mehrere Branches gleichzeitig ausgecheckt zu
haben. Gut, dann lass uns mal ein
bisschen ins Detail gehen und über das Git World Tree feature
sprechen. Das gibt es ja schon relativ
lange. Du hast gesagt, seit 2017, also
seit git 25. Mittlerweile sind wir aber bei
Git 252, also schon wirklich einige Jahre weiter und einige
Features und Releases weiter. Aber gerade jetzt bekommt das
extrem viel Hype und wir haben davon erfahren und auch ganz
viele andere und dementsprechend macht es Sinn, dass wir uns
heute mal ein bisschen im Detail damit beschäftigen, wie das
ganze funktioniert, wie man es einsetzt und vielleicht macht es
dafür auch Sinn, dass wir noch mal ganz kurz darüber sprechen,
wie grundsätzlich git eigentlich funktioniert.
Genau, also kurze Auffrischung unter der Haube.
Wenn du ein git Projekt aus checkst.
Ein git Projekt besteht eigentlich aus 2 Teilen, diesem
Punkt git Ordner, den man ja auch oft dann gar nicht er
sieht, weil er versteckt ist. Das ist eigentlich die
Datenbank, also hier werden alle commits, Branches und der
Verlauf gespeichert und dann gibt es das sogenannte
Arbeitsverzeichnis, das sind dann die Dateien die du siehst
und bearbeitest und. Und davon hast du ja eigentlich
immer nur 1 da. So irgendwo checkst du das
Repository auf deinem Ordner aus und wenn du den Brunch
wechselst, dann werden eben diese Dateien verändert,
geupdatet und so weiter in diesem jeweiligen
Arbeitsverzeichnis und geht. Work Tree ist jetzt einfach ein
zweites Arbeitsverzeichnis, was aber auf die gleiche Punkt geht.
Ordner Datenbank verweist also ein anderer Ordner, ein anderer
Brunch, aber die gleiche History.
Das heißt, ich checke einen weiteren Brunch aus und lege den
aber auf einen anderen Ordner, zeige aber im Dateisystem auf
den ursprünglichen Punkt geht Ordnung, dadurch kann ich jetzt
halt mehrere Branches in ihren Ordnern parallel auschecken,
wichtig hierbei, jeder Brunch kann nur an einem Ort
gleichzeitig ausgecheckt sein, also ich kann nicht zweimal den
Main Brunch auschecken. Also wenn ich bereits einen Main
ausgecheckt habe, kann ich eben keinen weiteren Worktree dafür
erstellen. Dafür müsste ich dann eben zu
einem anderen Brunch wechseln. Und das ist ja auch ein
wesentlicher Unterschied zu dem Ansatz, wo ich das Repository an
mehreren Stellen Klone, wo ich dann diese Datenbank auch an
mehreren Stellen habe. Da könnte ich auch den gleichen
Brunch an mehreren Stellen. Offen haben und an dieser Stelle
mache ich das Ganze auf einer gemeinsamen Datenbank, was
natürlich dann praktisch ist, wenn ich zwischen einzelnen
Branches mergen möchte und kann das natürlich dementsprechend
auch in Richtung meines Upstreams vereinfachen, weil
wenn ich natürlich unterschiedliche lokale Clons
habe, muss ich auch immer den Überblick haben, in welchem
Ordner bin ich gerade, wo ist der Kontext und.
Mit dem ich gerade arbeite. Und jetzt habe ich tatsächlich
eine Datenbank, aber unterschiedliche Ordner, in
denen ich auf unterschiedlichen Branches arbeiten kann.
Genau da kommt es ja ursprünglich her.
Also der Grundgedanke ist, warum es auch damals 2017 aber ja, KI
noch ganz weit weg eingeführt wurde ist du befindest dich
keiner mitten mitten bei der Arbeit an einem bestimmten
Feature auf einem Feature Branch und hast schon ein paar
Änderungen vorgenommen hast die aber jetzt noch nicht committed.
Und jetzt kommt auf einmal dieses klassische Szenario.
Kommt auf einmal ein Teamkollege um die Ecke und meldet sich bei
dir und sagt, EY, malte, kannst du mal schnell irgendwas auf
Main checken und dann machst du einfach auf der Kommandozeile
git work tree add und dann den Pfad zu irgendeinem Ordner und
dann hast du den Main Brunch in diesem Ordner ausgecheckt.
Wenn du jetzt keinen anderen Brunch mit angibst in diesem Git
work tree Kommando die. Alternative wäre jetzt natürlich
einfach die Änderungen zu stashen, dann den Brunch zu
wechseln, mir anzuschauen. Was möchte der Kollege gerade
von mir und dann entsprechend zurückzuwechseln und die
Informationen wieder aus dem Stash herauszuholen, das
funktioniert auch in deinem Szenario, was du gerade
beschrieben hast. Ich möchte mal kurz was
nachschauen, aber sobald du dann jetzt auch anfängst, vielleicht
auf diesem anderen Brunch etwas zu tun zu arbeiten oder dann
vielleicht noch ein dritter paralleler Stream dazu kommt.
Dann kommt das natürlich an seine Grenzen und genau dort
fängt dann work Tree an, sinnvoll zu werden.
Genau. Für mich fühlt sich Stash noch
immer so ein bisschen gruselig an, muss ich ehrlich sagen.
Das glaube ich auch, weil es bei mir so ein bisschen so du
schiebst diese Änderungen weg, du weißt, sie sind da irgendwo
in diesem Stash halt einfach in die Gitterdatenbank geschrieben,
du gibst dem Stash idealerweise auch noch einen Namen.
Aber irgendwie so dann also ich mach immer 3 Kreuzzeichen, wenn
ich den Brunch Wechsel und dann der Stash immer noch da ist und
ich den dann wieder irgendwie ziehen kann aber das das kann
auch sein weil sich das für mich halt irgendwie so ein bisschen
undurchsichtig immer anfühlen und durch dieses Stash da weiß
ich auch nie so ganz genau, ob das auch richtig ist, was ich da
tue, aber genau für mich ist geht worktreet deutlich
nachvollziehbarer, weil es halt wirklich einfach ein eigener
Ordner ist. Da ist das ganze Ding halt halt
in dem anderen Brunch und. Und aber klar, wenn ich einfach
nur eine eine Änderung habe, erst eine Alternative zum
Stashen, so kann ich halt dann in dem anderen Ordner arbeiten
und danach wieder zu der originalen Arbeit, die ich jetzt
noch nicht wie Gestasht habe, wieder in den original Ordner
zurück. Und das kann ich jetzt natürlich
einsetzen, um zum Beispiel den Code auf verschiedenen Branches
zu reviewen du hast gerade ja gesagt, Hey, kannst du mal kurz
auf meinen Branch schauen, das kann ich dann natürlich für
mehrere Workstreams parallel machen, von verschiedenen
Kolleginnen und Kollegen. Ich kann auch Long Running Tests
laufen lassen, zum Beispiel auf meinem Feature Brunch und
gleichzeitig schon einen neuen Brunch anlegen und dort an einem
weiteren Feature arbeiten, ohne dass die Dinge sich in die Quere
kommen. Das heißt, da gibt es auch schon
vor der KI Welt sinnvolle Anwendungsfälle, wo work Tree
genutzt wird, aber ganz viele von uns hatten das vielleicht in
ihrem Alltag noch gar nicht realisiert, dass diese
Möglichkeit existiert. Jetzt bekommt das Feature aber
ein neues Revival in dieser Welt von parallelen Coding Agenten.
Also wir haben jetzt zum Beispiel das Szenario mein Agent
soll an einem Feature arbeiten, während ich auf dem Mainbrand
oder an meinem Feature gerade Werke, das hatte ich jetzt zum
Beispiel so ein bisschen, als ich diese Local Calendar Sync
App für ios geschrieben habe, ich habe irgendwelche kleinen
Pixelgeschubse in der ui gemacht und.
Und parallel könnte der Agent mir ja zum Beispiel schon mal in
einer ganz anderen View ein Feature bauen oder irgendwie die
Sachen, die ich irgendwie gesagt habe, schon mal irgendwie durch
durch testen, indem er irgendwelche Unit Tests
generiert und so weiter und da soll er mir natürlich nicht mal
in die Quere kommen und da haben wir dann irgendwie parallel
gearbeitet oder mehrere mehrere Agenten laufen parallel im
Hintergrund und Arbeiten an verschiedenen Features.
Und ich wurde da jetzt ungeduldig, in meinem Fall.
Also ich hatte jetzt einem Agenten so eine Aufgabe gegeben,
und wenn die ein bisschen länger dauert, dann rödelt der ja auch
eine Weile oder holt sich die aktuelle Swift Dokumentation vom
Kontext 7 MCP Server oder redet noch mal mit Gitarre um sich das
Issue noch mal genauer anzuschauen und zu verstehen und
dann dauert das und dauert das und da wurde ich ungeduldig und
deswegen habe ich dann gesagt okay, ich muss diesen Agenten
hier irgendwie auf so einen Background Task legen und im
Moment kannst du natürlich dann auch mehrere Agenten auf so
einen Background Task legen und. Und hast halt quasi ja dann 345
Agenten gleichzeitig, die in 345 verschiedenen Terminal Tabs
laufen und dann quasi sich nicht in die Quere kommen können, weil
sie wirklich auf deinem Dateisystem in ganz
verschiedenen Ordnern an ganz verschiedenen Branches arbeiten.
Und wenn sie dann fertig sind, kannst du das Reviewen und den
Branch auch einfach wieder in deinen Main Brunch rein Mergen
oder den Puri Quest stellen, weil es ja eben das Gleiche geht
Repository ist. Ja, und tatsächlich ist das ja
so ein bisschen wie die moderne Version des Szenarios, von dem
du vorhin berichtet hast. Eine Kollegin, Kollege, arbeitet
parallel an einer anderen Aufgabe und möchte, dass du
einfach mal draufschaust, vielleicht dort auch Änderungen
vornimmst. Und jetzt ist hier.
Der Kollege, die Kollegin, der KI Agent, der an einer Aufgabe
arbeitet, also von daher einfach ein Feature, was schon seit
vielen Jahren existiert, jetzt mit einem neuen Blickwinkel,
nämlich in der KI gestützten Softwareentwicklung, sofern wir
halt nicht diese Remote Coding Agents einsetzen, die ja alle
ihre eigene Umgebung haben. Aber sobald ich natürlich jetzt
auf meiner Maschine mit multiplen Persönlichkeiten
gleichzeitig an unterschiedlichen Dingen
arbeite. Dann brauche ich natürlich
solche Funktionalitäten, ja. Und dann machst du einfach genau
diese 345 Kommandos, die jetzt sich bei mir ein bisschen in
meinem Kopf eingebrannt haben. Also ich habe jetzt eigentlich
immer, wenn ich will, dass KI an irgendwas arbeitet, dann mache
ich direkt git work tree add und gebe einfach quasi das
Verzeichnis mit, wo dieser Work Tree dann laufen soll und mit
mit B dann auch den Namen von dem Branch Wechsel dann in
dieses Verzeichnis, also mit CD und dann den Namen von dem
Verzeichnis starte, dann da den Agenten, in meinem Fall Cloud.
Lasst ihn seine Arbeit machen und wenn er fertig ist, werden
die Änderungen committed. Also geht at Punkt geht.com mit
m und nur mit coolen coole Commit Message merge dann diesen
Brunch mit geht Merch wieder in meinen Main Brunch oder wo ich
arbeite dran und kann damit geht Work Tree remove und wieder den
Ordner Pfad diesen geht Work Tree auch wieder löschen und bei
mir leben diese Work Trees tatsächlich auch einfach in
meinem Punkt Cloud Ordner der in meinem Home Verzeichnis liegt
das heißt wenn ich jetzt irgendwie ich habe da bei mir
ist es. Homeverzeichnis Cloud Worktrees
und da kriegt einfach hier für jedes Repositorial liegt an,
liegt an Ordner und da muss ich einfach daran denken, dass ich
dann danach wieder aufräume und das ist hat sich so ein bisschen
kann man sich fast schon einen Skript für Schreiben oder Cloud
direkt sagen, ey, wenn du an irgendwas arbeitest in den
Custom Instructions kann ich das direkt sagen, dann leg dir bitte
immer mit diesen Commands einen eigenen Worktree an und.
Und so kann ich halt quasi 567 Instanzen gleichzeitig starten
und fühl mich zumindest produktiver.
Ich glaub das hat auch irgendwo n Limit, weil dann ist irgendwo
die siebte, ist wahrscheinlich dann irgendwann dann ist ist der
erste schon wieder fertig, während ich in der siebten
arbeite aber so. Ich sag mal so realistisch habe
ich sag ich mal 3 Instanzen gleichzeitig an Features
arbeiten lassen, dann hatte ich aber auch selber genug zu tun
zwischen diesen Instanzen hin und her zu springen und
vielleicht hier mal einen Tool Call zu approven oder vielleicht
hier dann doch noch mal über Reviews zu gucken oder dann hier
vor und dem Agenten dort noch mal Feedback zu geben.
Also ich glaube jetzt mehr als 3 sind jetzt wahrscheinlich erst
mal unrealistisch, es sei man hat ein größeres Gehirn als wir.
Es gibt aber auch Dinge, die jetzt in diesen
unterschiedlichen Work trees. Nicht sofort sichtbar oder
vorhanden sind, weil natürlich die Informationen, die in der
Git History liegen, dann auch in diesem weiteren Ordner verfügbar
sind. Sobald du dort diesen Branch
anlegst. Aber es gibt ja auch bestimmte
Dinge, die du so üblicherweise am Anfang deines
Entwicklungsprozesses installierst.
Zum Beispiel Dependencies, wenn du irgendwelche Note Module
hast, machst du am Anfang einmal einen enpairment Stall, damit du
die Anwendung auch laufen lassen kannst.
Und das hast du dann natürlich nur in diesem einen Ordner
gemacht und dementsprechend, wenn du einen neuen Ordner
anlegst mit einem neuen Work Tree, dann musst du natürlich
diesen Install der entsprechenden Dependencies noch
mal nachziehen, sofern dein Coding Agent in deinem Fall auch
Zugriff auf diese Dependencies braucht, um zum Beispiel die
Anwendung zu bauen oder auszuführen.
Genau das ist ganz wichtig. Es ist keine Kopie von dem
bestehenden Ordner, sondern der Branch wird wirklich neu
ausgecheckt. Das bedeutet alles was in der
gitignor Datei steht, also alles was wie Note Modules sind oder
Local end Dateien und das sollte ja so sein, die sollten ja in
der Gitignor stehen, die sind dann in diesem neuen Work für
auch nicht vorhanden und müssen dann eben entweder kopiert
werden oder noch mal neu runtergeladen werden und Cursor
hat dafür sogar schon ein Feature gebaut, die haben.
Einen eigenen Work Tree Modus, da kann ich in den Einstellungen
von Cursor für jedes Projekt wirklich in der Work Trees json
sagen, was passieren soll, wenn ich in einen neuen Work Tree
Wechsel um einen Agenten auf so eine Art Background Job dann
eine Aufgabe ausführen zu lassen.
Da kann ich dann zum Beispiel immer sagen, immer wenn du in
einen Work tree wechselst, mach deinen npm install oder was auch
immer ihr verwendet oder kopiere von dem ursprünglichen Pfad die
Dot 11 Datei rüber in den jetzt neuen work Tree Pfad.
Das kann man da quasi direkt schon machen und da rechne ich
damit, dass das wahrscheinlich jetzt relativ bald auch mit dem
Hype von Git work trees jetzt gerade in alle anderen Coding
Agenten und ID s auch Einzug findet.
Ja, und das Schöne ist natürlich, dass das schon seit
Langem ein Feature von Git als solches ist und dementsprechend
uns allen auch schon heute zur Verfügung steht, ganz unabhängig
davon, ob wir schon so intensiv wie du die Coding Agenten nutzen
und. Und von daher lasst uns mal
drüber sprechen, wann wir jetzt get Work Trees einsetzen
sollten, weil manchmal ist es vielleicht auch einfach overkill
und einfacher, vielleicht mal zu stashen oder andere Ansätze zu
wählen. Genau eine coole Sache ist
natürlich, du kannst es solchen prompt.
Theoretisch auch in mehreren Modellen oder mehreren Coding
Agenten gleichzeitig ausführen. Du könntest zum Beispiel sagen,
Pass auf, ich habe ein Feature und ich möchte, dass da jetzt
Clawed und Germany ein Gitter co Pilot und Cursor oder was auch
immer gleichzeitig daran arbeiten, dann würde ich für das
gleiche Feature einfach 345 Worktrees erstellen, denselben
prompt an verschiedene Agenten oder vielleicht auch im gleichen
Agenten an verschiedene Modelle. Übergeben und jedes läuft dann
in seinem eigenen Work Tree und am Ende vergleiche ich oder eine
KI die Ergebnisse und wählt das Beste aus.
Das wäre ja auch noch mal irgendwie was wo du Get Work
Trees gut verwenden könntest. Du willst sehr genau, dass dann
diese verschiedenen parallelen Agenten sich dann nicht in die
Quere kommen. Ja, ein weiterer Anwendungsfall
ist natürlich dieses Kontext switching, was wir vorhin schon
angesprochen haben, wo du nicht mal kurz vielleicht lesend auf
einen anderen Brunch gehst, sondern tatsächlich an
unterschiedlichen Dingen parallel arbeitest.
Aber nicht hingehen möchtest und dir das Repository zweimal in
unterschiedliche oder dreimal in unterschiedliche Ordner zu
klonen, weil dann verliert man natürlich ganz schnell den
Überblick. Welcher Branch ist jetzt
eigentlich in welcher in welchem Klon vorhanden und hier hat man
natürlich alles auf einer. Auf einer History in einem einer
entsprechenden Git Datenbank und kann natürlich dort auch viel
besser an den verschiedenen Dingen parallel arbeiten.
Genau, oder ihr seid wie ich und traut euch gar nicht zu Session,
dann ist es natürlich auch eine gute Variante oder ihr macht
irgendwas riskantes vielleicht, was man später bereut, dass man
sagt EY, Pass auf, da gehe ich auf den Worktree, weil ich
wirklich irgendwie in Dateisystem irgendwas rumfummel,
was ich sonst aus verschiedenen Git restores irgendwie wieder
zusammenbasteln könnte. Denkt dran, es ist die gleiche
git Datenbank, also ich würde es jetzt nicht machen um.
Irgendwelche Sachen in der git history zu ändern und sich davon
so eine Sicherheitskopie zu machen, dafür müssen wir uns
glaube ich wirklich noch mal neu klonen.
Aber halt alles was nicht git betrifft und irgendwie sagt EY,
das mache ich mal lieber auf einem neuen Brunch, ich habe
aber noch andere uncompetit Arbeit woanders und mache es
nicht nur auf einem neuen Brunch, sondern wirklich auch in
einem neuen Ordner im neuen Dateisystem.
Fühlt sich für mich manchmal irgendwie so gefühlt zumindest
so ein bisschen beruhigter oder sicherer an, wenn ich weiß es
ist in einem ganz anderen Ordner, der wird auch
weggeschmissen danach wenn das Feature gemerged wird.
Dafür finde ich, kann man git work trees jetzt so.
Neben der Tatsache ist natürlich, wie wir gerade die
ganze Zeit gesagt haben, verschiedene KI Agenten parallel
ausführen lassen ist das wäre das ja vielleicht auch noch mal
ein Feature wo man git work trees verwenden könnte.
Ich glaube, zusammenfassend lässt sich sagen, dass es immer
dann sinnvoll ist, wenn ich an unterschiedlichen Dingen
parallel arbeite und den Kontext nicht verlieren möchte und
dementsprechend wirklich diese etwas komplexere Variante.
Du hast ja gerade. Vorgelesen, was dann
entsprechend die Kommandos sind, die du ausführen musst, die dann
doch ein bisschen komplexer sind, als einfach einen Stash zu
machen und den Brunch zu wechseln.
Aber diese zusätzliche Komplexität ist gerade bei
länger laufenden parallelen Aufgaben definitiv wert.
Wenn ihr jetzt auf den Geschmack gekommen seid von Git worktrees,
haben wir in der Beschreibung von der Folge noch mal die
offizielle Dokumentation von Git verlinkt und.
Aber auch von Cloud und von Cursor.
Die haben auch noch mal Dokumentation, quasi wie man in
ihrem Kontext am besten mit geht, Work Trees umgeht und was
man dann auch alles in deren Tools konfigurieren kann.
Schaut euch das gerne mal an und wenn ihr natürlich auch
irgendwelche coolen Tipps und Tricks habt oder schon lange mit
Work Tree arbeitet, dann teilt das doch gerne mit uns in der
Community. Ihr könnt gerne auch Kommentare
unter der Podcast Folge hinterlassen, da das sehen dann
auch immer alle anderen und. Oder ihr könnt uns natürlich
auch gerne, wenn ihr irgendwelche coolen Tipps und
Tricks oder Empfehlungen oder Wünsche habt, eine E Mail
schreiben. Ihr findet auch immer in der
Folgen Beschreibung eine e Mail Adresse, unter der ihr uns
privat erreichen könnt. Und wie immer, wenn euch die
Folge gefallen hat und hoffentlich weiter gebracht hat,
dann lasst uns gerne eine positive Bewertung da.
Das könnt ihr auf Apple Podcast, Spotify und natürlich über
Youtube machen. Wir freuen uns immer sehr, wenn
ihr uns. Positives Feedback gebt und
natürlich, wie du gerade gesagt hast, auch kommentiert wir.
Freuen uns natürlich auch immer sehr, wenn ihr Lust habt, uns
einen Kaffee oder einen Tee auszugeben.
Da findet ihr den Link zu bei mir Coffee auch in den Shownotes
und in der Folgenbeschreibung oder wenn ihr zu eurem eigenen
Tee oder Kaffee die passende Nerd Tasse oder To do Podcast
Merch haben wollt. Wir haben einen kleinen Shop, da
freuen wir uns auch immer wie kleine Kinder, wenn da eine
Bestellung reinkommt. Und nachdem ihr jetzt wisst, wie
ihr ganz toll parallel an ganz vielen Dingen arbeiten könnt,
könnt ihr ja den üblichen Hinweis besonders zu Herzen
nehmen und ganz viel Code schreiben.
Genau, macht's gut. Wir hören uns nächste Woche
wieder. Der to do Cast erscheint jeden
Montag immer abwechselnd mit einer News oder einer
Themenfolge wie dieser hier. Nächste Woche gibt's also die
Zusammenfassung der Tech und Developer News der letzten 2
Wochen, bis dahin habt eine gute Zeit, schreibt viel Code
parallel und bis ganz bald. Bis dann.