1
00:00:00,080 --> 00:00:03,680
Git work Trees gibt es 
eigentlich schon seit 2017, aber

2
00:00:03,680 --> 00:00:06,880
mit KI Coding Assistenten 
erleben Sie gerade ein Revival. 

3
00:00:07,120 --> 00:00:10,640
Wir erklären, was Work Trees 
sind, warum sie praktisch sind, 

4
00:00:10,640 --> 00:00:13,920
zum Beispiel für parallele KI 
Agenten und wie du sie in der 

5
00:00:13,920 --> 00:00:16,079
Praxis nutzt. 
Außerdem sprechen wir über 

6
00:00:16,079 --> 00:00:19,600
Fallstricke, Best Practices zum 
Beispiel mit Cursor und Co. 

7
00:00:19,600 --> 00:00:22,520
Und wann sich der Einsatz 
wirklich lohnt viel Spaß mit 

8
00:00:22,520 --> 00:00:30,480
dieser Folge. 
Und damit herzlich Willkommen zu

9
00:00:30,480 --> 00:00:35,640
Folge 147 des To do Developer 
Podcasts, diesmal wieder mit 

10
00:00:35,640 --> 00:00:40,560
einer Themenfolge der ersten 
Themenfolge in diesem neuen 

11
00:00:40,560 --> 00:00:43,840
Kalenderjahr und Euch begrüßen 
wie immer. 

12
00:00:44,320 --> 00:00:48,120
Robin Manuel Thiel und ich malte
lantin Ich bin Strategic 

13
00:00:48,120 --> 00:00:51,840
Solutions Engineer bei Github 
und Robin Manuel ist Director AI

14
00:00:52,000 --> 00:00:55,120
und Cloud beim E Commerce 
Software Unternehmen Jtl. 

15
00:00:55,360 --> 00:00:58,560
Den Podcast machen wir aber in 
unserer Freizeit und alle 

16
00:00:58,560 --> 00:01:02,640
Erfahrungen, die wir hier 
teilen, basieren auf echten 

17
00:01:02,640 --> 00:01:06,560
Kundenprojekten und den eigenen 
Developer Erfahrungen. 

18
00:01:07,120 --> 00:01:10,000
Da haben wir heute auch wieder 
ein ganz spannendes Thema aus 

19
00:01:10,000 --> 00:01:13,560
dem eigenen Alltag mitgebracht, 
weil du hattest gerade im Intro 

20
00:01:13,560 --> 00:01:17,360
schon gesagt, das Feature Get 
work Trees gibt es seit 2017, 

21
00:01:17,520 --> 00:01:22,720
aber ich persönlich habe erst 
2025 überhaupt davon erfahren, 

22
00:01:22,720 --> 00:01:26,160
weil ich nie ein Use Case dafür 
hatte, aber jetzt gibt es ein 

23
00:01:26,160 --> 00:01:29,200
Use Case, du hast ja darüber 
gesprochen, dass man es gerade 

24
00:01:29,200 --> 00:01:33,040
bei AI Assisted Coding häufig 
einsetzt, da gehen wir gleich 

25
00:01:33,040 --> 00:01:36,400
nochmal. 
Im Detail drauf ein, aber 

26
00:01:36,400 --> 00:01:40,160
zunächst vielleicht wie immer 
der Dank an euch aus der 

27
00:01:40,160 --> 00:01:43,840
Community, die uns hier so 
tatkräftig unterstützt. 

28
00:01:44,160 --> 00:01:46,280
Genau, ihr habt uns nämlich 
wieder Kaffee ausgegeben. 

29
00:01:46,280 --> 00:01:49,600
Ganz lieben Dank dafür, wobei 
wir das dieses Mal glaube ich in

30
00:01:49,680 --> 00:01:52,480
T für den Malte eintauschen. 
Ihr hört es so ein bisschen, der

31
00:01:52,480 --> 00:01:54,960
Malte ist eingeschlagen und hört
das Kratzen in seiner Stimme, 

32
00:01:54,960 --> 00:01:59,240
aber er bleibt hier für uns 
standhaft und nimmt diese 

33
00:01:59,240 --> 00:02:01,840
Podcast Folge auf. 
Ganz, ganz lieben dank dir, 

34
00:02:01,840 --> 00:02:04,880
malte und ganz ganz lieben dank 
auch an die lieben Spenderinnen 

35
00:02:04,880 --> 00:02:08,720
und Spender aus der Community. 
Wir haben 5 Kaffee von Wolfram 

36
00:02:08,720 --> 00:02:14,480
bekommen, vielen Dank 2 Kaffee 
von Lukas und 3 Kaffee von Mar 

37
00:02:14,480 --> 00:02:17,640
Holl ganz ganz lieben dank dafür
und seht es uns nach, wenn wir 

38
00:02:17,640 --> 00:02:20,640
den vielleicht diesmal in Husten
und Bronchialtee für den Malte 

39
00:02:20,640 --> 00:02:23,680
eintauschen. 
Vielen Dank dafür. 

40
00:02:23,920 --> 00:02:27,720
Und dann noch kurz die 
Information für diejenigen, die 

41
00:02:27,720 --> 00:02:30,240
an unserer Umfrage teilgenommen 
haben. 

42
00:02:30,480 --> 00:02:34,240
Schaut mal in eure E Mail Inbox,
gegebenenfalls den Spamfilter. 

43
00:02:34,240 --> 00:02:38,480
Wir haben in den letzten Tagen 
die E Mails verschickt. 

44
00:02:39,040 --> 00:02:44,280
Und euch darüber informiert, 
dass ihr einen 5€ Gutschein für 

45
00:02:44,280 --> 00:02:46,840
unseren Shop bekommen habt. 
Und wir haben natürlich auch die

46
00:02:46,840 --> 00:02:50,920
5 Personen informiert, die sich 
besonders viel Mühe bei ihrem 

47
00:02:50,920 --> 00:02:54,240
Feedback gegeben haben und haben
für diese. 

48
00:02:54,560 --> 00:03:00,560
Ein ganz besonderes Gimmick 
erstellt, das werden wir in den 

49
00:03:00,560 --> 00:03:03,520
nächsten Tagen rausschicken und 
dann halten wir es auch mal hier

50
00:03:03,520 --> 00:03:06,240
in die Kamera. 
Wir wollen jetzt nicht die 

51
00:03:06,240 --> 00:03:09,760
Überraschung verderben, von 
daher zeigen und reden wir 

52
00:03:09,760 --> 00:03:15,280
darüber erst wenn es soweit ist.
Aber damit lass uns ins Thema 

53
00:03:15,280 --> 00:03:18,640
einsteigen und über geht Work 
Trees sprechen. 

54
00:03:18,720 --> 00:03:21,680
Das Thema hast du ja 
aufgebracht, du hattest mir 

55
00:03:21,760 --> 00:03:24,640
zwischen Weihnachten und Neujahr
eine Nachricht geschrieben, hey,

56
00:03:24,640 --> 00:03:28,400
ich habe hier schon die nächste 
Folge vorbereitet, ich habe mich

57
00:03:28,400 --> 00:03:32,320
nämlich ganz viel mit Work Trees
beschäftigt, warum hast du die 

58
00:03:32,320 --> 00:03:33,720
eigentlich gebraucht? 
Genau. 

59
00:03:33,720 --> 00:03:34,800
Bei mir war es ähnlich wie bei 
dir. 

60
00:03:34,800 --> 00:03:36,880
Ich kannte das Feature auch gar 
nicht vorher oder habe es 

