1
00:00:00,000 --> 00:00:04,600
如果你沒有程式背景,最近卻迷上了用AI寫程式,也就是所謂的vibe coding

2
00:00:04,600 --> 00:00:08,300
那你絕對遇過一種狀況,就是Claude或者Cursor突然問你

3
00:00:08,300 --> 00:00:11,900
要不要commit,要不要開個分支,或者是要不要發個pr

4
00:00:11,900 --> 00:00:17,000
這些聽起來像外新聞的術語,背後其實全都指向同一個東西,那就是git

5
00:00:17,000 --> 00:00:20,700
如果你每天被這些名詞轟炸,卻還是搞不懂他們到底在幹嘛

6
00:00:20,700 --> 00:00:22,800
那麼今天的影片你一定要看完

7
00:00:22,800 --> 00:00:28,000
我會用最白話的方式搭配實際的案例,帶你一次搞懂git和github的概念與用法

8
00:00:28,000 --> 00:00:32,000
同時,我也會告訴你,身為一個用AI寫程式的vibe coder

9
00:00:32,000 --> 00:00:35,000
要怎麼把這些工具無縫融入你的開發流程中

10
00:00:35,000 --> 00:00:40,000
讓你下次看到AI吐出這些專有名詞的時候,你就不會再心慌慌不知道自己在幹嘛了

11
00:00:40,000 --> 00:00:44,400
那我們就直接開始今天的主題,假設今天Gary心血來超,想要做一個記帳軟體

12
00:00:44,400 --> 00:00:50,000
於是他打開CodeCode,請AI幫忙,過沒多久,AI就順利幫他把第一版的畫面給做出來了

13
00:00:50,000 --> 00:00:55,000
但這個時候,Gary遇到了一個問題,我寫好的這些程式,到底可以放在哪裡呢?

14
00:00:55,000 --> 00:00:59,000
他不想讓程式只能留在這台電腦裡,畢竟他之後可能會想換別台電腦接著寫

15
00:00:59,000 --> 00:01:02,000
或者想把做好的東西分享給朋友看

16
00:01:02,000 --> 00:01:08,000
於是他就想,有沒有一種像Google Drive一樣的工具,可以讓我把程式碼直接存在雲端上呢?

17
00:01:08,000 --> 00:01:12,000
這時候,我們就會用到今天的第一個關鍵工具,也就是Github

18
00:01:12,000 --> 00:01:16,000
你可以先簡單把Github理解成程式碼專用的Google Drive

19
00:01:16,000 --> 00:01:23,000
工程師們都會把程式碼上傳到Github,讓有權限的人都能夠隨時查看,甚至是一起編輯

20
00:01:23,000 --> 00:01:28,000
但下一個問題就來了,我要怎麼把我電腦裡這些寫好程式的資料夾上傳到Github呢?

21
00:01:28,000 --> 00:01:33,000
其實啊,你不能像用Google Drive那樣,直接把整個資料夾拖進去就好

22
00:01:33,000 --> 00:01:40,000
你可以想像,我們以前寫報告的時候,資料夾裡常常會出現報告V1,報告最終版,報告打死不改版這種檔案

23
00:01:40,000 --> 00:01:44,000
像這樣留下每次修改歷史的行為,就叫做版本紀錄

24
00:01:44,000 --> 00:01:47,000
因為Github主要是用來讓大家協作跟追蹤程式碼進度的

25
00:01:47,000 --> 00:01:51,000
所以他不收單純的檔案,他只接收已經做好版本紀錄的專案

26
00:01:51,000 --> 00:01:57,000
也就是說,在上傳之前,你必須先在自己的電腦裡幫程式碼建立起這個紀錄系統

27
00:01:57,000 --> 00:02:01,000
而要幫資料夾建立這種版本紀錄的關鍵工具,就是Git

28
00:02:01,000 --> 00:02:04,000
我們可以想像一下,如果今天沒有Git,當Gary請AI幫忙加一個新功能

29
00:02:04,000 --> 00:02:07,000
結果AI不小心把原本好好的程式給改壞了

30
00:02:07,000 --> 00:02:11,000
這時候最崩潰的點在於,你根本不知道AI剛剛到底動了哪些檔案

31
00:02:11,000 --> 00:02:14,000
也完全不知道該怎麼讓程式恢復到上一個正常的狀態

32
00:02:14,000 --> 00:02:17,000
但如果有了Git,那就不一樣了

33
00:02:17,000 --> 00:02:21,000
不管AI怎麼亂改,你隨時都有辦法把程式回溯到之前正常的樣子

34
00:02:21,000 --> 00:02:26,000
所以,在把專案放上Github之前,Clocko通常會先問你要不要設定Git

35
00:02:26,000 --> 00:02:29,000
或者是直接幫你跑一行叫做GitInit的指令

36
00:02:29,000 --> 00:02:33,000
這行指令的意思非常簡單,它就是在跟Git這個版本管理工具說

37
00:02:33,000 --> 00:02:36,000
嘿,請你開始幫我追蹤這個資料夾裡的所有變動

38
00:02:36,000 --> 00:02:38,000
講到這裡,我們先停一下

39
00:02:38,000 --> 00:02:40,000
你只要先分清楚這兩個東西就好

40
00:02:40,000 --> 00:02:43,000
GitHub是在雲端儲存和管理程式碼的網站

41
00:02:43,000 --> 00:02:46,000
而Git則是幫你在本機端管理程式碼版本的工具

42
00:02:46,000 --> 00:02:48,000
回到Gary的例子

43
00:02:48,000 --> 00:02:51,000
因為他想把程式放到GitHub上,所以他現在的第一步

44
00:02:51,000 --> 00:02:55,000
就是必須先讓他電腦裡的資料夾開始被Git給追蹤

45
00:02:55,000 --> 00:02:58,000
設定好Git之後,Gary又繼續寫了一陣子

46
00:02:58,000 --> 00:03:00,000
好不容易終於把登錄頁面給做出來了

47
00:03:00,000 --> 00:03:02,000
他看著這個終於能順利運作的程式

48
00:03:02,000 --> 00:03:05,000
心裡想,我好不容易才把登錄功能搞定

49
00:03:05,000 --> 00:03:07,000
我想要在這邊先建立一個版本紀錄

50
00:03:07,000 --> 00:03:09,000
這樣萬一之後AI又把程式改壞了

51
00:03:09,000 --> 00:03:12,000
我才可以隨時退回到現在這個正常的狀態

52
00:03:12,000 --> 00:03:14,000
當你有這種想要存檔的念頭時

53
00:03:14,000 --> 00:03:18,000
你要知道,這就對應著Git裡面的Commit功能

54
00:03:18,000 --> 00:03:21,000
你可以把Commit想像成是在玩遊戲的時候

