介紹 Git & GitCafe，Git & GitCafe 使用方法，最佳實踐 COSCUP 2015 Workshop at Taipei

1. Git 基礎教學
COSCUP 2015 Workshop
Brought to you by GitCafe

2. 關於我們

3. ⺫⽬目的
• 學習 Git 的基本⽤用法
• 學習使⽤用 GitCafe 來為開源專案做貢獻
• 學習使⽤用 GitCafe 來為協作⼀一個專案

4. 規則
• 請各位聽眾嚴格按照 Slides 上的指⽰示⼀一步⼀一步做
• 如果在課程中遇到任何問題，可以詢問助教
• 課後如果還有問題，可以求助於 GitCafe Support
或者 Facebook 群

5. Agenda
• Git 是什麼？GitCafe 是什麼？
• 基本環境配置
• Git 和 GitCafe 的基本⽤用法
• 最佳實踐介紹

6. ⾸首先讓我們舉個例⼦子
以下 33 ⾴頁 Slides 來⾃自 Code Smart, Don't Code hard by 畢⽟玉泉(CrBoy)<crboy@crboy.net>

40. Solution
+

41. Git 是什麼
Git 是當今開源世界中最流⾏行的版本控制系統

42. 版本控制是什麼
追蹤⽂文件變化

43. 版本控制能幫到我什麼
• 看到每⼀一⾏行程式碼修改的原因
• 程式碼如果寫的太爛還能看是誰寫的
• 錯誤的修改可以直接回退
• 幾個版本可以同時存在，任意切換，互相合併

44. GitCafe 是什麼
• 存放開源專案的程式碼
• 發現專案的問題，提交⼯工單，與開發者交流
• ⾃自⼰己有能⼒力改好，提交 PR
• 多⼈人協作⼀一個專案

45. 基礎環境配置

46. 安裝 Git

47. ⼤大家都⽤用什麼操作系統?
• Windows?
• Mac OS X?
• Linux? (Debian? CentOS? OpenSUSE?)
• BSD?
• Solaris?
• ???

48. 安裝在 Windows 上

49. Google “git”

51. git-scm.com

54. 打開安裝包，按 Next

55. Next

56. Next

57. Next

58. Next

59. Next

60. Next

61. Wait

62. 去掉那個鉤，Finish

63. 開始菜單，選擇 Git Bash

64. Git Bash

65. git

66. 看成這樣的提⽰示就算成功

67. 安裝在 Mac OS X 上

68. Homebrew
Mac OS X 下的命令⾏行軟件安裝⼯工具

69. Google “homebrew”

71. brew.sh

72. Copy

73. 打開 spotlight 輸⼊入 terminal

74. terminal

75. paste

76. brew install git

77. git

78. 請⼤大家務必安裝好 Git

79. 安裝 程式碼編輯器

80. ⼤大家都⽤用什麼編輯器寫程式碼?
• Word?
• Notepad?
• Visual Studio?
• Eclipse?
• Vim?
• Emacs?
• Notepad++?
• TextEdit?
• Text Mate?
• Sublime Text?
• Atom?

81. ⼤大家都⽤用什麼編輯器寫程式碼?
• Word?
• Notepad?
• Visual Studio?
• Eclipse?
• Vim?
• Emacs?
• Notepad++?
• TextEdit?
• Text Mate?
• Sublime Text?
• Atom?

82. 程式碼編輯器
• 本次教程需要⼤大家使⽤用程式碼編輯器編輯⽂文本
• ⼤大家可以⾃自由使⽤用⾃自⼰己慣⽤用的程式碼編輯器
• 如果沒有慣⽤用的程式碼編輯器，為了統⼀一不同平
台的編輯器需求，本次教程使⽤用 Atom 作為編輯
器

83. Google “atom”

85. atom.io

87. Atom 安裝指導
• Windows ⽤用⼾戶雙擊安裝包即可直接安裝
• Mac ⽤用⼾戶解壓安裝包並把 app 拖曳到 /
Applications 中去，然後在 Atom 主菜單中選擇
Install Shell Commands

90. GitCafe

91. GitCafe.com

92. 註冊 GitCafe

93. 註冊 GitCafe

94. 註冊 GitCafe

95. 註冊 GitCafe