61
00:03:36,880 --> 00:03:38,760
zumindest noch nie vorher 
verwendet und. 

62
00:03:39,120 --> 00:03:41,520
Und bei mir ist so die Zeit 
zwischen den Jahren immer 

63
00:03:41,520 --> 00:03:45,040
nerding Time und ich habe an 
irgendwelchen hobbyprojekten 

64
00:03:45,040 --> 00:03:48,000
Zeit rumzubasteln und so war es 
auch dieses Jahr. 

65
00:03:48,000 --> 00:03:49,880
Ich habe es ja bestimmt auch 
schon ein oder andere Male im 

66
00:03:49,880 --> 00:03:52,720
Podcast erwähnt, ich habe so 23 
Apps im App Store und eine davon

67
00:03:52,720 --> 00:03:56,640
ist die Local Calendar Sync und 
das ist eine App, die gab es 

68
00:03:56,640 --> 00:03:59,200
ursprünglich nur für Mac OS, die
synchronisiert verschiedene 

69
00:03:59,200 --> 00:04:02,480
Kalender miteinander, sodass man
zum Beispiel private Termine als

70
00:04:02,480 --> 00:04:05,280
Blogger in den Arbeitskalender 
eintragen kann oder umgekehrt 

71
00:04:05,280 --> 00:04:08,840
und. 
Und da gab es immer mal wieder 

72
00:04:08,840 --> 00:04:11,280
den Wunsch, und das ist völlig 
logisch und nachvollziehbar, die

73
00:04:11,280 --> 00:04:14,600
auf Smartphone oder in dem Fall 
jetzt auf ios zu portieren. 

74
00:04:14,600 --> 00:04:18,120
Das hat 2 Gründe, einmal haben 
mehr Leute gerade auch irgendwie

75
00:04:18,120 --> 00:04:21,959
noch im im Arbeitskontext ein 
iphone als ein Mac und der viel 

76
00:04:21,959 --> 00:04:24,960
logischere Grund ist natürlich, 
dass das iphone ja wirklich 24 

77
00:04:24,960 --> 00:04:27,680
7. 
Eingeschaltet ist 

78
00:04:27,760 --> 00:04:30,560
Internetverbindung hat Strom hat
und dadurch natürlich viel 

79
00:04:30,800 --> 00:04:33,760
konstanter im Hintergrund diese 
Termine synchronisieren kann, 

80
00:04:33,760 --> 00:04:36,000
denn das ist so ein bisschen der
Witz bei der App, dass es keinen

81
00:04:36,000 --> 00:04:39,040
Server gibt, worüber das dann 
irgendwie alles passiert lokal 

82
00:04:39,040 --> 00:04:43,000
auf dem Gerät alles passiert mit
höchsten Privacy Standards und 

83
00:04:43,000 --> 00:04:45,480
so weiter oder gar nicht zu viel
Werbung dafür machen. 

84
00:04:45,480 --> 00:04:47,640
Wenn es jetzt bei irgendjemandem
Interesse geweckt hat, schaut es

85
00:04:47,640 --> 00:04:51,200
euch natürlich trotzdem gerne 
anlocalcalendarsync.com gibt es 

86
00:04:51,200 --> 00:04:52,800
natürlich den Link auch in den 
Shownotes. 

87
00:04:53,280 --> 00:04:56,080
Aber warum wir auf das Thema 
kommen, ist, weil ich das Ding 

88
00:04:56,080 --> 00:04:57,800
natürlich nicht alleine 
geschrieben habe, sondern weil 

89
00:04:57,800 --> 00:05:01,040
ich das mit ganz viel KI Hilfe 
gebaut habe, in meinem Fall. 

90
00:05:01,040 --> 00:05:04,480
Ich bin jetzt die KI meiner 
Wahl, jetzt gerade ändert sich 

91
00:05:04,480 --> 00:05:08,080
bei mir auch ständig, ist Cloud 
Code und in diesem Kontext von 

92
00:05:08,080 --> 00:05:11,440
Cloud Code habe ich ganz ganz 
viele Features und ganz ganz 

93
00:05:11,440 --> 00:05:14,560
viele Sachen bei dieser 
Portierung eben von der KI 

94
00:05:14,560 --> 00:05:18,480
übernehmen lassen und dabei hat 
mir ganz viel Git work Trees 

95
00:05:18,480 --> 00:05:22,960
geholfen, denn wir sind schon. 
In dieser Zeit angelangt, wo die

96
00:05:22,960 --> 00:05:26,560
KI mir zu langsam programmiert, 
obwohl sie natürlich 1000 mal 

97
00:05:26,560 --> 00:05:28,400
schneller programmiert als ich 
das machen würde. 

98
00:05:28,480 --> 00:05:32,000
Ich sitze vorm Computer und 
langweile mich und warte, bis 

99
00:05:32,080 --> 00:05:36,000
Cloud Code mir quasi irgendwas 
ausspuckt und um dann jetzt hier

100
00:05:36,000 --> 00:05:38,800
die Arbeit quasi von mehreren 
Agenten zu parallelisieren, das 

101
00:05:38,800 --> 00:05:40,720
habe ich jetzt erstmal so 
wirklich in der Praxis auf 

102
00:05:40,720 --> 00:05:43,280
meinem Rechner gehabt. 
Dafür habe ich get work Trees 

103
00:05:43,280 --> 00:05:45,600
verwendet. 
Und du bist ja jetzt in einer 

104
00:05:45,600 --> 00:05:50,240
Situation, wo die Agenten lokal 
auf deiner Maschine ausgeführt 

105
00:05:50,240 --> 00:05:52,040
werden. 
Du nutzt zwar Remote Models, 

106
00:05:52,040 --> 00:05:54,960
aber die Agenten laufen lokal 
bei dir, das bedeutet du kannst 

107
00:05:54,960 --> 00:05:58,320
auch nicht ohne weiteres die auf
unterschiedlichen Branches 

108
00:05:58,400 --> 00:06:01,440
arbeiten lassen, wie es bei 
Remote Agents der Fall wäre. 

109
00:06:01,440 --> 00:06:04,000
Also wenn du einen Remote Agent 
hätte, würde dieser ja. 

110
00:06:04,840 --> 00:06:08,160
Einen eigenen Klon erstellen von
dem Repo dort einen Brunch 

111
00:06:08,160 --> 00:06:11,120
anlegen und dann das Ganze 
irgendwie in Richtung eines 

112
00:06:11,120 --> 00:06:14,800
Repositories pushen und dann 
irgendwie ein Pull request 

113
00:06:14,800 --> 00:06:16,800
anlegen. 
Aber das kannst du natürlich, 

114
00:06:16,800 --> 00:06:21,680
sofern du nicht das Repository 
mehrmals auf deine Maschine 

115
00:06:21,680 --> 00:06:24,480
klonst. 
Ohne dieses Feature, über das 

116
00:06:24,480 --> 00:06:26,960
wir heute sprechen, gar nicht so
einfach umsetzen. 

117
00:06:27,680 --> 00:06:29,680
Genau das ist ja der Punkt. 
Diese Remote Agents, die haben 

118
00:06:29,680 --> 00:06:32,640
ja quasi für jede Instanz so was
wie einen eigenen kleinen 

119
00:06:32,640 --> 00:06:34,640
Computer oder einen 
Dockercontainer, in dem sie ganz

120
00:06:34,640 --> 00:06:37,440
isoliert arbeiten. 
Das Problem ist und alle die mit

121
00:06:37,440 --> 00:06:41,040
Git arbeiten wissen das man kann
ein Git repository auschecken, 