55
00:03:21,000 --> 00:03:24,000
打大魔王之前,你會先手動存檔的那個動作

56
00:03:24,000 --> 00:03:26,000
Commit最大的價值在於

57
00:03:26,000 --> 00:03:29,000
他幫你的程式碼建立了一個絕對安全的檢查點

58
00:03:29,000 --> 00:03:32,000
只要你做了Commit,這份正常的狀態就被永久封存了

59
00:03:32,000 --> 00:03:35,000
接下來就算AI發瘋,把你的程式碼全刪了

60
00:03:35,000 --> 00:03:36,000
或是改的亂七八糟

61
00:03:36,000 --> 00:03:40,000
你都可以瞬間把程式碼還原回你當初Commit的那個完美狀態

62
00:03:40,000 --> 00:03:43,000
所以當CodeCode幫你寫完一段程式

63
00:03:43,000 --> 00:03:46,000
主動問你要不要Commit的時候

64
00:03:46,000 --> 00:03:48,000
他其實就是在問你現在這個好好的狀態

65
00:03:48,000 --> 00:03:50,000
你要不要先幫他存個打賣個保險

66
00:03:50,000 --> 00:03:52,000
這裡有一個觀念一定要特別注意

67
00:03:52,000 --> 00:03:55,000
Commit不是上傳,也不是把東西放到GitHub上

68
00:03:55,000 --> 00:03:58,000
Commit只是單純在你自己的電腦裡面

69
00:03:58,000 --> 00:04:00,000
幫目前的狀態留下一份紀錄而已

70
00:04:00,000 --> 00:04:03,000
所以當你自己覺得這一版跑起來沒問題

71
00:04:03,000 --> 00:04:04,000
想要留個底的時候

72
00:04:04,000 --> 00:04:05,000
你也可以主動跟AI說

73
00:04:05,000 --> 00:04:07,000
現在這版測試都沒問題幫我Commit一下

74
00:04:07,000 --> 00:04:10,000
並且在訊息裡寫清楚這次修改了什麼

75
00:04:10,000 --> 00:04:13,000
好,現在Gary順利為他的登入頁面做了一個Commit存檔

76
00:04:13,000 --> 00:04:14,000
接著他一定會想

77
00:04:14,000 --> 00:04:17,000
既然我自己電腦裡已經有一個滿意的版本了

78
00:04:17,000 --> 00:04:19,000
我是不是該把它丟到網路上備份

79
00:04:19,000 --> 00:04:20,000
順便準備分享給朋友看呢

80
00:04:20,000 --> 00:04:23,000
當你有這種想把電腦裡存好的進度

81
00:04:23,000 --> 00:04:24,000
上傳到雲端的念頭時

82
00:04:24,000 --> 00:04:27,000
對應的Git動作就叫做Push

83
00:04:27,000 --> 00:04:29,000
這邊我們要再幫大家強調一次

84
00:04:29,000 --> 00:04:31,000
Commit跟Push完全是兩回事

85
00:04:31,000 --> 00:04:34,000
Commit只是在你自己的電腦裡面存檔

86
00:04:34,000 --> 00:04:36,000
而Push才是真的把你電腦裡存好的檔案

87
00:04:36,000 --> 00:04:38,000
推送到雲端的GitHub上

88
00:04:38,000 --> 00:04:41,000
不過在你真的把東西Push上去之前

89
00:04:41,000 --> 00:04:43,000
有一件事是所有Videcoder都要知道的

90
00:04:43,000 --> 00:04:45,000
不然可能會出大事

91
00:04:45,000 --> 00:04:47,000
因為Gary的記帳軟體裡面

92
00:04:47,000 --> 00:04:50,000
剛好藏了一把用來串接金流的API金鑰

93
00:04:50,000 --> 00:04:53,000
你可以把這種金鑰想像程式你家大門的鑰匙

94
00:04:53,000 --> 00:04:55,000
如果它跟著程式碼一起被Push到GitHub上

95
00:04:55,000 --> 00:04:58,000
就等於是你把鑰匙公開貼在網路上

96
00:04:58,000 --> 00:04:59,000
任何人都可以撿去用

97
00:04:59,000 --> 00:05:00,000
所以我可以撿去用

98
00:05:00,000 --> 00:05:01,800
甚至拿去倒刷你的信用卡帳號

99
00:05:02,300 --> 00:05:03,320
前面提到的情況

100
00:05:03,580 --> 00:05:05,380
就算AI把程式改壞的都還有舊

101
00:05:05,380 --> 00:05:07,160
但金鑰一旦外洩流傳出去

102
00:05:07,420 --> 00:05:08,440
那就真的救不回來了

103
00:05:08,700 --> 00:05:10,240
只能整把作廢重新申請

104
00:05:10,500 --> 00:05:11,780
就像信用卡被倒刷後

105
00:05:11,780 --> 00:05:13,820
只能掛失原本的卡片重新補發一張

106
00:05:14,600 --> 00:05:15,620
所以在Push之前

107
00:05:15,880 --> 00:05:16,900
我們會需要用到一個叫做

108
00:05:16,900 --> 00:05:17,660
Git Ignore的檔案

109
00:05:18,180 --> 00:05:19,200
它的作用非常單純

110
00:05:19,460 --> 00:05:20,220
就是用來告訴Git

111
00:05:20,480 --> 00:05:22,020
這些特定的檔案請不要追蹤

112
00:05:22,020 --> 00:05:23,040
也絕對不要上傳

113
00:05:23,560 --> 00:05:25,600
而且你根本不用自己去記哪些檔案改檔

114
00:05:25,600 --> 00:05:26,880
只要直接跟Cold Code說

115
00:05:26,880 --> 00:05:27,640
幫我確認

116
00:05:27,640 --> 00:05:28,920
EMV檔 密碼

117
00:05:29,180 --> 00:05:29,940
還有各種金鑰

118
00:05:30,200 --> 00:05:32,000
或者機密檔案都已經放進Git Ignore裡面

119
00:05:32,240 --> 00:05:33,520
絕對不要Cold Me上去

120
00:05:34,040 --> 00:05:34,560
這樣就可以了

121
00:05:35,060 --> 00:05:36,080
第一次做Push的時候

122
00:05:36,080 --> 00:05:37,360
你可能會看到AI跑出一些

123
00:05:37,620 --> 00:05:38,640
看起來很長的指令

124
00:05:38,900 --> 00:05:39,920
像是設定Remote啦

125
00:05:40,180 --> 00:05:41,720
或者是Push到Origin Main啦

126
00:05:42,480 --> 00:05:44,540
其實你完全不用被這些字眼給嚇到

127
00:05:45,040 --> 00:05:45,560
Remote

128
00:05:45,560 --> 00:05:46,840
顧名思義就是遠端的地址