96. 請⼤大家務必註冊好
GitCafe

97. 還需要做⼀一些配置

98. ~/.gitconfig

99. gitcafe.com/poetries/tang
Copy

100. atom ~/.gitconfig

101. 編輯器
• 通過 atom 命令後⾯面跟⽂文件名就可以⽤用 atom 編輯
該⽂文件
• ⼤大家也可以使⽤用⾃自⼰己慣⽤用的編輯器編輯⽂文件

102. 彈出 Atom 窗⼝口

103. paste

104. 填上你的英⽂文名和郵箱

105. 如果你⽤用的不是 Atom 編輯器還需要在這裡修改設置

106. 然後保存，退出
• Windows ⽤用⼾戶按下 Ctrl + s 保存，然後點擊右上
⾓角的關閉窗⼝口按鈕退出
• Mac ⽤用⼾戶按下 Cmd + s 保存，然後按下 Cmd +
q 退出，注意不要直接按關閉窗⼝口按鈕

107. 完成後開始今天正式的
Git 基礎教程

108. 課程規劃
• 任務⼀一：學習為 GitCafe 的開源項⺫⽬目貢獻代碼
• 任務⼆二：兩名開發者在 GitCafe 上合作完成⼀一個
項⺫⽬目
• 任務三：學習通過分⽀支來幫助項⺫⽬目協作更順利的
完成

109. 任務⼀一
• 現在你看到 GitCafe 上有⼀一個唐詩專案
• gitcafe.com/poetries/tang
• 你發現第⼀一⾸首詩有個地⽅方寫錯了
• 你需要修復這個問題

110. 步驟
1. 打開 gitcafe.com/poetries/tang
2. 複製這個專案到⾃自⼰己的 GitCafe 帳⼾戶
3. 將這個專案的源碼下載到⾃自⼰己的電腦上
4. 在⾃自⼰己的電腦上改正錯誤
5. 提交修改並上傳到 GitCafe
6. 寫信給專案的原作者

111. 在 GitCafe 上複製項⺫⽬目
Remote
Local
別⼈人家的項⺫⽬目v1 我們家的項⺫⽬目v1
複製

112. 下載項⺫⽬目到本地，在本地修改
Remote
Local
我們家的項⺫⽬目v1
我們家的項⺫⽬目v2
下載
我們家的項⺫⽬目v1
修改

113. 下載項⺫⽬目到本地，在本地修改
Remote
Local
我們家的項⺫⽬目v2
上傳
我們家的項⺫⽬目v2
別⼈人家的項⺫⽬目v1
寫信

114. 然後我們就開⼯工吧

115. 打開 gitcafe.com/poetries/tang

116. 選擇 poem1

117. ⼤大家知道這⾸首詩中哪裡有問題嗎?

118. 我們需要為原作者改正這個錯誤

119. 但是在 GitCafe 上，預設情況下⽤用⼾戶
不會對其他⼈人的專案有寫⼊入權限

120. 派⽣生 & 請求合併 這兩個功能就是為
這種情況設計的

121. 點擊右上⾓角的 派⽣生 按鈕

122. 派⽣生 （Fork）
將別⼈人的開源專案複製⼀一份到⾃自⼰己的帳⼾戶下

123. 看到派⽣生成功的提⽰示

124. 複製紅框內的網址

125. 打開 terminal

126. git clone
• 這是我們學習的第⼀一個 git 命令
• git clone 能夠把存放在 GitCafe 上的專案下載到
⾃自⼰己的電腦上

127. git clone，然後 paste

128. git clone，然後 paste

129. 成功的話就是這個效果

130. git clone
• 預設情況下，git clone 會在當前⺫⽬目錄中創建⼀一個
與專案名同名的新⺫⽬目錄
• 例如我們 clone 的這個專案叫 tang，因此新⺫⽬目錄
也就叫 tang
• 所有源碼都會被下載到這個新⺫⽬目錄中
• 這樣⼀一個⺫⽬目錄就叫 Git repo
• ⺫⽬目錄和當前⺫⽬目錄的概念如果不理解請詢問助教