122
00:06:41,120 --> 00:06:44,480
man kann aber nur einen Branch 
gleichzeitig ausgecheckt haben 

123
00:06:44,880 --> 00:06:49,040
und genau das ist eigentlich das
Feature was git work tree löst. 

124
00:06:49,120 --> 00:06:51,280
Mit git work Tree kann ich 
nämlich mehrere Branches 

125
00:06:51,600 --> 00:06:54,400
parallel ausgecheckt haben und 
dann auch an mehreren Branches 

126
00:06:54,400 --> 00:06:59,280
parallel arbeiten und. 
Das brauche ich spätestens dann,

127
00:06:59,360 --> 00:07:02,800
wenn ich eben selber kann. 
Als Mensch habe ich ja meistens 

128
00:07:02,800 --> 00:07:05,360
nur eine Fokus Stränge, Mensch 
kann ich ja gar nicht so oft 

129
00:07:05,360 --> 00:07:08,680
parallel arbeiten, aber wenn ich
natürlich 345 KI Agenten dann 

130
00:07:08,680 --> 00:07:12,640
345 Features arbeiten lasse, 
alle parallel lokal auf meinem 

131
00:07:12,640 --> 00:07:15,520
Rechner. 
Dann ist es sehr wohl von von 

132
00:07:15,520 --> 00:07:18,080
Vorteil, mehrere Branches 
gleichzeitig ausgecheckt zu 

133
00:07:18,080 --> 00:07:19,600
haben. 
Gut, dann lass uns mal ein 

134
00:07:19,600 --> 00:07:23,680
bisschen ins Detail gehen und 
über das Git World Tree feature 

135
00:07:23,840 --> 00:07:25,920
sprechen. 
Das gibt es ja schon relativ 

136
00:07:25,920 --> 00:07:28,560
lange. 
Du hast gesagt, seit 2017, also 

137
00:07:28,560 --> 00:07:31,520
seit git 25. 
Mittlerweile sind wir aber bei 

138
00:07:31,520 --> 00:07:37,040
Git 252, also schon wirklich 
einige Jahre weiter und einige 

139
00:07:37,200 --> 00:07:40,320
Features und Releases weiter. 
Aber gerade jetzt bekommt das 

140
00:07:40,320 --> 00:07:43,360
extrem viel Hype und wir haben 
davon erfahren und auch ganz 

141
00:07:43,360 --> 00:07:46,160
viele andere und dementsprechend
macht es Sinn, dass wir uns 

142
00:07:46,160 --> 00:07:48,880
heute mal ein bisschen im Detail
damit beschäftigen, wie das 

143
00:07:48,880 --> 00:07:52,400
ganze funktioniert, wie man es 
einsetzt und vielleicht macht es

144
00:07:52,400 --> 00:07:55,600
dafür auch Sinn, dass wir noch 
mal ganz kurz darüber sprechen, 

145
00:07:55,600 --> 00:07:58,160
wie grundsätzlich git eigentlich
funktioniert. 

146
00:07:58,560 --> 00:08:01,200
Genau, also kurze Auffrischung 
unter der Haube. 

147
00:08:01,440 --> 00:08:02,840
Wenn du ein git Projekt aus 
checkst. 

148
00:08:02,840 --> 00:08:05,040
Ein git Projekt besteht 
eigentlich aus 2 Teilen, diesem 

149
00:08:05,040 --> 00:08:08,120
Punkt git Ordner, den man ja 
auch oft dann gar nicht er 

150
00:08:08,120 --> 00:08:10,560
sieht, weil er versteckt ist. 
Das ist eigentlich die 

151
00:08:10,560 --> 00:08:14,320
Datenbank, also hier werden alle
commits, Branches und der 

152
00:08:14,320 --> 00:08:17,440
Verlauf gespeichert und dann 
gibt es das sogenannte 

153
00:08:17,440 --> 00:08:22,160
Arbeitsverzeichnis, das sind 
dann die Dateien die du siehst 

154
00:08:22,160 --> 00:08:24,920
und bearbeitest und. 
Und davon hast du ja eigentlich 

155
00:08:24,920 --> 00:08:26,600
immer nur 1 da. 
So irgendwo checkst du das 

156
00:08:26,600 --> 00:08:28,880
Repository auf deinem Ordner aus
und wenn du den Brunch 

157
00:08:28,880 --> 00:08:31,600
wechselst, dann werden eben 
diese Dateien verändert, 

158
00:08:31,600 --> 00:08:33,520
geupdatet und so weiter in 
diesem jeweiligen 

159
00:08:33,520 --> 00:08:37,679
Arbeitsverzeichnis und geht. 
Work Tree ist jetzt einfach ein 

160
00:08:37,919 --> 00:08:42,400
zweites Arbeitsverzeichnis, was 
aber auf die gleiche Punkt geht.

161
00:08:42,480 --> 00:08:47,680
Ordner Datenbank verweist also 
ein anderer Ordner, ein anderer 

162
00:08:47,680 --> 00:08:50,560
Brunch, aber die gleiche 
History. 

163
00:08:50,960 --> 00:08:54,160
Das heißt, ich checke einen 
weiteren Brunch aus und lege den

164
00:08:54,160 --> 00:08:58,080
aber auf einen anderen Ordner, 
zeige aber im Dateisystem auf 

165
00:08:58,080 --> 00:09:00,640
den ursprünglichen Punkt geht 
Ordnung, dadurch kann ich jetzt 

166
00:09:00,640 --> 00:09:03,200
halt mehrere Branches in ihren 
Ordnern parallel auschecken, 

167
00:09:03,440 --> 00:09:06,960
wichtig hierbei, jeder Brunch 
kann nur an einem Ort 

168
00:09:06,960 --> 00:09:10,000
gleichzeitig ausgecheckt sein, 
also ich kann nicht zweimal den 

169
00:09:10,000 --> 00:09:12,960
Main Brunch auschecken. 
Also wenn ich bereits einen Main

170
00:09:12,960 --> 00:09:15,760
ausgecheckt habe, kann ich eben 
keinen weiteren Worktree dafür 

171
00:09:15,840 --> 00:09:17,240
erstellen. 
Dafür müsste ich dann eben zu 

172
00:09:17,240 --> 00:09:19,680
einem anderen Brunch wechseln. 
Und das ist ja auch ein 

173
00:09:19,680 --> 00:09:24,480
wesentlicher Unterschied zu dem 
Ansatz, wo ich das Repository an

174
00:09:24,560 --> 00:09:28,560
mehreren Stellen Klone, wo ich 
dann diese Datenbank auch an 

175
00:09:28,560 --> 00:09:31,120
mehreren Stellen habe. 
Da könnte ich auch den gleichen 

176
00:09:31,120 --> 00:09:35,360
Brunch an mehreren Stellen. 
Offen haben und an dieser Stelle

177
00:09:35,920 --> 00:09:39,200
mache ich das Ganze auf einer 
gemeinsamen Datenbank, was 

178
00:09:39,200 --> 00:09:42,000
natürlich dann praktisch ist, 
wenn ich zwischen einzelnen 

179
00:09:42,000 --> 00:09:46,600
Branches mergen möchte und kann 
das natürlich dementsprechend 

180
00:09:46,600 --> 00:09:49,880
auch in Richtung meines 
Upstreams vereinfachen, weil 

181
00:09:49,880 --> 00:09:52,520
wenn ich natürlich 
unterschiedliche lokale Clons 

182
00:09:52,520 --> 00:09:54,560
habe, muss ich auch immer den 
Überblick haben, in welchem 