129
00:05:47,360 --> 00:05:48,640
跟它相對應的叫做Local

130
00:05:48,640 --> 00:05:50,160
也就是你電腦本地的資料夾

131
00:05:50,680 --> 00:05:51,440
而Origin

132
00:05:51,700 --> 00:05:53,500
通常就是指你在Github上的那個

133
00:05:53,760 --> 00:05:54,520
專案資料夾

134
00:05:55,040 --> 00:05:55,540
至於Main

135
00:05:55,540 --> 00:05:57,600
則代表這個專案目前的官方正式

136
00:05:58,400 --> 00:05:59,940
所以Push到Origin Main

137
00:06:00,200 --> 00:06:01,220
翻譯成白話文就是

138
00:06:01,480 --> 00:06:03,780
請幫我把現在寫好的這個正式版本

139
00:06:04,040 --> 00:06:06,860
傳送到雲端的那個專案資料夾裡面

140
00:06:07,620 --> 00:06:08,640
順利上傳之後

141
00:06:08,900 --> 00:06:10,960
Gary很開心的把Github的連結丟給他的朋友

142
00:06:11,720 --> 00:06:13,000
朋友收到連結之後就會想

143
00:06:13,260 --> 00:06:15,820
那我要怎麼把這個專案抓到我自己的電腦裡呢

144
00:06:16,080 --> 00:06:18,120
而且我不只想要拿到現在的檔案

145
00:06:18,380 --> 00:06:19,660
如果之後我修改了程式

146
00:06:19,920 --> 00:06:21,960
我也想把它上傳回Gary的Github裡面

147
00:06:22,220 --> 00:06:24,000
這樣我們就可以一起維護這套程式

148
00:06:24,760 --> 00:06:27,580
當朋友有這種想一起共同編輯這個專案的念頭時

149
00:06:27,840 --> 00:06:28,860
他需要的動作

150
00:06:29,120 --> 00:06:30,140
就叫做Clone

151
00:06:30,660 --> 00:06:31,680
這裡也要特別注意喔

152
00:06:31,940 --> 00:06:33,220
Clone跟你在Github網頁上

153
00:06:33,480 --> 00:06:34,500
常看到的另一個選項

154
00:06:34,760 --> 00:06:35,000
Download zip

155
00:06:35,260 --> 00:06:36,280
是完全不一樣的東西

156
00:06:37,320 --> 00:06:38,340
如果你只是按Download zip

157
00:06:38,340 --> 00:06:39,620
那你抓下來的

158
00:06:39,880 --> 00:06:41,420
就只是一包純粹的檔案

159
00:06:41,660 --> 00:06:43,460
裡面完全沒有被Gith追蹤的紀錄

160
00:06:43,980 --> 00:06:44,480
這樣一來

161
00:06:44,740 --> 00:06:46,280
如果Gary的朋友之後改了程式碼

162
00:06:46,540 --> 00:06:48,580
他是沒辦法把改動同步回Github上的

163
00:06:49,100 --> 00:06:50,880
但如果是用Clone把專案抓下來

164
00:06:51,140 --> 00:06:51,660
那就等於是

165
00:06:51,900 --> 00:06:52,940
你正式加入了這個專案

166
00:06:53,440 --> 00:06:55,500
只要Gary有在Github上把你加入成協作者

167
00:06:55,740 --> 00:06:57,020
之後你做了任何修改

168
00:06:57,280 --> 00:06:58,060
想要上傳回去

169
00:06:58,300 --> 00:06:59,080
都會非常輕鬆

170
00:06:59,580 --> 00:07:00,100
過沒多久

171
00:07:00,360 --> 00:07:02,140
Gary的朋友幫忙增加了一個新的功能

172
00:07:02,660 --> 00:07:03,420
Gary這時候就想

173
00:07:03,680 --> 00:07:04,960
朋友剛剛已經把新寫好的東西

174
00:07:05,220 --> 00:07:05,980
推送到雲端了

175
00:07:05,980 --> 00:07:08,800
那我自己的電腦要怎麼拿到他最新改好的版本呢

176
00:07:09,300 --> 00:07:10,080
這邊對應的Git

177
00:07:10,340 --> 00:07:10,840
指令

178
00:07:11,100 --> 00:07:11,620
就叫做

179
00:07:11,860 --> 00:07:12,120
Pol

180
00:07:12,380 --> 00:07:14,940
他會把Github上面最新版本的程式碼給抓下來

181
00:07:15,460 --> 00:07:16,740
並且同步到Gary自己的電腦裡

182
00:07:17,500 --> 00:07:18,020
所以

183
00:07:18,260 --> 00:07:19,800
如果以後你要跟朋友一起用AI寫程式

184
00:07:20,060 --> 00:07:21,860
你們合作的基礎循環就會是這個樣子

185
00:07:22,360 --> 00:07:24,420
第一次加入專案要把程式碼抓下來

186
00:07:24,660 --> 00:07:25,180
叫做Clone

187
00:07:25,940 --> 00:07:27,740
平常想同步別人的最新進度

188
00:07:28,000 --> 00:07:28,500
叫做Pool

189
00:07:29,020 --> 00:07:30,560
自己改好東西想要存檔

190
00:07:30,820 --> 00:07:31,580
先用Commit

191
00:07:32,100 --> 00:07:33,880
最後想把自己的進度送上雲端

192
00:07:34,140 --> 00:07:34,660
就用Push

193
00:07:34,660 --> 00:07:35,940
把這個合作

194
00:07:36,200 --> 00:07:37,220
循環建立起來之後

195
00:07:37,480 --> 00:07:37,980
接下來

196
00:07:38,500 --> 00:07:39,260
Gary準備要來

197
00:07:39,520 --> 00:07:40,300
開發一個大功能了

198
00:07:41,060 --> 00:07:43,620
他這次想要幫記帳軟體加上資料庫的功能

199
00:07:43,880 --> 00:07:45,420
這樣就能儲存用戶的資料

200
00:07:46,180 --> 00:07:46,700
但是

201
00:07:46,940 --> 00:07:48,740
他不想要直接在目前的穩定版本

202
00:07:49,000 --> 00:07:50,280
也就是我們剛剛提到的main

203
00:07:50,540 --> 00:07:50,780
上面

204
00:07:51,040 --> 00:07:52,320
去開發這個新功能

205
00:07:52,580 --> 00:07:52,840
因為

206
00:07:53,100 --> 00:07:53,860
Gary是vibecoder

207
00:07:54,120 --> 00:07:55,660
他很怕把自己辛辛苦苦的東西

208
00:07:55,900 --> 00:07:56,420
改爆了

209
00:07:56,940 --> 00:07:58,460
這時候就要引進Git裡面

210
00:07:58,720 --> 00:07:59,740
另一個非常關鍵的概念