131. ⽤用圖形界⾯面剛剛下載的⺫⽬目錄
• Windows ⽤用⼾戶可以查看 計算機 ➡ 本地磁盤
（C:）➡️ ⽤用⼾戶 ➡ <當前⽤用⼾戶名>
• Mac ⽤用⼾戶可以在 Finder 中⽤用 Cmd + Shift + G 可
以打開 Go to the folder 對話框

132. Windows ⽤用⼾戶驗證⽅方法

133. Finder 下⽤用 Cmd + Shift + G

134. 輸⼊入波浪號 ~，按 Go

135. 輸⼊入波浪號 ~，按 Go

136. 回到 Terminal

137. cd tang

138. cd tang
• 切換當前⺫⽬目錄到 tang 這個⺫⽬目錄下
• 切換當前⺫⽬目錄的概念如果不理解請詢問助教

139. cd tang

140. 然後我們可以看下項⺫⽬目裡⾯面的代碼

141. ls

142. ls
• 列出當前⺫⽬目錄下所有的⽂文件名
• ⽂文件的概念如果不理解請詢問助教

143. 然後我們需要檢查下這些⽂文件
的狀態

144. git status

145. git status
• 這是我們學習的第⼆二條 git 命令
• 這條命令是⽤用來查看當前 Git repo 的狀態
• 仔細閱讀這條命令所顯⽰示的信息，可以幫助我們
知道接下來該做什麼
• 所以這條命令應該經常使⽤用
• 現在它告訴我們當前 Git repo 還沒有被修改過

146. 現在我們需要編輯 poem1

147. atom poem1

148. 編輯器
• 本次教程使⽤用 Atom 作為編輯器
• 通過 atom 命令後⾯面跟⽂文件名就可以⽤用 atom 編輯
該⽂文件
• ⼤大家也可以使⽤用⾃自⼰己慣⽤用的編輯器編輯⽂文件

149. atom poem1

150. 改正錯誤

151. 然後保存，退出
• Windows ⽤用⼾戶按下 Ctrl + s 保存，然後點擊右上
⾓角的關閉窗⼝口按鈕退出
• Mac ⽤用⼾戶按下 Cmd + s 保存，然後按下 Cmd +
q 退出，注意不要直接按關閉窗⼝口按鈕

152. 請再次⽤用 git status 檢查

153. git status
• 正如之前所說的
• 這條命令是⽤用來查看當前 Git repo 的狀態
• 這裏它告訴我們有⼀一個叫 poem1 的⽂文件被修改過
• 仔細閱讀這條命令所顯⽰示的信息，可以幫助我們
知道接下來該做什麼
• 這裏它告訴我們該執⾏行 git add 了

154. git add
• 在 Git 中，所有修改過的⽂文件都需要⽤用 git add 命
令做標記
• 如果修改過的⽂文件沒有被標記，等會 git 就不會提
交這個修改

155. git add poem1

156. 請再次⽤用 git status 檢查

157. git status
• 以紅⾊色顯⽰示的⽂文件表⽰示還沒有被 git add 標記
• 以綠⾊色顯⽰示的⽂文件表⽰示已經被 git add 標記了

158. 然後就可以提交你的修改了

159. git commit
• 這條命令將當前所有被標記為提交的⽂文件提交
• 每次提交都需要⼀一段描述性的語句來解釋修改程
式碼的原因，這被稱為 commit message，通常
是英語
• ⽐比如這裡的 commit message 就可以是 "correct
author"，⼤大家也可以適當發揮
• 為了⽅方便，本次教程統⼀一⽤用 git commit 的 -m 參
數來設置 commit message

160. git commit -m "correct author"

161. git commit -m "correct author"

162. 檢查下⾃自⼰己的提交

163. git log

164. 可以看到你的提交

165. 還可以⽤用 git log -p 查看你具
體的修改內容

166. git log -p

167. git log -p

168. git log -p
• 在預設情況下，git 總是按⾏行⽐比較
• 紅⾊色⾏行表⽰示被刪除的⾏行
• 綠⾊色⾏行表⽰示新增加的⾏行

169. 按 Q 退出 git log -p 的界⾯面

170. 提交完成後，你需要把提交上
傳到 GitCafe 上

171. git push

172. 輸⼊入你的 GitCafe ⽤用⼾戶名

173. 輸⼊入你的 GitCafe 密碼