183
00:09:54,560 --> 00:09:57,160
Ordner bin ich gerade, wo ist 
der Kontext und. 

184
00:09:57,680 --> 00:10:01,600
Mit dem ich gerade arbeite. 
Und jetzt habe ich tatsächlich 

185
00:10:01,600 --> 00:10:04,320
eine Datenbank, aber 
unterschiedliche Ordner, in 

186
00:10:04,320 --> 00:10:07,200
denen ich auf unterschiedlichen 
Branches arbeiten kann. 

187
00:10:07,600 --> 00:10:08,920
Genau da kommt es ja 
ursprünglich her. 

188
00:10:09,120 --> 00:10:13,120
Also der Grundgedanke ist, warum
es auch damals 2017 aber ja, KI 

189
00:10:13,120 --> 00:10:15,600
noch ganz weit weg eingeführt 
wurde ist du befindest dich 

190
00:10:15,840 --> 00:10:18,640
keiner mitten mitten bei der 
Arbeit an einem bestimmten 

191
00:10:18,640 --> 00:10:21,720
Feature auf einem Feature Branch
und hast schon ein paar 

192
00:10:21,720 --> 00:10:24,280
Änderungen vorgenommen hast die 
aber jetzt noch nicht committed.

193
00:10:24,680 --> 00:10:26,880
Und jetzt kommt auf einmal 
dieses klassische Szenario. 

194
00:10:26,880 --> 00:10:29,040
Kommt auf einmal ein Teamkollege
um die Ecke und meldet sich bei 

195
00:10:29,040 --> 00:10:32,160
dir und sagt, EY, malte, kannst 
du mal schnell irgendwas auf 

196
00:10:32,160 --> 00:10:34,720
Main checken und dann machst du 
einfach auf der Kommandozeile 

197
00:10:34,720 --> 00:10:39,240
git work tree add und dann den 
Pfad zu irgendeinem Ordner und 

198
00:10:39,240 --> 00:10:42,240
dann hast du den Main Brunch in 
diesem Ordner ausgecheckt. 

199
00:10:42,240 --> 00:10:44,720
Wenn du jetzt keinen anderen 
Brunch mit angibst in diesem Git

200
00:10:44,720 --> 00:10:47,920
work tree Kommando die. 
Alternative wäre jetzt natürlich

201
00:10:48,080 --> 00:10:51,280
einfach die Änderungen zu 
stashen, dann den Brunch zu 

202
00:10:51,280 --> 00:10:55,440
wechseln, mir anzuschauen. 
Was möchte der Kollege gerade 

203
00:10:55,440 --> 00:10:58,800
von mir und dann entsprechend 
zurückzuwechseln und die 

204
00:10:58,800 --> 00:11:03,040
Informationen wieder aus dem 
Stash herauszuholen, das 

205
00:11:03,040 --> 00:11:05,800
funktioniert auch in deinem 
Szenario, was du gerade 

206
00:11:05,800 --> 00:11:07,600
beschrieben hast. 
Ich möchte mal kurz was 

207
00:11:07,600 --> 00:11:10,680
nachschauen, aber sobald du dann
jetzt auch anfängst, vielleicht 

208
00:11:10,680 --> 00:11:14,200
auf diesem anderen Brunch etwas 
zu tun zu arbeiten oder dann 

209
00:11:14,200 --> 00:11:17,440
vielleicht noch ein dritter 
paralleler Stream dazu kommt. 

210
00:11:17,840 --> 00:11:21,280
Dann kommt das natürlich an 
seine Grenzen und genau dort 

211
00:11:21,280 --> 00:11:24,320
fängt dann work Tree an, 
sinnvoll zu werden. 

212
00:11:24,640 --> 00:11:26,040
Genau. 
Für mich fühlt sich Stash noch 

213
00:11:26,040 --> 00:11:27,880
immer so ein bisschen gruselig 
an, muss ich ehrlich sagen. 

214
00:11:27,880 --> 00:11:30,000
Das glaube ich auch, weil es bei
mir so ein bisschen so du 

215
00:11:30,160 --> 00:11:32,440
schiebst diese Änderungen weg, 
du weißt, sie sind da irgendwo 

216
00:11:32,440 --> 00:11:34,840
in diesem Stash halt einfach in 
die Gitterdatenbank geschrieben,

217
00:11:34,840 --> 00:11:37,040
du gibst dem Stash idealerweise 
auch noch einen Namen. 

218
00:11:37,360 --> 00:11:39,840
Aber irgendwie so dann also ich 
mach immer 3 Kreuzzeichen, wenn 

219
00:11:39,840 --> 00:11:42,360
ich den Brunch Wechsel und dann 
der Stash immer noch da ist und 

220
00:11:42,360 --> 00:11:44,640
ich den dann wieder irgendwie 
ziehen kann aber das das kann 

221
00:11:44,640 --> 00:11:46,320
auch sein weil sich das für mich
halt irgendwie so ein bisschen 

222
00:11:46,320 --> 00:11:48,680
undurchsichtig immer anfühlen 
und durch dieses Stash da weiß 

223
00:11:48,680 --> 00:11:50,920
ich auch nie so ganz genau, ob 
das auch richtig ist, was ich da

224
00:11:50,920 --> 00:11:54,320
tue, aber genau für mich ist 
geht worktreet deutlich 

225
00:11:54,320 --> 00:11:56,920
nachvollziehbarer, weil es halt 
wirklich einfach ein eigener 

226
00:11:56,920 --> 00:11:58,560
Ordner ist. 
Da ist das ganze Ding halt halt 

227
00:11:58,560 --> 00:12:01,960
in dem anderen Brunch und. 
Und aber klar, wenn ich einfach 

228
00:12:01,960 --> 00:12:04,080
nur eine eine Änderung habe, 
erst eine Alternative zum 

229
00:12:04,080 --> 00:12:07,040
Stashen, so kann ich halt dann 
in dem anderen Ordner arbeiten 

230
00:12:07,200 --> 00:12:09,920
und danach wieder zu der 
originalen Arbeit, die ich jetzt

231
00:12:09,920 --> 00:12:13,280
noch nicht wie Gestasht habe, 
wieder in den original Ordner 

232
00:12:13,280 --> 00:12:15,040
zurück. 
Und das kann ich jetzt natürlich

233
00:12:15,040 --> 00:12:19,840
einsetzen, um zum Beispiel den 
Code auf verschiedenen Branches 

234
00:12:19,840 --> 00:12:22,280
zu reviewen du hast gerade ja 
gesagt, Hey, kannst du mal kurz 

235
00:12:22,280 --> 00:12:24,480
auf meinen Branch schauen, das 
kann ich dann natürlich für 

236
00:12:24,720 --> 00:12:27,640
mehrere Workstreams parallel 
machen, von verschiedenen 

237
00:12:27,640 --> 00:12:31,360
Kolleginnen und Kollegen. 
Ich kann auch Long Running Tests

238
00:12:31,360 --> 00:12:34,040
laufen lassen, zum Beispiel auf 
meinem Feature Brunch und 

239
00:12:34,040 --> 00:12:37,760
gleichzeitig schon einen neuen 
Brunch anlegen und dort an einem

240
00:12:37,760 --> 00:12:41,200
weiteren Feature arbeiten, ohne 
dass die Dinge sich in die Quere

241
00:12:41,200 --> 00:12:43,280
kommen. 
Das heißt, da gibt es auch schon

242
00:12:43,600 --> 00:12:48,240
vor der KI Welt sinnvolle 
Anwendungsfälle, wo work Tree 