211
00:08:00,000 --> 00:08:01,020
也就是分支

212
00:08:01,280 --> 00:08:01,800
英文叫做

213
00:08:02,060 --> 00:08:02,300
branch

214
00:08:02,300 --> 00:08:04,340
在Git的世界裡

215
00:08:04,600 --> 00:08:05,380
所有的專案

216
00:08:05,620 --> 00:08:06,660
一開始都會有一條主線

217
00:08:06,900 --> 00:08:07,420
叫做main

218
00:08:07,680 --> 00:08:08,700
這條線代表的是

219
00:08:08,960 --> 00:08:10,240
穩定運行中的程式碼

220
00:08:11,000 --> 00:08:12,020
我們之所以要開branch

221
00:08:12,280 --> 00:08:13,560
目的其實非常單純

222
00:08:13,820 --> 00:08:15,100
就是要讓正在開發中

223
00:08:15,360 --> 00:08:16,120
還不穩定的功能

224
00:08:16,380 --> 00:08:17,920
跟已經寫好很穩定的功能

225
00:08:18,180 --> 00:08:18,680
徹底分開

226
00:08:18,940 --> 00:08:19,960
讓他們緊隨不犯河水

227
00:08:20,480 --> 00:08:21,240
這時候你肯會想

228
00:08:21,500 --> 00:08:22,520
既然我前面已經學會

229
00:08:22,780 --> 00:08:23,040
用commit

230
00:08:23,300 --> 00:08:23,800
來存檔了

231
00:08:24,320 --> 00:08:26,100
那我直接讓AI在main主線上面改

232
00:08:26,360 --> 00:08:27,140
如果他改壞了

233
00:08:27,380 --> 00:08:28,420
我再退回到上一個commit

234
00:08:28,660 --> 00:08:28,920
不就好了嗎

235
00:08:29,180 --> 00:08:30,460
為什麼大家都一定要叫我開一個

236
00:08:30,720 --> 00:08:31,480
叫做branch的東西呢

237
00:08:32,240 --> 00:08:33,020
其實原因很簡單

238
00:08:33,520 --> 00:08:36,080
因為當AI在幫你寫比較複雜的大功能時

239
00:08:36,340 --> 00:08:37,360
他通常不會

240
00:08:37,620 --> 00:08:38,140
一次就寫對

241
00:08:38,400 --> 00:08:40,180
而是會需要反覆試錯

242
00:08:40,440 --> 00:08:40,960
修改好幾次

243
00:08:41,720 --> 00:08:43,260
如果你一直都在main上面讓他改

244
00:08:43,520 --> 00:08:45,560
那在AI試錯的這段期間

245
00:08:45,820 --> 00:08:47,100
你的程式就會一直處於一種

246
00:08:47,360 --> 00:08:48,380
半壞掉的狀態

247
00:08:48,880 --> 00:08:50,680
這時候如果朋友突然想看看你的

248
00:08:50,940 --> 00:08:51,440
記帳軟體

249
00:08:51,700 --> 00:08:52,220
或者是

250
00:08:52,480 --> 00:08:53,760
你突然發現畫面上有一處

251
00:08:54,000 --> 00:08:55,280
拼置錯誤需要緊急修正

252
00:08:55,540 --> 00:08:56,320
你就會非常尷尬

253
00:08:56,820 --> 00:08:58,360
因為你這條作為專案

254
00:08:58,620 --> 00:08:59,380
門面的main

255
00:08:59,640 --> 00:09:00,660
現在根本就跑不動

256
00:09:00,660 --> 00:09:02,200
你可以把你的專案資料夾

257
00:09:02,460 --> 00:09:04,500
想像成一張神奇辦公桌

258
00:09:04,760 --> 00:09:05,260
而branch

259
00:09:05,520 --> 00:09:06,800
就像是這張桌子旁邊的

260
00:09:07,060 --> 00:09:08,080
平行時空切換按鈕

261
00:09:08,600 --> 00:09:09,360
當你按下main

262
00:09:09,620 --> 00:09:10,140
桌上會呈現

263
00:09:10,380 --> 00:09:11,420
穩定版本的程式碼

264
00:09:11,660 --> 00:09:12,700
當你按下新功能branch

265
00:09:12,940 --> 00:09:15,760
桌上的東西會瞬間變成你正在開發中的草稿

266
00:09:16,540 --> 00:09:17,040
也就是說

267
00:09:17,300 --> 00:09:19,340
branch讓你可以隨時在同一張辦公桌上

268
00:09:19,600 --> 00:09:20,620
安全地把不同任務的進度

269
00:09:20,880 --> 00:09:21,400
切換來

270
00:09:21,660 --> 00:09:21,900
切換去

271
00:09:22,160 --> 00:09:23,440
不用擔心弄亂原本的東西

272
00:09:24,220 --> 00:09:26,260
如果這個新功能的草稿真的被AI改爛了

273
00:09:26,260 --> 00:09:28,560
最壞的狀況就是把這個branch直接刪掉

274
00:09:28,820 --> 00:09:29,580
然後切回main

275
00:09:29,840 --> 00:09:31,120
而你的main依然毫法無傷

276
00:09:31,900 --> 00:09:32,400
所以你可以這樣記

277
00:09:32,660 --> 00:09:34,460
當你準備要開發一個新功能的時候

278
00:09:34,700 --> 00:09:36,240
第一步就是請AI開一個branch

279
00:09:36,760 --> 00:09:38,300
然後接下來所有的程式改動

280
00:09:38,540 --> 00:09:39,820
都在這個branch上面做

281
00:09:40,080 --> 00:09:40,340
commit

282
00:09:40,600 --> 00:09:41,620
在這個時代

283
00:09:41,880 --> 00:09:43,420
我不會說你必須要學會

284
00:09:43,660 --> 00:09:43,920
git指令

285
00:09:44,180 --> 00:09:45,460
但你一定要知道這些名詞

286
00:09:45,720 --> 00:09:46,480
功能是幹嘛的

287
00:09:46,740 --> 00:09:48,280
這樣你就可以直接跟AI說

288
00:09:48,540 --> 00:09:50,580
嘿先幫我從main開一條新的branch

289
00:09:50,580 --> 00:09:53,140
專門用來做這次的資料庫功能

290
00:09:53,660 --> 00:09:55,180
之後所有的改動都幫我commit

291
00:09:55,440 --> 00:09:55,960
在這條branch上

292
00:09:56,220 --> 00:09:56,980
絕對不要動到面

293
00:09:58,000 --> 00:09:59,280
不過現在情況又變了

294
00:09:59,800 --> 00:10:00,060
Garry

295
00:10:00,000 --> 00:10:02,500
Tabby在等Clockode開發資料庫功能的同時