174. 可以看到 push 成功

175. git push
• git push 會通過網絡將你所有提交上傳到 GitCafe
上
• 由於你電腦上的 Git repo 是通過 git clone 命令從
你帳⼾戶下的 tang 項⺫⽬目中下載的，因此你的提交會
上傳回同樣的地⽅方

176. ⼀一次修改的必要流程
1. 修改程式碼
2. git add <所有要提交的⽂文件>
3. git commit -m "<commit message>"
4. git push

177. 重新打開 GitCafe

178. 點擊 poem1

179. 可以看到你的修改已經⽣生效

180. 但是這還是不夠的

181. 你只是修復了你⾃自⼰己帳⼾戶下的 tang 項⺫⽬目
中的錯誤

182. 原作者此時還不知道你做了修改

183. 這個修復也沒有進⼊入原作者的專案中去

184. 那怎麼辦？

185. 你需要使⽤用請求合併

186. 回到你的專案主⾴頁

187. 在右上⾓角點擊請求合併

188. 然後出現了這樣的⾴頁⾯面

189. 請求合併（Pull Request）
相當於你給原作者寫封信，你要在信中告知它修改
程式碼的原因，以及為何要這麼修改，信中會⾃自動
包含你對他的 Git repo 所做的全部修改
原作者會收到你的信，他可以選擇與你進⼀一步交流，
或者選擇接受你的修改，當然也可以拒絕咯
在 Pull Request 被發明之前，Linux 開源⼩小組確實
⽤用寫信的⽅方法來提交修改的

190. 你需要填寫這封信的內容

191. 然後點擊發送請求合併

192. 然後就完成了

193. 任務⼀一結束

194. 任務⼀一步驟回憶
1. 打開 gitcafe.com/poetries/tang
2. 複製這個專案到⾃自⼰己的 GitCafe 帳⼾戶
3. 將這個專案的源碼下載到⾃自⼰己的電腦上
4. 在⾃自⼰己的電腦上改正錯誤
5. 提交修改並上傳到 GitCafe
6. 寫信給專案的原作者

195. 任務⼀一步驟回憶
1. 打開 gitcafe.com/poetries/tang
2. 點擊“派⽣生”將項⺫⽬目複製⼀一份到⾃自⼰己帳⼾戶下
3. git clone <派⽣生後的項⺫⽬目的地址>
4. 在⾃自⼰己的電腦上改正錯誤
5. git add <所有要提交的⽂文件>
6. git commit -m "<commit message>"
7. git push
8. 在項⺫⽬目中點擊“請求合併”，並填寫內容發送給原作者等待決定

196. 第⼀一階段 Q & A 時間
• 提問
• 跟上節奏
• 相互交流
• 安排分組

197. 任務⼆二
• ⾓角⾊色扮演
• 在場聽眾兩兩分組，假設其中⼀一⼈人為 project owner，⽽而另
⼀一個⼈人充當他的 collaborator
• 兩⼈人合作完成⼀一個寫詩的專案
• Project owner 負責在 GitCafe 創建專案並設置另⼀一名同伴
為他的 collaborator
• Owner 與 collaborator 根據指⽰示交替開發同⼀一專案
• 並且解決交替開發中發⽣生⼀一切的衝突

198. 任務⼆二
• 多⼈人通過 collaborator 的⽅方式同時開發同⼀一專案
最頭疼的情況就是發⽣生衝突
• 任務⼆二的主體就是模擬多種造成衝突的可能情況，
由簡⼊入深，並學習解決衝突的⽅方法

199. ⾸首先 owner 開始創建
專案

200. owner: 創建 project

201. owner: 創建 project

202. owner: 創建 project

203. owner 需要設置
collaborator

204. 相當於賦予其他⽤用⼾戶對
該專案的寫⼊入權限

205. 此時 collaborator 不需
要經過 owner 也可以改
程式碼了

206. owner: 設置協作者

207. owner: 設置協作者

208. owner: 設置協作者

209. 輸⼊入 collaborator 的
⽤用⼾戶名，不要輸錯

210. owner: 設置協作者

211. owner: 設置協作者

212. owner / collaborator: 重新打開 terminal

213. owner / collaborator: git clone
Paste 新項⺫⽬目的地址