243
00:12:48,480 --> 00:12:53,240
genutzt wird, aber ganz viele 
von uns hatten das vielleicht in

244
00:12:53,240 --> 00:12:55,360
ihrem Alltag noch gar nicht 
realisiert, dass diese 

245
00:12:55,360 --> 00:12:58,080
Möglichkeit existiert. 
Jetzt bekommt das Feature aber 

246
00:12:58,080 --> 00:13:01,760
ein neues Revival in dieser Welt
von parallelen Coding Agenten. 

247
00:13:01,760 --> 00:13:04,280
Also wir haben jetzt zum 
Beispiel das Szenario mein Agent

248
00:13:04,280 --> 00:13:08,040
soll an einem Feature arbeiten, 
während ich auf dem Mainbrand 

249
00:13:08,040 --> 00:13:10,320
oder an meinem Feature gerade 
Werke, das hatte ich jetzt zum 

250
00:13:10,320 --> 00:13:12,560
Beispiel so ein bisschen, als 
ich diese Local Calendar Sync 

251
00:13:12,600 --> 00:13:15,360
App für ios geschrieben habe, 
ich habe irgendwelche kleinen 

252
00:13:15,360 --> 00:13:18,120
Pixelgeschubse in der ui gemacht
und. 

253
00:13:18,320 --> 00:13:21,160
Und parallel könnte der Agent 
mir ja zum Beispiel schon mal in

254
00:13:21,160 --> 00:13:24,120
einer ganz anderen View ein 
Feature bauen oder irgendwie die

255
00:13:24,120 --> 00:13:26,080
Sachen, die ich irgendwie gesagt
habe, schon mal irgendwie durch 

256
00:13:26,400 --> 00:13:28,400
durch testen, indem er 
irgendwelche Unit Tests 

257
00:13:28,400 --> 00:13:30,680
generiert und so weiter und da 
soll er mir natürlich nicht mal 

258
00:13:30,680 --> 00:13:32,880
in die Quere kommen und da haben
wir dann irgendwie parallel 

259
00:13:32,880 --> 00:13:37,600
gearbeitet oder mehrere mehrere 
Agenten laufen parallel im 

260
00:13:37,600 --> 00:13:40,560
Hintergrund und Arbeiten an 
verschiedenen Features. 

261
00:13:40,800 --> 00:13:43,040
Und ich wurde da jetzt 
ungeduldig, in meinem Fall. 

262
00:13:43,040 --> 00:13:45,120
Also ich hatte jetzt einem 
Agenten so eine Aufgabe gegeben,

263
00:13:45,120 --> 00:13:46,920
und wenn die ein bisschen länger
dauert, dann rödelt der ja auch 

264
00:13:46,920 --> 00:13:50,000
eine Weile oder holt sich die 
aktuelle Swift Dokumentation vom

265
00:13:50,080 --> 00:13:54,280
Kontext 7 MCP Server oder redet 
noch mal mit Gitarre um sich das

266
00:13:54,280 --> 00:13:56,120
Issue noch mal genauer 
anzuschauen und zu verstehen und

267
00:13:56,120 --> 00:13:58,480
dann dauert das und dauert das 
und da wurde ich ungeduldig und 

268
00:13:58,480 --> 00:14:00,640
deswegen habe ich dann gesagt 
okay, ich muss diesen Agenten 

269
00:14:00,640 --> 00:14:03,120
hier irgendwie auf so einen 
Background Task legen und im 

270
00:14:03,120 --> 00:14:05,240
Moment kannst du natürlich dann 
auch mehrere Agenten auf so 

271
00:14:05,240 --> 00:14:09,840
einen Background Task legen und.
Und hast halt quasi ja dann 345 

272
00:14:09,840 --> 00:14:13,840
Agenten gleichzeitig, die in 345
verschiedenen Terminal Tabs 

273
00:14:13,840 --> 00:14:17,520
laufen und dann quasi sich nicht
in die Quere kommen können, weil

274
00:14:17,520 --> 00:14:19,640
sie wirklich auf deinem 
Dateisystem in ganz 

275
00:14:19,640 --> 00:14:22,000
verschiedenen Ordnern an ganz 
verschiedenen Branches arbeiten.

276
00:14:22,080 --> 00:14:24,240
Und wenn sie dann fertig sind, 
kannst du das Reviewen und den 

277
00:14:24,240 --> 00:14:26,880
Branch auch einfach wieder in 
deinen Main Brunch rein Mergen 

278
00:14:26,960 --> 00:14:29,920
oder den Puri Quest stellen, 
weil es ja eben das Gleiche geht

279
00:14:29,920 --> 00:14:32,880
Repository ist. 
Ja, und tatsächlich ist das ja 

280
00:14:32,880 --> 00:14:36,680
so ein bisschen wie die moderne 
Version des Szenarios, von dem 

281
00:14:36,680 --> 00:14:39,680
du vorhin berichtet hast. 
Eine Kollegin, Kollege, arbeitet

282
00:14:39,680 --> 00:14:42,160
parallel an einer anderen 
Aufgabe und möchte, dass du 

283
00:14:42,160 --> 00:14:44,640
einfach mal draufschaust, 
vielleicht dort auch Änderungen 

284
00:14:44,640 --> 00:14:46,400
vornimmst. 
Und jetzt ist hier. 

285
00:14:47,280 --> 00:14:51,760
Der Kollege, die Kollegin, der 
KI Agent, der an einer Aufgabe 

286
00:14:51,760 --> 00:14:55,600
arbeitet, also von daher einfach
ein Feature, was schon seit 

287
00:14:55,600 --> 00:14:59,720
vielen Jahren existiert, jetzt 
mit einem neuen Blickwinkel, 

288
00:14:59,720 --> 00:15:03,280
nämlich in der KI gestützten 
Softwareentwicklung, sofern wir 

289
00:15:03,280 --> 00:15:06,560
halt nicht diese Remote Coding 
Agents einsetzen, die ja alle 

290
00:15:06,880 --> 00:15:09,600
ihre eigene Umgebung haben. 
Aber sobald ich natürlich jetzt 

291
00:15:09,680 --> 00:15:12,480
auf meiner Maschine mit 
multiplen Persönlichkeiten 

292
00:15:12,480 --> 00:15:14,400
gleichzeitig an 
unterschiedlichen Dingen 

293
00:15:14,400 --> 00:15:16,240
arbeite. 
Dann brauche ich natürlich 

294
00:15:16,240 --> 00:15:18,800
solche Funktionalitäten, ja. 
Und dann machst du einfach genau

295
00:15:18,800 --> 00:15:21,160
diese 345 Kommandos, die jetzt 
sich bei mir ein bisschen in 

296
00:15:21,160 --> 00:15:23,360
meinem Kopf eingebrannt haben. 
Also ich habe jetzt eigentlich 

297
00:15:23,360 --> 00:15:25,560
immer, wenn ich will, dass KI an
irgendwas arbeitet, dann mache 

298
00:15:25,560 --> 00:15:28,400
ich direkt git work tree add und
gebe einfach quasi das 

299
00:15:28,400 --> 00:15:31,840
Verzeichnis mit, wo dieser Work 
Tree dann laufen soll und mit 

300
00:15:32,400 --> 00:15:35,680
mit B dann auch den Namen von 
dem Branch Wechsel dann in 

301
00:15:35,680 --> 00:15:38,480
dieses Verzeichnis, also mit CD 
und dann den Namen von dem 

302
00:15:38,480 --> 00:15:42,240
Verzeichnis starte, dann da den 
Agenten, in meinem Fall Cloud. 