296
00:10:02,500 --> 00:10:03,900
他又想要開另一個Clockode

297
00:10:03,900 --> 00:10:05,700
來幫他重新設計UI畫面

298
00:10:06,300 --> 00:10:09,400
但如果你直接叫AI同時在同一個資料夾裡做這兩件事

299
00:10:09,400 --> 00:10:10,800
那絕對會是一場災難

300
00:10:11,300 --> 00:10:12,200
為什麼呢?

301
00:10:12,200 --> 00:10:14,400
回到剛剛神奇辦公桌的比喻

302
00:10:14,400 --> 00:10:16,000
Branch的致命傷在於

303
00:10:16,000 --> 00:10:17,900
雖然你可以切換不同狀態

304
00:10:17,900 --> 00:10:20,500
但你終究只有一張辦公桌

305
00:10:20,500 --> 00:10:21,300
也就是說

306
00:10:21,300 --> 00:10:25,100
這張桌子同一個時間只能顯示一個平行時空

307
00:10:25,100 --> 00:10:28,400
如果你硬要叫兩個AI同時在這唯一的一張桌子上做事

308
00:10:28,400 --> 00:10:30,100
一個要看資料庫藍圖

309
00:10:30,100 --> 00:10:31,600
一個要看UI設計稿

310
00:10:31,600 --> 00:10:34,800
他們就會為了搶這張桌子的顯示狀態而大打出手

311
00:10:34,800 --> 00:10:36,700
你明明在開發資料庫的Branch上

312
00:10:36,700 --> 00:10:38,800
裡面卻混進了修改UI的commit

313
00:10:38,800 --> 00:10:41,500
這會讓整個Git的狀態變得非常混亂

314
00:10:41,500 --> 00:10:42,300
為了解決這個問題

315
00:10:42,300 --> 00:10:45,000
我們就需要認識WorkTree這個超好用的功能

316
00:10:45,000 --> 00:10:46,400
既然一張桌子不夠用

317
00:10:46,400 --> 00:10:47,900
最暴力的解決辦法是什麼?

318
00:10:47,900 --> 00:10:49,300
就是直接去IKEA

319
00:10:49,300 --> 00:10:51,900
再買第二張實體的辦公桌放在旁邊

320
00:10:51,900 --> 00:10:52,800
你可以這樣想

321
00:10:52,800 --> 00:10:55,400
Branch像是在同一張桌子上切換不同的時空

322
00:10:55,400 --> 00:10:57,300
同一個時間你只能看見一個畫面

323
00:10:57,300 --> 00:11:00,200
而WorkTree則是直接給你第二張實體的桌子

324
00:11:00,200 --> 00:11:02,900
讓兩個時空可以同時並存在你的電腦裡

325
00:11:02,900 --> 00:11:05,800
所以當你跟ClawCode說你要開一個新的WorkTree時

326
00:11:05,800 --> 00:11:07,200
它其實就是在你電腦裡

327
00:11:07,200 --> 00:11:09,300
生出一個全新的實體資料夾

328
00:11:09,300 --> 00:11:11,100
也就是這第二張桌子

329
00:11:11,100 --> 00:11:13,300
所以如果Gary想同時開發資料庫

330
00:11:13,300 --> 00:11:14,200
又想修改UI

331
00:11:14,200 --> 00:11:16,100
他就可以請AI開兩個WorkTree

332
00:11:16,100 --> 00:11:19,000
這時候AI就會生出兩個獨立的資料夾

333
00:11:19,000 --> 00:11:19,800
最棒的是

334
00:11:19,800 --> 00:11:22,100
這兩張桌子是連通同一個Git記憶庫的

335
00:11:22,100 --> 00:11:25,300
所以你可以讓Agent A去第一張桌子負責資料庫的Branch

336
00:11:25,300 --> 00:11:28,200
讓Agent B去第二張桌子負責UI的Branch

337
00:11:28,200 --> 00:11:28,900
這樣一來

338
00:11:28,900 --> 00:11:31,800
這兩個AI就像是擁有了各自專屬的實體辦公桌

339
00:11:31,800 --> 00:11:33,900
能在各自的資料夾裡各私其職

340
00:11:33,900 --> 00:11:35,500
平行開發的效率直接拉滿

341
00:11:35,500 --> 00:11:37,500
完全不會互相干擾

342
00:11:37,500 --> 00:11:39,700
以前的工程師其實不太會用到WorkTree

343
00:11:39,700 --> 00:11:41,400
畢竟一個人沒有三頭六臂

344
00:11:41,400 --> 00:11:43,500
一次大概也就是專心做一件事

345
00:11:43,500 --> 00:11:44,900
但是現在時代不一樣了

346
00:11:44,900 --> 00:11:46,200
身為一個Vibe Coder

347
00:11:46,200 --> 00:11:48,900
你真的很有可能會同時開兩三個AI Agent

348
00:11:48,900 --> 00:11:50,200
讓他們平行工作

349
00:11:50,200 --> 00:11:51,400
而不是呆呆地排隊

350
00:11:51,400 --> 00:11:53,200
等一個做完才換下一個

351
00:11:53,200 --> 00:11:53,900
這時候

352
00:11:53,900 --> 00:11:55,900
你就一定會需要用到WorkTree

353
00:11:55,900 --> 00:11:56,800
過了一陣子

354
00:11:56,800 --> 00:11:59,200
Gary讓好幾個AI在各自的工作區裡

355
00:11:59,200 --> 00:12:02,000
順利把自己負責的新功能都寫完了

356
00:12:02,000 --> 00:12:02,700
這時候

357
00:12:02,700 --> 00:12:05,100
他想要把這條Branch上做好的功能

358
00:12:05,100 --> 00:12:06,800
在正式合併進Main之前

359
00:12:06,800 --> 00:12:09,100
先丟給朋友Review檢查一下

360
00:12:09,100 --> 00:12:10,000
這個動作

361
00:12:10,000 --> 00:12:12,100
在GitHub上就叫做開PR

362
00:12:12,100 --> 00:12:14,200
PR的全名叫做Pool Request

363
00:12:14,200 --> 00:12:17,100
你可以先把它想像成是一份改動提案

364
00:12:17,100 --> 00:12:18,200
當你開好PR之後

365
00:12:18,200 --> 00:12:19,900
這份提案就會被送到GitHub上

366
00:12:19,900 --> 00:12:22,700
讓大家一起來審核這次的改動合不合理

367
00:12:22,700 --> 00:12:24,100
而且開PR這件事

368
00:12:24,100 --> 00:12:25,300
你也不用自己動手

369
00:12:25,300 --> 00:12:27,100
可以直接請AI代勞

370
00:12:27,100 --> 00:12:28,800
只要跟你的Agent說