214. owner / collaborator: cd my_poetries
Paste 新項⺫⽬目的地址

215. 假設 collaborator 開始編輯
⽂文件並提交到伺服器

216. collaborator: atom README.md

217. collaborator: atom README.md

218. collaborator: atom README.md

219. collaborator: git add README.md

220. collaborator: git commit -m "..."

221. collaborator: git push

222. collaborator push 完後，
owner 需要 pull 最新的修改

223. owner: git pull

224. owner: 注意到 Fast-forward 字樣

225. git pull
• git pull 從伺服器上抓取所有新 push 的提交並且
更新本地的代碼
• 如果執⾏行 git pull 前本地沒有提交過任何代碼，則
顯⽰示 Fast-Forward，表⽰示更新本地代碼沒有問題

226. Fast Forward
Owner
Remote
Collaborator

227. Fast Forward
Owner
Remote
Collaborator

228. Fast Forward
Owner
Remote
Collaborator

229. Fast Forward
Owner
Remote
Collaborator

230. owner: 檢查 pull 之後的結果

231. owner 可以看到 collaborator 的修改

232. 接著由 owner 負責編輯⽂文件
並提交到伺服器

233. owner 繼續修改當前⽂文件

234. owner: git add README.md

235. owner: git commit -m "..."

236. owner: git push

237. collaborator 還不知道
owner 再次 push 了程式碼

238. 但是他覺得寫⾸首詩卻沒有 title
很不好，於是 ...

239. collaborator: 編輯⽂文件

240. collaborator: 編輯⽂文件

241. collaborator: 寫上 title

242. collaborator: git add README.md

243. collaborator: git commit -m "..."

244. collaborator: git push

245. git push 失敗了

246. 只要有其他⼈人在你之前做
過 push，你就不能直接
push

247. 根據提⽰示，你先需要
git pull

248. collaborator: git pull

249. Auto-merging
• 當你執⾏行 git pull 之前提交過代碼，同時其他⼈人在
此之前也 push 過代碼，那麼 Git 會試圖將雙⽅方提
交的代碼合併，並⾃自動解決衝突
• 如果衝突解決成功，就無須⼿手⼯工解決
• 衝突解決後，需要創建⼀一個特殊提交稱之為
merge commit，合併提交本⾝身不包含⽂文件修改，
但是同時基於兩個或兩個以上的提交

250. Merge commit
Owner
Remote
Collaborator

251. Owner commits
Owner
Remote
Collaborator

252. Owner pushes
Owner
Remote
Collaborator

253. Collaborator commits
Owner
Remote
Collaborator

254. Pull
Owner
Remote
Collaborator

255. Merge
Owner
Remote
Collaborator

256. 既然是提交，就有
commit message

257. collaborator: git pull

258. commit message
• git 會⾃自動打開編輯器讓你編輯 commit message
• 預設的 merge commit 已經很清晰，無需修改直
接退出 Atom 即可

259. collaborator: ⾃自動合併結束

260. collaborator: 查看合併結果

261. collaborator: 同時包含雙⽅方的修改

262. collaborator: 再次 git push

263. owner: 也同樣做下 git pull

264. 此時，collaborator 不僅
添加了標題，也寫了詩

265. collaborator: atom README.md

266. collaborator: git add README.md

267. collaborator: git commit -m "..."

268. collaborator: git push

269. 同時 owner 也在⾃自顧⾃自
的寫詩

270. owner: atom README.md

271. owner: git add README.md

272. owner: git commit -m "..."

273. owner: git push

274. owner: git pull

275. git pull 也失敗了

276. 雙⽅方修改有重疊，無法
⾃自動合併

277. Merge commit
Collaborator
Remote
Owner

278. Collaborator commits
Remote
Collaborator Owner

279. Collaborator pushes
Remote
Collaborator Owner

280. Owner commits
Remote
Collaborator Owner

281. Pull
Remote
Collaborator Owner

282. Merge
Remote
Collaborator Owner ??

283. Conflict

284. 看⼀一眼 git status

285. owner: git status

286. git status 告訴我們雙⽅方
對同⼀一個⽂文件做出了衝突
的修改

287. 必須⼿手動解決