303
00:15:42,720 --> 00:15:44,880
Lasst ihn seine Arbeit machen 
und wenn er fertig ist, werden 

304
00:15:44,880 --> 00:15:47,920
die Änderungen committed. 
Also geht at Punkt geht.com mit 

305
00:15:47,920 --> 00:15:52,000
m und nur mit coolen coole 
Commit Message merge dann diesen

306
00:15:52,000 --> 00:15:54,720
Brunch mit geht Merch wieder in 
meinen Main Brunch oder wo ich 

307
00:15:54,720 --> 00:15:58,960
arbeite dran und kann damit geht
Work Tree remove und wieder den 

308
00:15:58,960 --> 00:16:02,080
Ordner Pfad diesen geht Work 
Tree auch wieder löschen und bei

309
00:16:02,080 --> 00:16:04,400
mir leben diese Work Trees 
tatsächlich auch einfach in 

310
00:16:04,400 --> 00:16:09,440
meinem Punkt Cloud Ordner der in
meinem Home Verzeichnis liegt 

311
00:16:09,760 --> 00:16:11,800
das heißt wenn ich jetzt 
irgendwie ich habe da bei mir 

312
00:16:11,800 --> 00:16:14,640
ist es. 
Homeverzeichnis Cloud Worktrees 

313
00:16:14,640 --> 00:16:18,240
und da kriegt einfach hier für 
jedes Repositorial liegt an, 

314
00:16:18,240 --> 00:16:21,040
liegt an Ordner und da muss ich 
einfach daran denken, dass ich 

315
00:16:21,040 --> 00:16:23,920
dann danach wieder aufräume und 
das ist hat sich so ein bisschen

316
00:16:24,120 --> 00:16:26,680
kann man sich fast schon einen 
Skript für Schreiben oder Cloud 

317
00:16:26,680 --> 00:16:28,640
direkt sagen, ey, wenn du an 
irgendwas arbeitest in den 

318
00:16:28,640 --> 00:16:31,360
Custom Instructions kann ich das
direkt sagen, dann leg dir bitte

319
00:16:31,360 --> 00:16:33,640
immer mit diesen Commands einen 
eigenen Worktree an und. 

320
00:16:33,840 --> 00:16:36,960
Und so kann ich halt quasi 567 
Instanzen gleichzeitig starten 

321
00:16:36,960 --> 00:16:39,040
und fühl mich zumindest 
produktiver. 

322
00:16:39,200 --> 00:16:41,800
Ich glaub das hat auch irgendwo 
n Limit, weil dann ist irgendwo 

323
00:16:41,800 --> 00:16:44,720
die siebte, ist wahrscheinlich 
dann irgendwann dann ist ist der

324
00:16:44,720 --> 00:16:46,320
erste schon wieder fertig, 
während ich in der siebten 

325
00:16:46,320 --> 00:16:49,680
arbeite aber so. 
Ich sag mal so realistisch habe 

326
00:16:49,680 --> 00:16:52,400
ich sag ich mal 3 Instanzen 
gleichzeitig an Features 

327
00:16:52,400 --> 00:16:54,480
arbeiten lassen, dann hatte ich 
aber auch selber genug zu tun 

328
00:16:54,560 --> 00:16:56,520
zwischen diesen Instanzen hin 
und her zu springen und 

329
00:16:56,520 --> 00:16:59,280
vielleicht hier mal einen Tool 
Call zu approven oder vielleicht

330
00:16:59,280 --> 00:17:01,360
hier dann doch noch mal über 
Reviews zu gucken oder dann hier

331
00:17:01,360 --> 00:17:03,080
vor und dem Agenten dort noch 
mal Feedback zu geben. 

332
00:17:03,080 --> 00:17:05,839
Also ich glaube jetzt mehr als 3
sind jetzt wahrscheinlich erst 

333
00:17:05,839 --> 00:17:08,480
mal unrealistisch, es sei man 
hat ein größeres Gehirn als wir.

334
00:17:10,400 --> 00:17:12,480
Es gibt aber auch Dinge, die 
jetzt in diesen 

335
00:17:12,480 --> 00:17:16,560
unterschiedlichen Work trees. 
Nicht sofort sichtbar oder 

336
00:17:16,560 --> 00:17:21,280
vorhanden sind, weil natürlich 
die Informationen, die in der 

337
00:17:21,280 --> 00:17:25,760
Git History liegen, dann auch in
diesem weiteren Ordner verfügbar

338
00:17:25,760 --> 00:17:27,200
sind. 
Sobald du dort diesen Branch 

339
00:17:27,200 --> 00:17:28,960
anlegst. 
Aber es gibt ja auch bestimmte 

340
00:17:28,960 --> 00:17:32,000
Dinge, die du so üblicherweise 
am Anfang deines 

341
00:17:32,000 --> 00:17:33,680
Entwicklungsprozesses 
installierst. 

342
00:17:33,680 --> 00:17:37,080
Zum Beispiel Dependencies, wenn 
du irgendwelche Note Module 

343
00:17:37,080 --> 00:17:39,640
hast, machst du am Anfang einmal
einen enpairment Stall, damit du

344
00:17:39,640 --> 00:17:41,840
die Anwendung auch laufen lassen
kannst. 

345
00:17:42,240 --> 00:17:45,200
Und das hast du dann natürlich 
nur in diesem einen Ordner 

346
00:17:45,200 --> 00:17:47,800
gemacht und dementsprechend, 
wenn du einen neuen Ordner 

347
00:17:47,800 --> 00:17:51,440
anlegst mit einem neuen Work 
Tree, dann musst du natürlich 

348
00:17:51,440 --> 00:17:54,880
diesen Install der 
entsprechenden Dependencies noch

349
00:17:54,880 --> 00:17:59,280
mal nachziehen, sofern dein 
Coding Agent in deinem Fall auch

350
00:17:59,280 --> 00:18:01,440
Zugriff auf diese Dependencies 
braucht, um zum Beispiel die 

351
00:18:01,440 --> 00:18:03,440
Anwendung zu bauen oder 
auszuführen. 

352
00:18:03,800 --> 00:18:06,720
Genau das ist ganz wichtig. 
Es ist keine Kopie von dem 

353
00:18:06,720 --> 00:18:09,120
bestehenden Ordner, sondern der 
Branch wird wirklich neu 

354
00:18:09,120 --> 00:18:11,360
ausgecheckt. 
Das bedeutet alles was in der 

355
00:18:11,360 --> 00:18:15,280
gitignor Datei steht, also alles
was wie Note Modules sind oder 

356
00:18:15,280 --> 00:18:18,200
Local end Dateien und das sollte
ja so sein, die sollten ja in 

357
00:18:18,200 --> 00:18:20,960
der Gitignor stehen, die sind 
dann in diesem neuen Work für 

358
00:18:20,960 --> 00:18:24,160
auch nicht vorhanden und müssen 
dann eben entweder kopiert 

359
00:18:24,160 --> 00:18:27,680
werden oder noch mal neu 
runtergeladen werden und Cursor 

360
00:18:27,680 --> 00:18:30,400
hat dafür sogar schon ein 
Feature gebaut, die haben. 

361
00:18:30,720 --> 00:18:34,800
Einen eigenen Work Tree Modus, 
da kann ich in den Einstellungen

362
00:18:34,800 --> 00:18:37,520
von Cursor für jedes Projekt 
wirklich in der Work Trees json 

363
00:18:37,520 --> 00:18:41,280
sagen, was passieren soll, wenn 
ich in einen neuen Work Tree 