371
00:12:28,800 --> 00:12:30,700
幫我把這條Branch開一個PR

372
00:12:30,700 --> 00:12:32,600
內容說明一下這次做了什麼功能

373
00:12:32,600 --> 00:12:33,600
改了哪些檔案

374
00:12:33,600 --> 00:12:35,100
還有要怎麼去測試它

375
00:12:35,100 --> 00:12:37,300
AI就會幫你把這份提案整理得清清楚楚

376
00:12:37,300 --> 00:12:39,400
讓幫你Review的人一看就懂

377
00:12:39,400 --> 00:12:40,800
當大家都檢查過

378
00:12:40,800 --> 00:12:43,300
覺得Gary這次的改動完全沒有問題之後

379
00:12:43,300 --> 00:12:44,100
最後一個動作

380
00:12:44,100 --> 00:12:45,800
就是要將這次的程式碼變動

381
00:12:45,800 --> 00:12:47,800
正式合併回主線main裡面

382
00:12:47,800 --> 00:12:49,400
這個合併的動作

383
00:12:49,400 --> 00:12:50,700
對應的Git指令

384
00:12:50,700 --> 00:12:51,900
就叫做Merge

385
00:12:51,900 --> 00:12:53,300
當大家在GitHub網頁上

386
00:12:53,300 --> 00:12:54,400
按下Merge按鈕之後

387
00:12:54,400 --> 00:12:56,300
雲端上的main就正式更新了

388
00:12:56,300 --> 00:12:59,200
這邊要提醒一個新手最容易誤會的地方

389
00:12:59,200 --> 00:13:01,900
因為這個合併是在雲端網頁上發生的

390
00:13:01,900 --> 00:13:03,400
所以你自己電腦本機裡的main

391
00:13:03,400 --> 00:13:05,400
並不會自動通靈跟著變

392
00:13:05,400 --> 00:13:07,200
很多人會有一種錯覺

393
00:13:07,200 --> 00:13:09,800
以為我在VS Code或者是Cursor裡面看到的程式碼

394
00:13:09,800 --> 00:13:11,400
就是GitHub上最新的版本

395
00:13:11,400 --> 00:13:12,400
其實並不是

396
00:13:12,400 --> 00:13:15,100
你看到的永遠都是你電腦本機目前的狀態

397
00:13:15,100 --> 00:13:16,200
雲端更新了

398
00:13:16,200 --> 00:13:19,200
你的電腦是不會通靈自動去同步的

399
00:13:19,200 --> 00:13:19,700
所以

400
00:13:19,700 --> 00:13:22,100
每次只要有新功能被合併進man之後

401
00:13:22,100 --> 00:13:23,700
一定要記得切回本機的man

402
00:13:23,700 --> 00:13:25,600
並且叫你的agent再執行一次pool

403
00:13:25,600 --> 00:13:28,100
手動把雲端最新的版本給拉下來

404
00:13:28,100 --> 00:13:28,700
這樣一來

405
00:13:28,700 --> 00:13:30,100
你下次開新的branch

406
00:13:30,100 --> 00:13:31,800
才是從最新的進度出發

407
00:13:31,800 --> 00:13:34,400
而不會一直活在一個過時的舊版本裡

408
00:13:34,400 --> 00:13:35,100
不過

409
00:13:35,100 --> 00:13:36,700
在合併程式碼的過程中

410
00:13:36,700 --> 00:13:39,000
有時候會遇到另一種讓人頭痛的狀況

411
00:13:39,000 --> 00:13:40,200
那就是conflict

412
00:13:40,200 --> 00:13:42,000
也就是所謂的衝突

413
00:13:42,000 --> 00:13:42,600
假設

414
00:13:42,600 --> 00:13:45,400
Gary跟朋友剛好都改到了同一個檔案的同一個地方

415
00:13:45,400 --> 00:13:48,400
或者是兩個ai agent剛好去動到的同一段核心邏輯

416
00:13:48,400 --> 00:13:49,100
這時候

417
00:13:49,100 --> 00:13:51,600
Git就會跳出conflict的警告

418
00:13:51,600 --> 00:13:53,300
conflict的意思很直白

419
00:13:53,300 --> 00:13:55,500
就是Git發現同一段程式碼內容

420
00:13:55,500 --> 00:13:57,800
現在竟然出現了兩個完全不同的版本

421
00:13:57,800 --> 00:13:59,600
他不知道該聽誰的

422
00:13:59,600 --> 00:14:01,000
在現在ai coding的時代

423
00:14:01,000 --> 00:14:02,200
像clock code這種工具

424
00:14:02,200 --> 00:14:05,300
遇到conflict時是會自己去判斷跟處理的

425
00:14:05,300 --> 00:14:06,900
那他是怎麼處理的呢?

426
00:14:06,900 --> 00:14:08,400
當Git發現衝突時

427
00:14:08,400 --> 00:14:10,600
他會在檔案裡留下一些特殊的標記

428
00:14:10,600 --> 00:14:13,300
把兩邊打架的程式碼上下並列出來

429
00:14:13,300 --> 00:14:14,800
ai看到這些標記之後

430
00:14:14,800 --> 00:14:17,200
會先去分析這兩個版本各自到底想做什麼

431
00:14:17,200 --> 00:14:20,000
然後通常會用以下這三種方式來幫你合併

432
00:14:20,000 --> 00:14:21,500
第一種方式是二選一

433
00:14:21,500 --> 00:14:24,300
如果ai判斷出朋友改的那一版才是最新的邏輯

434
00:14:24,300 --> 00:14:27,000
或者是你原本的寫法有個bug剛好被朋友給修好了

435
00:14:27,000 --> 00:14:28,400
他就會直接捨棄舊的寫法

436
00:14:28,400 --> 00:14:30,000
只保留正確的那一邊

437
00:14:30,000 --> 00:14:31,800
第二種方式是兩邊都留

438
00:14:31,800 --> 00:14:33,700
你可能會想既然兩邊不衝突

439
00:14:33,700 --> 00:14:35,300
Git怎麼還會跳警告呢?

440
00:14:35,300 --> 00:14:37,700
這是因為有時候你們剛好改到的同一行程式

441
00:14:37,700 --> 00:14:38,600
Git比較死板

442
00:14:38,600 --> 00:14:40,200
只要看到同一行被兩個人動過

443
00:14:40,200 --> 00:14:41,700
他就會判定為衝突

444
00:14:41,700 --> 00:14:44,400
比如Gary在清單的最後一行加了理財分類

445
00:14:44,400 --> 00:14:47,000
而朋友也在最後一行加了日常分類

446
00:14:47,000 --> 00:14:48,700
Git嚇死了以為這就是衝突

447
00:14:48,700 --> 00:14:51,400
但ai看得懂這其實只是在新增不同的項目