288. 需⼿手動解決衝突的情況
• 當雙⽅方都修改了同⼀一個⽂文件的同⼀一⾏行或相鄰⾏行，
修改內容不同
• 當雙⽅方都在同⼀一個⽂文件末尾或開頭增加了內容，
⽽而且內容不同
• 當雙⽅方都創建了⼀一個同名⽂文件，並且內容不同
• 當⼀一⽅方修改了⼀一個⽂文件，⽽而另⼀一⽅方刪除了它
• 還有其他情況

289. ⼿手動解決衝突的⽅方法
• Git 解決衝突的最直觀⽅方法是直接編輯衝突⽂文件

290. owner: atom README.md

291. 通過編輯⽂文件解決衝突
• 從衝突⽂文件的內容可知，衝突部分被⽤用 7 個⼤大於
符號和⼩小於符號包住，並且⽤用 7 個等號分割開來
• 在前⾯面的例⼦子中，⽤用 HEAD 標⽰示的部分為本地衝
突內容，⽽而另⼀一部分為來⾃自伺服器的衝突內容
• 需要⼿手動刪除 >，< 和 =，然後編輯衝突部分，編
輯結果就是衝突解決的最終結果

292. owner: atom README.md

293. 此時 owner 應該判定如何解決衝突

294. 解決衝突
• 選擇⾃自⼰己的修改
• 選擇 collaborator 的修改
• 都保留，但需要適當修改

295. owner: 編輯完畢

296. 合併需要提交 merge commit

297. 在⼿手動解決衝突的情況下，你
需要⾃自⼰己⽤用 git add 標記已經
解決掉衝突的⽂文件

298. 然後執⾏行 git commit 創建
merge commit

299. owner: git add README.md

300. owner: git commit -m "..."

301. owner: git push

302. collaborator: git pull

303. owner 的衝突解決的很好

304. 第⼆二階段 Q & A 時間
• 提問
• 跟上節奏
• 相互交流

305. 任務三
• 繼續⾓角⾊色扮演
• owner 和之前⼀一樣繼續開發這個專案
• ⽽而 collaborator 將創建⼀一個新的分⽀支，在這個分
⽀支中，collaborator 也將同時開發這個專案
• 之後 owner 將 pull 下 collaborator 的新分⽀支，並
將它合併回主分⽀支

306. 什麼是分⽀支
• 在實際的軟件開發中，⼀一個軟件通常會有多個開
發版本在同時開發
• 例如在同⼀一時刻，A，B，C 三個⼯工程師在開發
GitCafe 的程式碼 Highlight 功能，⽽而 D，E，F 三
個⼯工程師在開發 GitCafe 的 PR Line Note 功能，
他們不希望互相影響

307. 什麼是分⽀支
• 如果沒有分⽀支功能，所有程式碼都只在主分⽀支上
提交，那麼這些複雜的功能在開發過程中勢必互
相影響
• 開發到⼀一半的功能還會導致另⼀一部分功能無法正
常使⽤用，其他同事無法在錯誤的狀態下開發新功
能

308. git branch
master
fix/123
highlight
line_note

309. git branch
• Git 的分⽀支功能特別易⽤用⾼高效，它實際上只是版本
樹上浮動的指針
• ⼀一個 Git repo ⾄至少有⼀一個分⽀支，預設情況下，⼀一
個新專案只有⼀一個分⽀支 master，通常也叫主分⽀支

310. owner: atom README.md

311. owner: git add README.md

312. owner: git commit -m "..."

313. owner: git push

314. 同時 collaborator 發現之前的
⼀一⾸首詩《⼭山居秋暝》並沒有寫全

315. 為了不像上次⼀一樣讓 owner 的
git pull 受到影響，於是他創建
⼀一個新的分⽀支來補全這⾸首詩

316. ⾸首先 collaborator 查看了當
前的分⽀支情況

317. collaborator: git branch

318. git branch
• 通過 git branch 命令，可列出所有本地分⽀支名
稱，並⽤用星號指出當前分⽀支

319. 只有 master 分⽀支，這是 git
新專案的預設分⽀支

320. 然後 collaborator 創建⼀一個
新分⽀支，並且切換到新分⽀支上

321. collaborator: git checkout -b cowork