364
00:18:41,280 --> 00:18:45,200
Wechsel um einen Agenten auf so 
eine Art Background Job dann 

365
00:18:45,200 --> 00:18:46,560
eine Aufgabe ausführen zu 
lassen. 

366
00:18:46,560 --> 00:18:48,680
Da kann ich dann zum Beispiel 
immer sagen, immer wenn du in 

367
00:18:48,680 --> 00:18:51,920
einen Work tree wechselst, mach 
deinen npm install oder was auch

368
00:18:51,920 --> 00:18:55,480
immer ihr verwendet oder kopiere
von dem ursprünglichen Pfad die 

369
00:18:55,480 --> 00:18:59,520
Dot 11 Datei rüber in den jetzt 
neuen work Tree Pfad. 

370
00:19:00,160 --> 00:19:02,120
Das kann man da quasi direkt 
schon machen und da rechne ich 

371
00:19:02,120 --> 00:19:05,280
damit, dass das wahrscheinlich 
jetzt relativ bald auch mit dem 

372
00:19:05,280 --> 00:19:08,320
Hype von Git work trees jetzt 
gerade in alle anderen Coding 

373
00:19:08,320 --> 00:19:10,560
Agenten und ID s auch Einzug 
findet. 

374
00:19:10,720 --> 00:19:13,080
Ja, und das Schöne ist 
natürlich, dass das schon seit 

375
00:19:13,080 --> 00:19:17,200
Langem ein Feature von Git als 
solches ist und dementsprechend 

376
00:19:17,200 --> 00:19:20,560
uns allen auch schon heute zur 
Verfügung steht, ganz unabhängig

377
00:19:20,560 --> 00:19:25,120
davon, ob wir schon so intensiv 
wie du die Coding Agenten nutzen

378
00:19:25,120 --> 00:19:27,280
und. 
Und von daher lasst uns mal 

379
00:19:27,280 --> 00:19:30,560
drüber sprechen, wann wir jetzt 
get Work Trees einsetzen 

380
00:19:30,560 --> 00:19:34,400
sollten, weil manchmal ist es 
vielleicht auch einfach overkill

381
00:19:34,400 --> 00:19:38,080
und einfacher, vielleicht mal zu
stashen oder andere Ansätze zu 

382
00:19:38,080 --> 00:19:39,920
wählen. 
Genau eine coole Sache ist 

383
00:19:39,920 --> 00:19:41,600
natürlich, du kannst es solchen 
prompt. 

384
00:19:41,920 --> 00:19:44,320
Theoretisch auch in mehreren 
Modellen oder mehreren Coding 

385
00:19:44,320 --> 00:19:46,400
Agenten gleichzeitig ausführen. 
Du könntest zum Beispiel sagen, 

386
00:19:46,400 --> 00:19:49,120
Pass auf, ich habe ein Feature 
und ich möchte, dass da jetzt 

387
00:19:49,120 --> 00:19:52,480
Clawed und Germany ein Gitter co
Pilot und Cursor oder was auch 

388
00:19:52,480 --> 00:19:54,440
immer gleichzeitig daran 
arbeiten, dann würde ich für das

389
00:19:54,440 --> 00:19:57,760
gleiche Feature einfach 345 
Worktrees erstellen, denselben 

390
00:19:57,760 --> 00:20:00,160
prompt an verschiedene Agenten 
oder vielleicht auch im gleichen

391
00:20:00,160 --> 00:20:03,760
Agenten an verschiedene Modelle.
Übergeben und jedes läuft dann 

392
00:20:03,760 --> 00:20:07,120
in seinem eigenen Work Tree und 
am Ende vergleiche ich oder eine

393
00:20:07,120 --> 00:20:10,040
KI die Ergebnisse und wählt das 
Beste aus. 

394
00:20:10,040 --> 00:20:12,440
Das wäre ja auch noch mal 
irgendwie was wo du Get Work 

395
00:20:12,440 --> 00:20:14,800
Trees gut verwenden könntest. 
Du willst sehr genau, dass dann 

396
00:20:14,800 --> 00:20:17,200
diese verschiedenen parallelen 
Agenten sich dann nicht in die 

397
00:20:17,200 --> 00:20:19,200
Quere kommen. 
Ja, ein weiterer Anwendungsfall 

398
00:20:19,200 --> 00:20:22,080
ist natürlich dieses Kontext 
switching, was wir vorhin schon 

399
00:20:22,080 --> 00:20:25,800
angesprochen haben, wo du nicht 
mal kurz vielleicht lesend auf 

400
00:20:25,800 --> 00:20:27,920
einen anderen Brunch gehst, 
sondern tatsächlich an 

401
00:20:27,920 --> 00:20:30,560
unterschiedlichen Dingen 
parallel arbeitest. 

402
00:20:30,960 --> 00:20:34,960
Aber nicht hingehen möchtest und
dir das Repository zweimal in 

403
00:20:34,960 --> 00:20:37,280
unterschiedliche oder dreimal in
unterschiedliche Ordner zu 

404
00:20:37,280 --> 00:20:39,840
klonen, weil dann verliert man 
natürlich ganz schnell den 

405
00:20:39,840 --> 00:20:42,640
Überblick. 
Welcher Branch ist jetzt 

406
00:20:42,640 --> 00:20:47,040
eigentlich in welcher in welchem
Klon vorhanden und hier hat man 

407
00:20:47,040 --> 00:20:51,480
natürlich alles auf einer. 
Auf einer History in einem einer

408
00:20:51,480 --> 00:20:55,440
entsprechenden Git Datenbank und
kann natürlich dort auch viel 

409
00:20:55,440 --> 00:20:57,920
besser an den verschiedenen 
Dingen parallel arbeiten. 

410
00:20:58,000 --> 00:21:00,160
Genau, oder ihr seid wie ich und
traut euch gar nicht zu Session,

411
00:21:00,160 --> 00:21:03,600
dann ist es natürlich auch eine 
gute Variante oder ihr macht 

412
00:21:03,600 --> 00:21:05,800
irgendwas riskantes vielleicht, 
was man später bereut, dass man 

413
00:21:05,800 --> 00:21:07,320
sagt EY, Pass auf, da gehe ich 
auf den Worktree, weil ich 

414
00:21:07,320 --> 00:21:10,000
wirklich irgendwie in 
Dateisystem irgendwas rumfummel,

415
00:21:10,000 --> 00:21:13,520
was ich sonst aus verschiedenen 
Git restores irgendwie wieder 

416
00:21:13,520 --> 00:21:15,680
zusammenbasteln könnte. 
Denkt dran, es ist die gleiche 

417
00:21:15,680 --> 00:21:17,760
git Datenbank, also ich würde es
jetzt nicht machen um. 

418
00:21:18,200 --> 00:21:20,880
Irgendwelche Sachen in der git 
history zu ändern und sich davon

419
00:21:20,880 --> 00:21:23,400
so eine Sicherheitskopie zu 
machen, dafür müssen wir uns 

420
00:21:23,400 --> 00:21:24,880
glaube ich wirklich noch mal neu
klonen. 

421
00:21:25,040 --> 00:21:27,920
Aber halt alles was nicht git 
betrifft und irgendwie sagt EY, 

422
00:21:28,440 --> 00:21:30,000
das mache ich mal lieber auf 
einem neuen Brunch, ich habe 

423
00:21:30,000 --> 00:21:33,080
aber noch andere uncompetit 
Arbeit woanders und mache es 

424
00:21:33,080 --> 00:21:34,880
nicht nur auf einem neuen 
Brunch, sondern wirklich auch in