448
00:14:51,400 --> 00:14:53,400
他就會很聰明的幫你解開這個衝突

449
00:14:53,400 --> 00:14:55,000
把兩個項目都保留下來

450
00:14:55,000 --> 00:14:56,200
湊進同一個選單裡

451
00:14:56,200 --> 00:14:57,600
皆大歡喜

452
00:14:57,600 --> 00:14:58,900
至於第三種就比較特別啦

453
00:14:58,900 --> 00:15:00,000
叫做打掉重

454
00:15:00,000 --> 00:15:00,760
別人幫你改寫

455
00:15:01,020 --> 00:15:02,040
很多時候

456
00:15:02,300 --> 00:15:04,360
兩個人改的邏輯如果硬生生拼在一起

457
00:15:04,360 --> 00:15:05,880
程式很可能會直接出錯

458
00:15:06,140 --> 00:15:08,440
這時候AI在看懂你們雙方的目的之後

459
00:15:08,440 --> 00:15:10,760
會乾脆把那一段程式碼重寫一遍

460
00:15:10,760 --> 00:15:13,560
用新的寫法把兩邊的功能順順的接在一起

461
00:15:14,080 --> 00:15:16,120
雖然AI有這幾種聰明的合併方法

462
00:15:16,380 --> 00:15:18,440
但他終究不知道你的產品規劃是什麼

463
00:15:18,940 --> 00:15:20,480
如果Gary跟朋友改的邏輯

464
00:15:20,740 --> 00:15:22,280
在產品邏輯上是互相衝突的

465
00:15:22,520 --> 00:15:23,300
AI就會卡住

466
00:15:23,560 --> 00:15:24,840
不知道該選哪一種方法

467
00:15:25,340 --> 00:15:26,120
所以這時候

468
00:15:26,360 --> 00:15:27,140
身為一個vibe coder

469
00:15:27,140 --> 00:15:28,920
你要做的不是自己下去改程式

470
00:15:28,920 --> 00:15:30,200
而是要給出明確的

471
00:15:30,200 --> 00:15:30,960
產品決策

472
00:15:31,220 --> 00:15:32,240
你只要跟AI說

473
00:15:32,500 --> 00:15:33,780
幫我解掉這個conflict

474
00:15:34,300 --> 00:15:36,080
分類列表的邏輯以朋友的為主

475
00:15:36,340 --> 00:15:37,880
但是把我的理財分類

476
00:15:38,140 --> 00:15:39,920
移到右邊的進階選單裡面

477
00:15:40,700 --> 00:15:42,740
只要你把取捨的方向跟規則講清楚

478
00:15:43,000 --> 00:15:45,040
AI就會自己挑選最適合的合併方式

479
00:15:45,300 --> 00:15:46,320
幫你把衝突的程式碼

480
00:15:46,580 --> 00:15:47,360
完美的結合起來

481
00:15:47,860 --> 00:15:48,120
最後

482
00:15:48,380 --> 00:15:50,680
我們來聊聊vibe coder每天都在怕的時刻

483
00:15:50,940 --> 00:15:51,440
那就是

484
00:15:51,700 --> 00:15:53,240
如果AI把程式碼改壞了

485
00:15:53,500 --> 00:15:54,260
到底該怎麼救

486
00:15:54,780 --> 00:15:57,600
這裡我們分成兩種最常見的情境來討論

487
00:15:57,600 --> 00:15:59,140
第一種情境是

488
00:15:59,400 --> 00:16:00,420
你還沒commit

489
00:16:00,920 --> 00:16:02,460
AI剛剛幫你改了一大堆檔案

490
00:16:02,720 --> 00:16:04,260
你跑了一下發現完全不對

491
00:16:04,520 --> 00:16:06,040
但好險你還沒有把他們存成commit

492
00:16:06,560 --> 00:16:08,100
當你有我確定不要這批改動了

493
00:16:08,360 --> 00:16:10,140
我要回到上一次正常狀態的念頭時

494
00:16:10,400 --> 00:16:11,940
對應的動作叫做restore

495
00:16:12,440 --> 00:16:12,960
白話一點說

496
00:16:13,220 --> 00:16:14,500
它就是讓你一鍵獨檔

497
00:16:14,760 --> 00:16:15,780
回到上一次的遊戲存檔點

498
00:16:16,040 --> 00:16:18,600
就當作剛剛AI亂寫的事情完全沒發生過

499
00:16:19,360 --> 00:16:20,120
第二種前進是

500
00:16:20,380 --> 00:16:21,160
你已經commit了

501
00:16:21,660 --> 00:16:22,680
你順手存檔之後

502
00:16:22,940 --> 00:16:23,720
跑了一下程式

503
00:16:23,960 --> 00:16:25,240
才驚覺剛剛那次commit

504
00:16:25,500 --> 00:16:26,020
根本是錯的

505
00:16:26,020 --> 00:16:29,600
這時候比較安全的補救作法通常是revert

506
00:16:30,120 --> 00:16:30,620
要注意喔

507
00:16:30,880 --> 00:16:32,940
revert不是偷偷把你的歷史紀錄給刪掉

508
00:16:33,440 --> 00:16:34,720
它是去新增

509
00:16:34,980 --> 00:16:36,260
一個反向的commit

510
00:16:36,520 --> 00:16:38,560
去把前面那次錯誤的改動給

511
00:16:38,820 --> 00:16:39,340
抵消掉

512
00:16:39,840 --> 00:16:42,140
這個做法在跟朋友合作專案的時候特別安全

513
00:16:42,660 --> 00:16:44,200
因為所有人都能在歷史紀錄裡

514
00:16:44,460 --> 00:16:45,480
看到有加錯的東西

515
00:16:45,740 --> 00:16:47,260
然後又被抵消掉的完整過程

516
00:16:47,520 --> 00:16:50,080
而不會覺得某一段進度怎麼突然憑空消失了

517
00:16:50,860 --> 00:16:51,360
最棒的是

518
00:16:51,620 --> 00:16:53,160
這些指令你其實都不用自己硬背

519
00:16:53,160 --> 00:16:55,200
當你發現AI改壞的時候

520
00:16:55,460 --> 00:16:56,240
你只要直接跟他說

521
00:16:56,480 --> 00:16:57,760
剛剛這次的改動我不要了

522
00:16:58,020 --> 00:16:59,560
請幫我回到上一個正常的版本

523
00:17:00,080 --> 00:17:01,600
AI自己就去判斷現在的狀態

524
00:17:01,860 --> 00:17:03,920
決定該用restore還是revert來幫你處理

525
00:17:04,680 --> 00:17:05,440
好到了這裡

526
00:17:05,700 --> 00:17:07,500
我們來總結一下今天Gary學到了什麼

527
00:17:08,260 --> 00:17:09,040
他現在知道了