322. 這會在當前 master 分⽀支基礎
上，創建⼀一個新的分⽀支 cowork

323. collaborator: git branch

324. 可以看到新分⽀支 cowork 已經創建，
並且當前分⽀支也變成了 cowork

325. 接著我們就在 cowork 的分⽀支上做
開發

326. collaborator: atom README.md

327. collaborator: git add README.md

328. collaborator: git commit -m "..."

329. 新的提交總是會被提交在當前分⽀支上

330. collaborator: git branch -v

331. git branch -v 提⽰示每個分⽀支的指向
的 commit 的內容

332. collaborator: git lg

333. git lg
• git lg 其實並⾮非⼀一條 git 命令，它其實是⼀一條複雜
的 git log 命令的別名
• git 的別名定義在最初提供的 ~/.gitconfig 中
• 這條命令告訴我們 cowork，也就是當前分⽀支，指
向了 fix poem3 這個 commit，⽽而主分⽀支還停留在
merge conflict 那邊

334. 分⽀支的存在意味著程式碼可以同時存
在多個版本，你可以切換回 master
分⽀支查看當前的程式碼

335. collaborator: git checkout master

336. collaborator: atom README.md

337. 可以看到程式碼回到了之前的狀
態

338. collaborator: git lg

339. 可以看到當前分⽀支切換回了
master，不包含 fix poem3 的修改

340. collaborator: git checkout cowork

341. collaborator: atom README.md

342. ⼀一回到 cowork 分⽀支，之前的修改
⼜又回來了

343. 然後 collaborator 要 push cowork
這個新分⽀支到 GitCafe 伺服器

344. collaborator: git push -u origin cowork

345. 我們可以看到 git push 更複雜的⽤用法
git push -u origin cowork

346. 它的語意是
• 將本地 Git repo 的 cowork 分⽀支 push 到遠端
origin 伺服器的 cowork 分⽀支上
• 如果伺服器上沒有這⼀一分⽀支就創建
• 並且設置當前 cowork 分⽀支對應遠端的 cowork 分
⽀支

347. 它的語意是
master
master
cowork
Remote
Local

348. 它的語意是
master
master
cowork
cowork
Remote
Local

349. 它的語意是
master
master
cowork
cowork
Remote
Local

350. 那麼問題來了，什麼是 origin？
什麼是對應遠端的分⽀支？

351. git remote
• ⼀一個 Git repo 可以有⼀一個或多個遠端伺服器上的
Git repo
• 每個遠端伺服器上的 Git repo 都有⼀一個名稱，預設
名稱是 origin
• 我們的 Git repo 是通過 git clone 命令從 GitCafe
伺服器下載的，因此預設的 origin 伺服器就是這個
repo 在 GitCafe 上的地址
• 可以通過 git remote -v 看到

352. collaborator: git remote -v

353. 遠端分⽀支
• 即遠端 Git repo 上的分⽀支
• 本地的 Git repo 有分⽀支，遠端 Git repo 上⾃自然也要
有分⽀支與本地分⽀支對應
• 遠端分⽀支⼀一律以「遠端 repo 名稱」/「分⽀支名」命
名
• 你不能直接切換到遠端分⽀支上，也不能直接對遠端
分⽀支進⾏行修改
注：這是⼀一個簡化模型，⽤用來簡化我們的教學

354. 遠端分⽀支
• 每⼀一個本地分⽀支可以選擇與⼀一個遠端分⽀支對應
• git status 總是會⾃自動⽐比較當前分⽀支與其對應的遠
端分⽀支的差異，並告知⽤用⼾戶
• git push 可以不總是指定遠端庫和遠端分⽀支，預
設總是上傳到對應的遠端分⽀支
• git pull 也是類似

355. collaborator: git branch -vv

356. git branch -vv 可以列出每個
branch 的對應的遠端分⽀支

357. 我們再來提交⼀一次

358. collaborator: atom README.md

359. collaborator: git add README.md

360. collaborator: git commit -m "..."

361. collaborator: git status

362. git status 提⽰示 cowork 分⽀支⽐比
遠端的 cowork 分⽀支多⼀一個提交

363. collaborator: git push

364. git push 也會⾃自動將 cowork 分
⽀支推送到遠端的 cowork 分⽀支上

365. 回到 owner