425
00:21:34,880 --> 00:21:37,120
einem neuen Ordner im neuen 
Dateisystem. 

426
00:21:37,360 --> 00:21:39,520
Fühlt sich für mich manchmal 
irgendwie so gefühlt zumindest 

427
00:21:39,520 --> 00:21:42,320
so ein bisschen beruhigter oder 
sicherer an, wenn ich weiß es 

428
00:21:42,320 --> 00:21:43,720
ist in einem ganz anderen 
Ordner, der wird auch 

429
00:21:43,720 --> 00:21:46,160
weggeschmissen danach wenn das 
Feature gemerged wird. 

430
00:21:46,560 --> 00:21:48,240
Dafür finde ich, kann man git 
work trees jetzt so. 

431
00:21:48,480 --> 00:21:50,240
Neben der Tatsache ist 
natürlich, wie wir gerade die 

432
00:21:50,240 --> 00:21:53,120
ganze Zeit gesagt haben, 
verschiedene KI Agenten parallel

433
00:21:53,120 --> 00:21:55,560
ausführen lassen ist das wäre 
das ja vielleicht auch noch mal 

434
00:21:55,560 --> 00:21:57,520
ein Feature wo man git work 
trees verwenden könnte. 

435
00:21:57,840 --> 00:22:01,200
Ich glaube, zusammenfassend 
lässt sich sagen, dass es immer 

436
00:22:01,200 --> 00:22:05,280
dann sinnvoll ist, wenn ich an 
unterschiedlichen Dingen 

437
00:22:05,280 --> 00:22:09,760
parallel arbeite und den Kontext
nicht verlieren möchte und 

438
00:22:09,760 --> 00:22:13,960
dementsprechend wirklich diese 
etwas komplexere Variante. 

439
00:22:13,960 --> 00:22:16,720
Du hast ja gerade. 
Vorgelesen, was dann 

440
00:22:16,720 --> 00:22:19,360
entsprechend die Kommandos sind,
die du ausführen musst, die dann

441
00:22:19,360 --> 00:22:22,400
doch ein bisschen komplexer 
sind, als einfach einen Stash zu

442
00:22:22,400 --> 00:22:23,840
machen und den Brunch zu 
wechseln. 

443
00:22:24,000 --> 00:22:26,720
Aber diese zusätzliche 
Komplexität ist gerade bei 

444
00:22:27,040 --> 00:22:31,360
länger laufenden parallelen 
Aufgaben definitiv wert. 

445
00:22:31,840 --> 00:22:34,080
Wenn ihr jetzt auf den Geschmack
gekommen seid von Git worktrees,

446
00:22:34,080 --> 00:22:36,440
haben wir in der Beschreibung 
von der Folge noch mal die 

447
00:22:36,440 --> 00:22:39,080
offizielle Dokumentation von Git
verlinkt und. 

448
00:22:39,280 --> 00:22:41,760
Aber auch von Cloud und von 
Cursor. 

449
00:22:41,760 --> 00:22:44,400
Die haben auch noch mal 
Dokumentation, quasi wie man in 

450
00:22:44,400 --> 00:22:47,280
ihrem Kontext am besten mit 
geht, Work Trees umgeht und was 

451
00:22:47,280 --> 00:22:49,680
man dann auch alles in deren 
Tools konfigurieren kann. 

452
00:22:50,000 --> 00:22:51,960
Schaut euch das gerne mal an und
wenn ihr natürlich auch 

453
00:22:51,960 --> 00:22:55,360
irgendwelche coolen Tipps und 
Tricks habt oder schon lange mit

454
00:22:55,360 --> 00:22:58,400
Work Tree arbeitet, dann teilt 
das doch gerne mit uns in der 

455
00:22:58,400 --> 00:22:59,960
Community. 
Ihr könnt gerne auch Kommentare 

456
00:22:59,960 --> 00:23:03,200
unter der Podcast Folge 
hinterlassen, da das sehen dann 

457
00:23:03,200 --> 00:23:05,440
auch immer alle anderen und. 
Oder ihr könnt uns natürlich 

458
00:23:05,440 --> 00:23:07,720
auch gerne, wenn ihr 
irgendwelche coolen Tipps und 

459
00:23:07,720 --> 00:23:10,960
Tricks oder Empfehlungen oder 
Wünsche habt, eine E Mail 

460
00:23:10,960 --> 00:23:12,720
schreiben. 
Ihr findet auch immer in der 

461
00:23:12,720 --> 00:23:15,360
Folgen Beschreibung eine e Mail 
Adresse, unter der ihr uns 

462
00:23:15,360 --> 00:23:17,800
privat erreichen könnt. 
Und wie immer, wenn euch die 

463
00:23:17,800 --> 00:23:21,200
Folge gefallen hat und 
hoffentlich weiter gebracht hat,

464
00:23:21,200 --> 00:23:23,520
dann lasst uns gerne eine 
positive Bewertung da. 

465
00:23:23,520 --> 00:23:27,760
Das könnt ihr auf Apple Podcast,
Spotify und natürlich über 

466
00:23:27,760 --> 00:23:29,920
Youtube machen. 
Wir freuen uns immer sehr, wenn 

467
00:23:29,920 --> 00:23:32,520
ihr uns. 
Positives Feedback gebt und 

468
00:23:32,520 --> 00:23:35,200
natürlich, wie du gerade gesagt 
hast, auch kommentiert wir. 

469
00:23:35,600 --> 00:23:37,880
Freuen uns natürlich auch immer 
sehr, wenn ihr Lust habt, uns 

470
00:23:37,880 --> 00:23:40,240
einen Kaffee oder einen Tee 
auszugeben. 

471
00:23:40,480 --> 00:23:44,240
Da findet ihr den Link zu bei 
mir Coffee auch in den Shownotes

472
00:23:44,240 --> 00:23:46,960
und in der Folgenbeschreibung 
oder wenn ihr zu eurem eigenen 

473
00:23:46,960 --> 00:23:50,480
Tee oder Kaffee die passende 
Nerd Tasse oder To do Podcast 

474
00:23:50,480 --> 00:23:53,120
Merch haben wollt. 
Wir haben einen kleinen Shop, da

475
00:23:53,360 --> 00:23:55,240
freuen wir uns auch immer wie 
kleine Kinder, wenn da eine 

476
00:23:55,240 --> 00:23:58,720
Bestellung reinkommt. 
Und nachdem ihr jetzt wisst, wie

477
00:23:58,720 --> 00:24:02,760
ihr ganz toll parallel an ganz 
vielen Dingen arbeiten könnt, 

478
00:24:02,760 --> 00:24:07,000
könnt ihr ja den üblichen 
Hinweis besonders zu Herzen 

479
00:24:07,000 --> 00:24:09,440
nehmen und ganz viel Code 
schreiben. 

480
00:24:09,760 --> 00:24:11,280
Genau, macht's gut. 
Wir hören uns nächste Woche 

481
00:24:11,280 --> 00:24:12,880
wieder. 
Der to do Cast erscheint jeden 

482
00:24:12,880 --> 00:24:14,720
Montag immer abwechselnd mit 
einer News oder einer 

483
00:24:14,720 --> 00:24:17,280
Themenfolge wie dieser hier. 
Nächste Woche gibt's also die 

484
00:24:17,680 --> 00:24:19,920
Zusammenfassung der Tech und 
Developer News der letzten 2 

485
00:24:19,920 --> 00:24:22,320
Wochen, bis dahin habt eine gute
Zeit, schreibt viel Code 

486
00:24:22,320 --> 00:24:25,040
parallel und bis ganz bald. 
Bis dann.