528
00:17:09,280 --> 00:17:10,560
寫好的程式可以備份到

529
00:17:10,820 --> 00:17:11,840
Github這個雲端倉庫上

530
00:17:12,100 --> 00:17:13,120
而在上傳之前

531
00:17:13,380 --> 00:17:14,400
必須先設定好Git

532
00:17:14,660 --> 00:17:15,680
來做本機端的版本管理

533
00:17:16,460 --> 00:17:17,740
當AI提到commit的時候

534
00:17:18,000 --> 00:17:20,040
他明白這是在幫程式當下的狀態

535
00:17:20,300 --> 00:17:21,320
留一個存檔快照

536
00:17:21,320 --> 00:17:23,120
當準備要push的時候

537
00:17:23,360 --> 00:17:24,640
就是在把電腦裡的存檔

538
00:17:24,900 --> 00:17:25,920
正式推送到雲端

539
00:17:26,440 --> 00:17:27,460
如果有朋友想加入開發

540
00:17:27,720 --> 00:17:29,260
就請他用clone把專案抓下來

541
00:17:29,520 --> 00:17:30,800
如果朋友上傳了新進度

542
00:17:31,040 --> 00:17:33,100
就用pull把最新的版本拉回自己的電腦裡

543
00:17:33,860 --> 00:17:35,400
當AI準備要大改功能的時候

544
00:17:35,660 --> 00:17:36,940
他會要求開一條branch

545
00:17:37,200 --> 00:17:38,480
當作安全的實驗殺盒

546
00:17:38,980 --> 00:17:41,280
如果想同時讓好幾個AI幫忙做不同的事情

547
00:17:41,540 --> 00:17:42,560
他就會利用worktree

548
00:17:42,820 --> 00:17:45,380
讓每條branch都能擁有自己的實體資料夾

549
00:17:46,160 --> 00:17:47,680
等所有的功能都寫完測試過後

550
00:17:47,940 --> 00:17:49,220
再透過開PR和merge

551
00:17:49,220 --> 00:17:51,260
把成果正式收回到main主線

552
00:17:51,780 --> 00:17:53,580
萬一合併時遇到conflip衝突

553
00:17:54,080 --> 00:17:55,360
他也知道這不是世界末日

554
00:17:55,620 --> 00:17:57,660
這只是Git在等他下達明確的產品決策

555
00:17:58,180 --> 00:18:00,220
而就算AI真的把程式改到無法挽救

556
00:18:00,480 --> 00:18:02,780
只要還沒commit就可以用restore一鍵復原

557
00:18:03,040 --> 00:18:04,320
如果不小心commit了

558
00:18:04,580 --> 00:18:06,880
也可以用revert安全的把錯誤給抵消掉

559
00:18:07,900 --> 00:18:08,420
所以你看

560
00:18:08,680 --> 00:18:09,440
或許對你來說

561
00:18:09,700 --> 00:18:11,240
Git是一堆南北的火星文指令

562
00:18:11,500 --> 00:18:13,020
但你只要有能力指揮就可以了

563
00:18:13,540 --> 00:18:14,560
只要你能把這些概念

564
00:18:14,820 --> 00:18:15,080
對應到

565
00:18:15,340 --> 00:18:17,120
他可以幫你解決開發上的什麼問題

566
00:18:17,120 --> 00:18:18,920
一切也會變得非常好理解

567
00:18:19,680 --> 00:18:22,240
你不需要在今天就逼自己變成Git專家

568
00:18:22,760 --> 00:18:23,260
但你要知道

569
00:18:23,520 --> 00:18:24,280
當cloud

570
00:18:24,540 --> 00:18:25,820
或者是cursor問你要不要commit

571
00:18:26,340 --> 00:18:27,100
要不要開branch

572
00:18:27,360 --> 00:18:27,880
要不要發pr

573
00:18:28,120 --> 00:18:28,380
的時候

574
00:18:28,640 --> 00:18:29,660
他其實是在問你

575
00:18:29,920 --> 00:18:31,200
這次的開發你要不要先存檔

576
00:18:31,720 --> 00:18:33,000
你要不要開個空間來隔離風險

577
00:18:33,240 --> 00:18:36,060
你要不要把寫好的東西交出去給別人檢查

578
00:18:37,080 --> 00:18:38,120
只要這些判斷你聽得懂

579
00:18:38,360 --> 00:18:39,640
你用AI開發就會踏實很多

580
00:18:40,680 --> 00:18:41,180
今天這集

581
00:18:41,440 --> 00:18:43,240
我盡量把Git最核心的幾個情境

582
00:18:43,480 --> 00:18:45,020
用最白話的方式講清楚

583
00:18:45,020 --> 00:18:47,580
不過實際開發時遇到的狀況

584
00:18:47,840 --> 00:18:48,860
其實不止這些

585
00:18:49,120 --> 00:18:50,900
所以我把日常最常見的27個情境

586
00:18:51,160 --> 00:18:52,700
整理成了一份更完整的對照表

587
00:18:52,960 --> 00:18:53,720
每一種狀況

588
00:18:53,980 --> 00:18:55,520
都直接對應到該用的Git指令

589
00:18:55,780 --> 00:18:57,060
還有給AI的提示詞範例

590
00:18:57,560 --> 00:18:59,100
如果你手邊已經有在開發的專案

591
00:18:59,360 --> 00:19:00,380
我也附了一組提示詞

592
00:19:00,640 --> 00:19:02,180
幫你檢查他現在的Git健康度

593
00:19:02,680 --> 00:19:03,700
如果這些對你有幫助

594
00:19:03,960 --> 00:19:05,240
可以來我的Patreon看看

595
00:19:05,500 --> 00:19:06,780
連結我放在資訊欄

596
00:19:07,540 --> 00:19:08,580
那以下就是今天的內容

597
00:19:08,820 --> 00:19:09,340
各位喜歡的話

598
00:19:09,600 --> 00:19:10,880
記得幫我按讚追蹤加分享

599
00:19:11,380 --> 00:19:12,660
這是我持續創作下去的動力

600
00:19:12,920 --> 00:19:13,440
我們下次見

601
00:19:15,020 --> 00:19:17,020
这是我對好的

602
00:19:17,320 --> 00:19:26,460
大家未來的

603
00:19:26,700 --> 00:19:28,480
注意訊欄

604
00:19:29,160 --> 00:19:29,980
沒有

605
00:19:30,360 --> 00:19:31,380
PEIN

606
00:19:32,180 --> 00:19:36,180
你

607
00:19:36,980 --> 00:19:38,040
剛剛

608
00:19:38,300 --> 00:19:38,640
心

（完整逐字稿請見 merged.srt，共 19 分鐘 16 秒，Whisper large-v3-turbo 轉錄）