366. owner: git lg

367. 可以看到 owner 的數據已經⽼老了

368. owner: git pull

369. 已經提⽰示找到了新的分⽀支

370. git pull 不僅可以更新當前分⽀支，
也可以同步遠端分⽀支

371. 但注意 git pull 不會⾃自動為新的
遠端分⽀支創建對應的本地分⽀支

372. owner: git branch -v

373. owner: git branch -a

374. git branch -a 會同時列出本地分⽀支
和遠端分⽀支的情況，可以看到
cowork 這個遠端分⽀支

375. ⽤用 git lg 會有更加清晰的呈現

376. owner: git lg

377. 可以看到遠端的 cowork 分
⽀支⽐比當前分⽀支多兩個 commit

378. 可以⽤用命令對⽐比⼆二者的區別

379. owner: git log master..origin/cowork

380. git log A..B
• 注意 A 和 B 當中⽤用兩個點連接
• 列出 A 和 B 兩個分⽀支之間的區別
• 更精確的說，列出所有存在於 B 分⽀支卻不存在於
A 分⽀支的提交

381. 不僅可以有提交之間的 對
⽐比，還有程式碼之間的對⽐比

382. owner: git diff master..origin/cowork
紅⾊色的⾏行表⽰示 master 分⽀支有⽽而 origin/cowork 分⽀支沒有的內容
綠⾊色的⾏行表⽰示 origin/cowork 分⽀支有⽽而 master 分⽀支沒有的內容

383. git diff A..B
• git diff 對⽐比兩個分⽀支之間源碼的區別
• 紅⾊色的⾏行表⽰示 A 分⽀支有⽽而 B 分⽀支沒有的內容
• 綠⾊色的⾏行表⽰示 B 分⽀支有⽽而 A 分⽀支沒有的內容
• 從返回的結果可知，遠端的 cowork 分⽀支與
master 分⽀支相⽐比，不僅改了《⼭山居秋暝》，還增
加了《相思》，但沒有《早發⽩白帝城》

384. owner 對 collaborator 的⼯工
作很滿意

385. 現在 owner 需要把 collaborator
的提交合併到主分⽀支中去

386. owner: git merge origin/cowork

387. git merge origin/cowork
• 將 origin/cowork 與當前分⽀支合併
• 與 git pull ⼀一樣，如果合併中發現衝突就要進⼊入⼿手
動合併的流程
• ⼿手動合併的流程與 git pull 也完全⼀一致

388. owner: atom README.md

389. owner: atom README.md

390. owner: 解決衝突

391. owner: git add README.md

392. owner: git commit -m "..."

393. owner: git lg

394. owner: git push

395. 最佳實踐

396. ⽤用⼾戶名/密碼 認證
• 每次 git push 和 git pull 都要輸⼊入⽤用⼾戶名/密碼
• 很⿇麻煩
• 怎麼才能做到不⽤用⼀一直輸⼊入密碼

397. SSH 認證
• ⽐比密碼認證更安全並且也更⽅方便
• ⾸首次使⽤用需要在本地⽣生成⼀一對 SSH 密鑰
• 然後將公鑰內容填寫在 GitCafe ⽤用⼾戶設置中
• 今後提交代碼無須再輸⼊入密碼
• 課後可以找助教幫忙設置

398. oh-my-zsh
• 這裏對 Mac ⽤用⼾戶重點推薦下 zsh + oh-my-zsh
• 更友好的⾃自動補全
• ⾃自動提⽰示當前分⽀支
• ⾃自動提⽰示當前 Git repo 有沒有程式碼還沒有提交

399. oh-my-zsh

400. alias
• ⾃自定義⼀一條簡單的命令⽤用來取代⼀一條複雜的命令
• 原本由於過於複雜⽽而不常⽤用的命令，可以通過別
名來簡化使⽤用⽅方法
• 你可以⾃自⼰己修改 ~/.gitconfig 來配置別名

401. alias

402. Learn more

404. www.atlassian.com/git/tutorials

406. progit.org

407. Q&A
如果你對 Git 或者 GitCafe 的⽤用法有任何問題
或者希望獲取 Git 相關的更多詳細資料
Email: support@gitcafe.com
Facebook：開源之道－Git Workshop