Git 經驗分享

1. Git 經驗分享
Kewang

2. 2
基本指令

3. 3
git checkout
移動到特定 <commit> ，不會更改現有
branch 的歷史

4. 4
git reset
移動到特定 <commit> ，或許會更改現
有 branch 的歷史

5. 5
git revert
還原特定 <commit> ，會增加新的歷史

6. 6
git merge
合併兩個 branch ，並分為 fast-forward
或 true merge 兩種

7. 7
git rebase
可以把特定 branch 接到另一個 branch
上面

8. 8
git cherry-pick
將特定的 <commit> 合併到特定
branch 上面

9. 9
git bisect
利用 binary search 的方式找到特定的
<commit>

10. 10
git reflog
整個 repo 的所有 HEAD 切換記錄

11. 11
git push
將本機的 branch 推到遠端機器

12. 12
git pull
從遠端機器拉 branch 回本機並且合併

13. 13
git fetch
從遠端機器拉 branch 回本機，但不做
合併

14. 14
git blame
看檔案的每一行是誰做的最後變更

15. 15
git diff
查看檔案或 <commit> 之間的變更內容

16. 16
資料流

17. 17

18. 18
存取模型

19. 19
分散式貢獻者模型

20. 20
分散式貢獻者模型
● Git core 目前還在使用的模型

21. 21
分散式貢獻者模型
● Git core 目前還在使用的模型
● 使用 diff 指令產生差異檔並寄送給相關開發者

22. 22
分散式貢獻者模型
● Git core 目前還在使用的模型
● 使用 diff 指令產生差異檔並寄送給相關開發者
●
可以不需使用任何版本控制軟體

23. 23
分散式貢獻者模型
● Git core 目前還在使用的模型
● 使用 diff 指令產生差異檔並寄送給相關開發者
●
可以不需使用任何版本控制軟體
●
鼓勵以完整的概念開發後再寄送差異檔

24. 24
分散式貢獻者模型
● Git core 目前還在使用的模型
● 使用 diff 指令產生差異檔並寄送給相關開發者
●
可以不需使用任何版本控制軟體
●
鼓勵以完整的概念開發後再寄送差異檔
脫離現代軟體開發方式

25. 25
分散式貢獻者模型
●
優點
●
缺點

26. 26
分散式貢獻者模型
●
優點
– 強制 code review
●
缺點

27. 27
分散式貢獻者模型
●
優點
– 強制 code review
●
缺點
– 分享成果變的很複雜

28. 28
分散式貢獻者模型
●
優點
– 強制 code review
●
缺點
– 分享成果變的很複雜
– 貢獻者可能要自己設定程式碼代管系統

29. 29
分散式貢獻者模型
●
優點
– 強制 code review
●
缺點
– 分享成果變的很複雜
– 貢獻者必須要自己設定程式碼代管系統
脫離現代軟體開發方式

30. 30
分散式貢獻者模型

31. 31
分散式貢獻者模型
脫離現代軟體開發方式

32. 32
共處一地貢獻者模型

33. 33
共處一地貢獻者模型
●
透過中央程式碼代管系統管理

34. 34
共處一地貢獻者模型
●
透過中央程式碼代管系統管理
● 上游 (upstream) 專案擁有完整的控制權

35. 35
共處一地貢獻者模型
●
透過中央程式碼代管系統管理
● 上游 (upstream) 專案擁有完整的控制權
● 貢獻者在代管系統建立專案複本 (fork)

36. 36
共處一地貢獻者模型
●
透過中央程式碼代管系統管理
● 上游 (upstream) 專案擁有完整的控制權
● 貢獻者在代管系統建立專案複本 (fork)
● 貢獻者變更複本並以合併請求 (Pull Request /
Merge Request) 的形式送到上游專案

37. 37
共處一地貢獻者模型
●
透過中央程式碼代管系統管理
● 上游 (upstream) 專案擁有完整的控制權
● 貢獻者在代管系統建立專案複本 (fork)
● 貢獻者變更複本並以合併請求 (Pull Request /
Merge Request) 的形式送到上游專案
● GitHub 為濫觴

38. 38
共處一地貢獻者模型
●
透過中央程式碼代管系統管理
● 上游 (upstream) 專案擁有完整的控制權
● 貢獻者在代管系統建立專案複本 (fork)
● 貢獻者變更複本並以合併請求 (Pull Request /
Merge Request) 的形式送到上游專案
● GitHub 為濫觴
最流行的存取模型

39. 39
共處一地貢獻者模型
●
優點
●
缺點
最流行的存取模型

40. 40
共處一地貢獻者模型
●
優點
– 強制 code review
●
缺點
最流行的存取模型

41. 41
共處一地貢獻者模型
●
優點
– 強制 code review
●
缺點
– 愈多的 <commit> 會造成除錯時的困難
最流行的存取模型

42. 42
共處一地貢獻者模型
●
優點
– 強制 code review
●
缺點
– 愈多的 <commit> 會造成除錯時的困難
– 每個團體成員都會複製一個儲存庫
最流行的存取模型

43. 43
共處一地貢獻者模型
●
優點
– 強制 code review
●
缺點
– 愈多的 <commit> 會造成除錯時的困難
– 每個團體成員都會複製一個儲存庫
– 合併一個新成果要多不少步驟
最流行的存取模型

44. 44
共處一地貢獻者模型
最流行的存取模型

45. 45
共享維護模型

46. 46
共享維護模型
●
一個共享的儲存庫，所有人都擁有寫入權限

47. 47
共享維護模型
●
一個共享的儲存庫，所有人都擁有寫入權限
●
團隊成員彼此要有互信基礎

48. 48
共享維護模型
●
一個共享的儲存庫，所有人都擁有寫入權限
●
團隊成員彼此要有互信基礎
●
所有開發者都在本機工作，完成後再將成果推送
到儲存庫

49. 49
共享維護模型
●
一個共享的儲存庫，所有人都擁有寫入權限
●
團隊成員彼此要有互信基礎
●
所有開發者都在本機工作，完成後再將成果推送
到儲存庫
一開始的存取模型

50. 50
共享維護模型
●
優點
●
缺點
一開始的存取模型

51. 51
共享維護模型
●
優點
– 鼓勵清楚的 master branch
●
缺點
一開始的存取模型

52. 52
共享維護模型
●
優點
– 鼓勵清楚的 master branch
●
缺點
– 鼓勵但不強制大家 code review
一開始的存取模型

53. 53
共享維護模型
●
優點
– 鼓勵清楚的 master branch
●
缺點
– 鼓勵但不強制大家 code review
– 必須給所有開發者有寫入的權限
一開始的存取模型

54. 54
共享維護模型
一開始的存取模型

55. 55
分支策略

56. 56
主線開發

57. 57
主線開發

58. 58
主線開發

59. 59
主線開發
●
最容易理解、最簡單

60. 60
主線開發
●
最容易理解、最簡單
●
所有開發者持續將成果合併到單一分支

61. 61
主線開發
●
最容易理解、最簡單
●
所有開發者持續將成果合併到單一分支
●
維持分支能夠部署的狀態，不應該發生問題

62. 62
主線搭配分支開發

63. 63
主線搭配分支開發

64. 64
主線搭配分支開發

65. 65
主線搭配分支開發
●
專案變大後的必經之路

66. 66
主線搭配分支開發
●
專案變大後的必經之路
●
工作變多：依照工作項目開分支

67. 67
主線搭配分支開發
●
專案變大後的必經之路
●
工作變多：依照工作項目開分支
●
開發者變多：依照開發者開分支

68. 68
主線搭配分支開發
●
專案變大後的必經之路
●
工作變多：依照工作項目開分支
●
開發者變多：依照開發者開分支
●
有成果後就把分支合併進主線

69. 69
主線搭配分支開發
●
專案變大後的必經之路
●
工作變多：依照工作項目開分支
●
開發者變多：依照開發者開分支
●
有成果後就把分支合併進主線
●
主線使用持續部署的方式交付整合後的成果

70. 70
優點

71. 71
優點
●
在專案內不會有過多的分支出現，減少找不到變
更的困擾

72. 72
優點
●
在專案內不會有過多的分支出現，減少找不到變
更的困擾
●
程式變更記錄小，當出現問題時較容易找出問題

73. 73
優點
●
在專案內不會有過多的分支出現，減少找不到變
更的困擾
●
程式變更記錄小，當出現問題時較容易找出問題
●
主線已可供部署，較不會發生上線後緊急修正

74. 74
缺點

75. 75
缺點
●
若沒有測試基礎設施，當合併至主線後發生錯誤
的機率就會變高

76. 76
缺點
●
若沒有測試基礎設施，當合併至主線後發生錯誤
的機率就會變高
●
持續部署的次數頻繁，所以較適合在使用者自動
更新軟體的情境

77. 77
一功能一分支

78. 78
一功能一分支

79. 79
一功能一分支

80. 80
一功能一分支
● 又稱 Dymitruk Model

81. 81
一功能一分支
● 又稱 Dymitruk Model
● 新工作都開新分支 (feature branch) 出來開發，儘
量讓分支不要太大

82. 82
一功能一分支
● 又稱 Dymitruk Model
● 新工作都開新分支 (feature branch) 出來開發，儘
量讓分支不要太大
● 功能完成後合併到整合分支 (integration branch)

83. 83
一功能一分支
● 又稱 Dymitruk Model
● 新工作都開新分支 (feature branch) 出來開發，儘
量讓分支不要太大
● 功能完成後合併到整合分支 (integration branch)
●
建置主管可選擇要合併到整合分支的功能有哪些

84. 84
一功能一分支
● 又稱 Dymitruk Model
● 新工作都開新分支 (feature branch) 出來開發，儘
量讓分支不要太大
● 功能完成後合併到整合分支 (integration branch)
●
建置主管可選擇要合併到整合分支的功能有哪些
●
整合分支測試完後再合併到主線

85. 85
優點

86. 86
優點
●
類似主線開發，可以快速部署

87. 87
優點
●
類似主線開發，可以快速部署
●
建置時可以選擇哪些分支應該合併進主線

88. 88
缺點

89. 89
缺點
●
功能分支完成卻沒有立刻合併到主線時，會花費
額外心力維持功能分支與主線的程式碼一致

90. 90
缺點
●
功能分支完成卻沒有立刻合併到主線時，會花費
額外心力維持功能分支與主線的程式碼一致
●
功能分支命名原則會成為團隊內的語言，若同時
有許多功能則會提高菜鳥加入的門檻

91. 91
缺點
●
功能分支完成卻沒有立刻合併到主線時，會花費
額外心力維持功能分支與主線的程式碼一致
●
功能分支命名原則會成為團隊內的語言，若同時
有許多功能則會提高菜鳥加入的門檻
●
當功能分支合併進主線後，開發者必須刪除功能
分支，會多一些額外工作

92. 92
GitHub Flow

93. 93
GitHub Flow

94. 94
GitHub Flow
●
所有主線的內容都可以被部署

95. 95
GitHub Flow
●
所有主線的內容都可以被部署
● 新工作都開新功能分支 (feature branch) 出來開發

96. 96
GitHub Flow
●
所有主線的內容都可以被部署
● 新工作都開新功能分支 (feature branch) 出來開發
●
功能分支會持續合併來自主線的內容

97. 97
GitHub Flow
●
所有主線的內容都可以被部署
● 新工作都開新功能分支 (feature branch) 出來開發
●
功能分支會持續合併來自主線的內容
● 當功能分支完成時，對主線發出拉取請求 (Pull
Request, PR)

98. 98
Dymitruk Model vs GitHub Flow

99. 99
Dymitruk Model vs GitHub Flow
● Dymitruk Model ：建置時要明確選擇所需要的功
能分支合併到整合分支，然後再合併至主線

100. 100
Dymitruk Model vs GitHub Flow
● Dymitruk Model ：建置時要明確選擇所需要的功
能分支合併到整合分支，然後再合併至主線
● GitHub Flow ：當 PR 接受後就馬上合併至主線，
較類似主線開發

101. 101
GitLab Flow

102. 102
GitLab Flow

103. 103
GitLab Flow

104. 104
GitLab Flow
● 導入位置 (location) 的概念

105. 105
GitLab Flow
● 導入位置 (location) 的概念
●
透過分支命名的慣例表示目前程式碼的環境

106. 106
GitLab Flow
● 導入位置 (location) 的概念
●
透過分支命名的慣例表示目前程式碼的環境
● 個別分支部署到個別的環境內，如： dev,staging,
production

107. 107
GitLab Flow
● 導入位置 (location) 的概念
●
透過分支命名的慣例表示目前程式碼的環境
● 個別分支部署到個別的環境內，如： dev,staging,
production
● 應該使用語意化版本 (SemVer)

108. 108
gitworkflows (Git 團隊本身使用 )

109. 109
gitworkflows (Git 團隊本身使用 )
● maint ：最新穩定版的 Git 及發佈時所有的記錄

110. 110
gitworkflows (Git 團隊本身使用 )
● maint ：最新穩定版的 Git 及發佈時所有的記錄
● master ：應該進入下一次發佈的記錄

111. 111
gitworkflows (Git 團隊本身使用 )
● maint ：最新穩定版的 Git 及發佈時所有的記錄
● master ：應該進入下一次發佈的記錄
● next ：實驗一些評估中的功能，會影響 master
的穩定性

112. 112
gitworkflows (Git 團隊本身使用 )
● maint ：最新穩定版的 Git 及發佈時所有的記錄
● master ：應該進入下一次發佈的記錄
● next ：實驗一些評估中的功能，會影響 master
的穩定性
● pu ：提議更新，包含目前還不適合發行的記錄

113. 113
gitworkflows (Git 團隊本身使用 )
● maint ：最新穩定版的 Git 及發佈時所有的記錄
● master ：應該進入下一次發佈的記錄
● next ：實驗一些評估中的功能，會影響 master
的穩定性
● pu ：提議更新，包含目前還不適合發行的記錄
●
每個較低分支都包含一些不在較高分支的記錄

114. 114
GitLab Flow & gitworkflows - 優點

115. 115
GitLab Flow & gitworkflows - 優點
●
分支名稱符合情境脈絡

116. 116
GitLab Flow & gitworkflows - 優點
●
分支名稱符合情境脈絡
●
不需猜測分支的作用，在合併進度時更易使用正
確的分支

117. 117
GitLab Flow & gitworkflows - 缺點

118. 118
GitLab Flow & gitworkflows - 缺點
●
必須要有指南才能知道該從哪個分支開始

119. 119
GitLab Flow & gitworkflows - 缺點
●
必須要有指南才能知道該從哪個分支開始
●
分支名稱與團隊情境有緊密關係，很難在不同專
案建立一致的結構

120. 120
GitFlow

121. 121

122. 122
優點

123. 123
優點
●
不需在初期就建立全面的測試基礎設施

124. 124
優點
●
不需在初期就建立全面的測試基礎設施
●
遵守相同慣例就能判斷工作時所應該使用的分支

125. 125
優點
●
不需在初期就建立全面的測試基礎設施
●
遵守相同慣例就能判斷工作時所應該使用的分支
●
適合需要分版本的軟體

126. 126
缺點

127. 127
缺點
●
對於不熟悉產品開發各階段的菜鳥來說，會有很
高的負擔

128. 128
缺點
●
對於不熟悉產品開發各階段的菜鳥來說，會有很
高的負擔
●
用錯分支必須花上很大的力氣才能將所有回復

129. 129
缺點
●
對於不熟悉產品開發各階段的菜鳥來說，會有很
高的負擔
●
用錯分支必須花上很大的力氣才能將所有回復
●
無法持續部署

130. 130
GitLab 專案可視度

131. 131
專案可視度

132. 132
專案可視度
● Private ：必須明確指定使用者權限

133. 133
專案可視度
● Private ：必須明確指定使用者權限
● Internal ：能登入 GitLab 就能 clone 專案

134. 134
專案可視度
● Private ：必須明確指定使用者權限
● Internal ：能登入 GitLab 就能 clone 專案
● Public ：不需要認證就能 clone 專案

135. 135
專案可視度
● Private ：必須明確指定使用者權限
● Internal ：能登入 GitLab 就能 clone 專案
● Public ：不需要認證就能 clone 專案
預設由 Admin 決定

136. 136
我的建議

137. 137
我的建議
● Private ：適合需要權限控制嚴謹的專案

138. 138
我的建議
● Private ：適合需要權限控制嚴謹的專案
● Internal ：使用 fork 及 MR 讓可受限制的開發者
( 同部門不同專案、同公司不同部門 ) 協同開發

139. 139
我的建議
● Private ：適合需要權限控制嚴謹的專案
● Internal ：使用 fork 及 MR 讓可受限制的開發者
( 同部門不同專案、同公司不同部門 ) 協同開發
● Public ：使用 fork 及 MR 讓外部開發者協同開發

140. 140
GitLab 權限使用情境

141. 141
權限等級

142. 142
權限等級
● Owner ：專案建立者，如部門經理、變更專案能
見度、移除專案

143. 143
權限等級
● Owner ：專案建立者，如部門經理、變更專案能
見度、移除專案
● Master ：專案執行者最高等級，如小組長、可建
立專案、可建立里程碑、可操作受保護的
branch 、可建立環境變數、可建立 trigger

144. 144
權限等級
● Owner ：專案建立者，如部門經理、變更專案能
見度、移除專案
● Master ：專案執行者最高等級，如小組長、可建
立專案、可建立里程碑、可操作受保護的
branch 、可建立環境變數、可建立 trigger
● Developer ：一般開發者、可建立 MR 、可建立
branch 、可操作不受保護的 branch 、可新增
tag 、可建立 wiki

145. 145
權限等級
● Owner ：專案建立者，如部門經理、變更專案能
見度、移除專案
● Master ：專案執行者最高等級，如小組長、可建
立專案、可建立里程碑、可操作受保護的
branch 、可建立環境變數、可建立 trigger
● Developer ：一般開發者、可建立 MR 、可建立
branch 、可操作不受保護的 branch 、可新增
tag 、可建立 wiki
● Reporter ：回報者、可取得所有程式碼

146. 146
權限等級
● Owner ：專案建立者，如部門經理、變更專案能見
度、移除專案
●
Master ：專案執行者最高等級，如小組長、可建立專
案、可建立里程碑、可操作受保護的 branch 、可建立
環境變數、可建立 trigger
● Developer ：一般開發者、可建立 MR 、可建立
branch 、可操作不受保護的 branch 、可新增 tag 、可
建立 wiki
●
Reporter ：回報者、可取得所有程式碼
● Guest ：訪客、可建立 issue 、可留言、觀看 build
log 、下載 build 完的產生物

147. 147
Git for Teams 的建議

148. 148
Git for Teams 的建議
● Owner ：適合不屬於團隊的管理人員

149. 149
Git for Teams 的建議
● Owner ：適合不屬於團隊的管理人員
● Master ：適合專案領導者及聰明的專案管理人
員，可能會需要隨時間調整團隊組成及權限

150. 150
Git for Teams 的建議
● Owner ：適合不屬於團隊的管理人員
● Master ：適合專案領導者及聰明的專案管理人
員，可能會需要隨時間調整團隊組成及權限
● Developer ：團隊中的大多數成員，可以限制個
別成員對特定 branch 的存取

151. 151
Git for Teams 的建議
● Owner ：適合不屬於團隊的管理人員
● Master ：適合專案領導者及聰明的專案管理人
員，可能會需要隨時間調整團隊組成及權限
● Developer ：團隊中的大多數成員，可以限制個
別成員對特定 branch 的存取
● Reporter ： CTO ，因為不太會直接寫程式碼

152. 152
Git for Teams 的建議
● Owner ：適合不屬於團隊的管理人員
● Master ：適合專案領導者及聰明的專案管理人
員，可能會需要隨時間調整團隊組成及權限
● Developer ：團隊中的大多數成員，可以限制個
別成員對特定 branch 的存取
● Reporter ： CTO ，因為不太會直接寫程式碼
● Guest ：適合給利害關係人 (stakeholder) ，不需
存取程式碼，但應該參與專案開發

153. 153
外包使用情境

154. 154
使用方式

155. 155
使用方式
●
有內部開發者及外部開發者，但不希望外部開發
者輕易動到程式碼時

156. 156
使用方式
●
有內部開發者及外部開發者，但不希望外部開發
者輕易動到程式碼時
● 開啟 fork 功能，讓外部開發者自己 fork 回去，開
發完時用 PR(MR) 的方式合併回 upstream

157. 157
使用方式
●
有內部開發者及外部開發者，但不希望外部開發
者輕易動到程式碼時
● 開啟 fork 功能，讓外部開發者自己 fork 回去，開
發完時用 PR(MR) 的方式合併回 upstream
● 可以做 code review

158. 158
使用方式
●
有內部開發者及外部開發者，但不希望外部開發
者輕易動到程式碼時
● 開啟 fork 功能，讓外部開發者自己 fork 回去，開
發完時用 PR(MR) 的方式合併回 upstream
● 可以做 code review
●
到職的新人可以用相同方式避免弄髒原程式碼

159. 159
遇到的問題

160. 160
遇到的問題
● 外部開發者的儲存庫不是 fork 的，無法接觸
upstream

161. 161
SemVer
Semantic Versioning

162. 162
版本格式：主版號 . 次版號 . 修訂號

163. 163
版本格式：主版號 . 次版號 . 修訂號
● 主版號：當你做了不相容的 API 修改

164. 164
版本格式：主版號 . 次版號 . 修訂號
● 主版號：當你做了不相容的 API 修改
●
次版號：當你做了向下相容的功能性新增

165. 165
版本格式：主版號 . 次版號 . 修訂號
● 主版號：當你做了不相容的 API 修改
●
次版號：當你做了向下相容的功能性新增
●
修訂號：當你做了向下相容的問題修正

166. 166
版本格式：主版號 . 次版號 . 修訂號
● 主版號：當你做了不相容的 API 修改
●
次版號：當你做了向下相容的功能性新增
●
修訂號：當你做了向下相容的問題修正
● 先行版號及版本編譯資訊可以加到「主版號 . 次
版號 . 修訂號」的後面，作為延伸

167. 167
版本格式：主版號 . 次版號 . 修訂號
● 主版號：當你做了不相容的 API 修改
●
次版號：當你做了向下相容的功能性新增
●
修訂號：當你做了向下相容的問題修正
● 先行版號及版本編譯資訊可以加到「主版號 . 次
版號 . 修訂號」的後面，作為延伸
● 以 0.1.0 作為你的初始化開發版本，並在後續的
每次發行時遞增次版號

168. 168
版本格式：主版號 . 次版號 . 修訂號
● 主版號：當你做了不相容的 API 修改
●
次版號：當你做了向下相容的功能性新增
●
修訂號：當你做了向下相容的問題修正
● 先行版號及版本編譯資訊可以加到「主版號 . 次版號 .
修訂號」的後面，作為延伸
● 以 0.1.0 作為你的初始化開發版本，並在後續的每次發
行時遞增次版號
● 1.0.0 版的定義：你的軟體被用於正式環境、有個穩定
的 API 被使用者依賴、擔心向下相容的問題

169. 169
各軟體生態系
● Java ： Maven
● Node.js ： npm
● Ruby ： gem
● PHP ： composer
● Python ： pip
●
…… 等

170. 170
Rebase or Merge

171. 171

172. 172
cherry-pick

173. 173
使用方式
● git cherry-pick <commit>
● git cherry-pick -e <commit>
● git cherry-pick -n <commit>

174. 174
使用方式
● git cherry-pick <commit>
– 通常是在 production 修正 bug 後，把同一個 bug 也在
dev 修復
● git cherry-pick -e <commit>
● git cherry-pick -n <commit>

175. 175
使用方式
● git cherry-pick <commit>
– 通常是在 production 修正 bug 後，把同一個 bug 也在
dev 修復
● git cherry-pick -e <commit>
– 在 cherry-pick 前先編輯 commit message
● git cherry-pick -n <commit>

176. 176
使用方式
● git cherry-pick <commit>
– 通常是在 production 修正 bug 後，把同一個 bug 也在
dev 修復
● git cherry-pick -e <commit>
– 在 cherry-pick 前先編輯 commit message
– 可以搭配 mention 功能，將某個 issue 關閉
● git cherry-pick -n <commit>

177. 177
使用方式
● git cherry-pick <commit>
– 通常是在 production 修正 bug 後，把同一個 bug 也在
dev 修復
● git cherry-pick -e <commit>
– 在 cherry-pick 前先編輯 commit message
– 可以搭配 mention 功能，將某個 issue 關閉
● git cherry-pick -n <commit>
– cherry-pick 時先不 commit ，而是放到 index 裡面一次
commit

178. 178
使用方式
●
git cherry-pick <commit>
– 通常是在 production 修正 bug 後，把同一個 bug 也在 dev
修復
● git cherry-pick -e <commit>
– 在 cherry-pick 前先編輯 commit message
– 可以搭配 mention 功能，將某個 issue 關閉
●
git cherry-pick -n <commit>
– cherry-pick 時先不 commit ，而是放到 index 裡面一次
commit
– 通常用在大範圍的 cherry-pick 上面，類似 squash

179. 179
用 git 找 bug

180. 180
使用 bisect

181. 181
使用 bisect
● 當某個 bug 出現，但卻無法得知是哪個
<commit> 造成時的好用工具

182. 182
使用 bisect
● 當某個 bug 出現，但卻無法得知是哪個
<commit> 造成時的好用工具
●
開發習慣必須良好，每完成一個小段落並且可以
編譯成功就馬上 commit ，而不是一次完成很大
的功能才 commit

183. 183
還原某次的變更

184. 184
還沒 commit

185. 185
還沒 commit

186. 186
已經 commit

187. 187
已經 commit

188. 188
還原某次的合併

189. 189
使用情境

190. 190
使用情境
● 本來要用 rebase ，可是卻用錯指令變成 merge

191. 191
使用情境
● 本來要用 rebase ，可是卻用錯指令變成 merge
● 本來要合併到分支 A ，可是卻合併到分支 B

192. 192
使用情境
● 本來要用 rebase ，可是卻用錯指令變成 merge
● 本來要合併到分支 A ，可是卻合併到分支 B
●
本來已經準備要發佈新版本，並且合併到主線
了。但發現新版本還沒準備好，所以要取消發佈

193. 193
還沒 push

194. 194
還沒 push

195. 195
已經 push

196. 196
已經 push

197. 197
合併衝突原因

198. 198
原因

199. 199
原因
● coding style ，如空白、 TAB 、括號、換行 ...... 等

200. 200
原因
● coding style ，如空白、 TAB 、括號、換行 ...... 等
– 團隊內部最好制定 coding style ，如： EditorConfig

201. 201
原因
● coding style ，如空白、 TAB 、括號、換行 ...... 等
– 團隊內部最好制定 coding style ，如： EditorConfig
●
兩個使用者改到同一個檔案的同一行

202. 202
原因
● coding style ，如空白、 TAB 、括號、換行 ...... 等
– 團隊內部最好制定 coding style ，如： EditorConfig
●
兩個使用者改到同一個檔案的同一行
– 模組化

203. 203
原因
● coding style ，如空白、 TAB 、括號、換行 ...... 等
– 團隊內部最好制定 coding style ，如： EditorConfig
●
兩個使用者改到同一個檔案的同一行
– 模組化
●
一個使用者改檔案，另一個使用者卻把檔案刪掉

204. 204
原因
● coding style ，如空白、 TAB 、括號、換行 ...... 等
– 團隊內部最好制定 coding style ，如： EditorConfig
●
兩個使用者改到同一個檔案的同一行
– 模組化
●
一個使用者改檔案，另一個使用者卻把檔案刪掉
– 模組化

205. 205
與 Redmine 整合

206. 206
使用方式

207. 207
使用方式
● 每個工作都詳實紀錄在 Redmine 上面

208. 208
使用方式
● 每個工作都詳實紀錄在 Redmine 上面
● 開 branch 時依照 issue number 建立，如
feature/145-add-oauth 、 bug/286-login-fail

209. 209
使用方式
● 每個工作都詳實紀錄在 Redmine 上面
● 開 branch 時依照 issue number 建立，如
feature/145-add-oauth 、 bug/286-login-fail
● issue 處理完畢後，合併到其他 branch 建議使用
true merge 方式處理，在線圖上會清楚表現出來

210. 210
使用方式
● 每個工作都詳實紀錄在 Redmine 上面
● 開 branch 時依照 issue number 建立，如
feature/145-add-oauth 、 bug/286-login-fail
● issue 處理完畢後，合併到其他 branch 建議使用
true merge 方式處理，在線圖上會清楚表現出來
● issue 處理完畢時，可以加上 GitHub 的方式直
接關閉 issue

211. 211
使用方式
● 每個工作都詳實紀錄在 Redmine 上面
● 開 branch 時依照 issue number 建立，如
feature/145-add-oauth 、 bug/286-login-fail
● issue 處理完畢後，合併到其他 branch 建議使用
true merge 方式處理，在線圖上會清楚表現出來
● issue 處理完畢時，可以加上 GitHub 的方式直接
關閉 issue
● 使用 tj/git-extras

212. 212
遇到的問題

213. 213
遇到的問題
● 沒有每個工作都記錄在 Redmine 上

214. 214
遇到的問題
● 沒有每個工作都記錄在 Redmine 上
● 不知道開 sub-issue 的時機

215. 215
遇到的問題
● 沒有每個工作都記錄在 Redmine 上
● 不知道開 sub-issue 的時機
● 沒有按照 name convention 開 branch

216. 216
遇到的問題
● 沒有每個工作都記錄在 Redmine 上
● 不知道開 sub-issue 的時機
● 沒有按照 name convention 開 branch
● 不知道要使用 merge 還是 rebase

217. 217
不想所有檔案被控管

218. 218
使用 .gitignore

219. 219
使用 .gitignore
● 定義不需要被 git 控管的檔案規則

220. 220
使用 .gitignore
● 定義不需要被 git 控管的檔案規則
● 暫存檔、建置完的 binary 檔，一般來說是不需被
git 控管

221. 221
使用 .gitignore
● 定義不需要被 git 控管的檔案規則
● 暫存檔、建置完的 binary 檔，一般來說是不需被
git 控管
● 密碼、 token 等各種敏感資料需依照實際情況決
定，如透過 env 取得

222. 222
使用 .gitignore
● 定義不需要被 git 控管的檔案規則
● 暫存檔、建置完的 binary 檔，一般來說是不需被
git 控管
● 密碼、 token 等各種敏感資料需依照實際情況決
定，如透過 env 取得
– 可多利用 framework 已內建的環境切換功能

223. 223
使用 .gitignore
● 定義不需要被 git 控管的檔案規則
● 暫存檔、建置完的 binary 檔，一般來說是不需被
git 控管
● 密碼、 token 等各種敏感資料需依照實際情況決
定，如透過 env 取得
– 可多利用 framework 已內建的環境切換功能
● https://www.gitignore.io

224. 224
使用 .gitignore
● 定義不需要被 git 控管的檔案規則
● 暫存檔、建置完的 binary 檔，一般來說是不需被
git 控管
● 密碼、 token 等各種敏感資料需依照實際情況決
定，如透過 env 取得
– 可多利用 framework 已內建的環境切換功能
● https://www.gitignore.io
– 內建數十種語言、 OS 及 framework

225. 225
遇到的問題

226. 226
遇到的問題
●
開發後期才發現有不該被控管的檔案如何處理？

227. 227
遇到的問題
●
開發後期才發現有不該被控管的檔案如何處理？
– 使用 BFG 或 filter-branch 將資料清除

228. 228
儲存庫大掃除

229. 229
使用 BFG 或 filter-branch

230. 230
使用 BFG 或 filter-branch
●
刪除某些特大檔

231. 231
使用 BFG 或 filter-branch
●
刪除某些特大檔
– git 對於 binary 檔案不會使用 delta 的方式儲存，而是
直接新增 binary 檔案。所以如果儲存庫過大的話，可
以考慮刪除某些特大檔的歷史，如圖檔

232. 232
使用 BFG 或 filter-branch
●
刪除某些特大檔
– git 對於 binary 檔案不會使用 delta 的方式儲存，而是
直接新增 binary 檔案。所以如果儲存庫過大的話，可
以考慮刪除某些特大檔的歷史，如圖檔
●
刪除某些檔案

233. 233
使用 BFG 或 filter-branch
●
刪除某些特大檔
– git 對於 binary 檔案不會使用 delta 的方式儲存，而是
直接新增 binary 檔案。所以如果儲存庫過大的話，可
以考慮刪除某些特大檔的歷史，如圖檔
●
刪除某些檔案
– 不小心 commit 進儲存庫的檔案，如暫存檔、建置完
的檔案

234. 234
使用 BFG 或 filter-branch
●
刪除某些特大檔
– git 對於 binary 檔案不會使用 delta 的方式儲存，而是
直接新增 binary 檔案。所以如果儲存庫過大的話，可
以考慮刪除某些特大檔的歷史，如圖檔
●
刪除某些檔案
– 不小心 commit 進儲存庫的檔案，如暫存檔、建置完
的檔案
●
取代字串，如密碼

235. 235
使用 BFG 或 filter-branch
●
刪除某些特大檔
– git 對於 binary 檔案不會使用 delta 的方式儲存，而是
直接新增 binary 檔案。所以如果儲存庫過大的話，可
以考慮刪除某些特大檔的歷史，如圖檔
●
刪除某些檔案
– 不小心 commit 進儲存庫的檔案，如暫存檔、建置完
的檔案
●
取代字串，如密碼
– 敏感資料不想公開出來

236. 236
遇到的問題

237. 237
遇到的問題
● 大掃除後無法 push

238. 238
遇到的問題
● 大掃除後無法 push
– 必須使用 push -f 的方式，強制更新遠端的儲存庫

239. 239
遇到的問題
● 大掃除後無法 push
– 必須使用 push -f 的方式，強制更新遠端的儲存庫
– 大掃除前先請所有開發者將本地所有分支都 push 到
遠端儲存庫，執行大掃除後再重新 clone 下來，保持
儲存庫的整潔及完整性

240. 240
遇到的問題
● 大掃除後無法 push
– 必須使用 push -f 的方式，強制更新遠端的儲存庫
– 大掃除前先請所有開發者將本地所有分支都 push 到
遠端儲存庫，執行大掃除後再重新 clone 下來，保持
儲存庫的整潔及完整性
●
敏感資料已經外流

241. 241
遇到的問題
● 大掃除後無法 push
– 必須使用 push -f 的方式，強制更新遠端的儲存庫
– 大掃除前先請所有開發者將本地所有分支都 push 到
遠端儲存庫，執行大掃除後再重新 clone 下來，保持
儲存庫的整潔及完整性
●
敏感資料已經外流
– 變更密碼、撤銷 api key ，並確認後續使用 env 取得

242. 242
Git for Teams

243. 243

244. 244
References
● Git for Teams
● A successful Git branching model
● BFG Repo-Cleaner
● The Dymitruk Model
● GitLab Flow
● GitHub Flow
● MitakeTW@GitHub

245. 245
References
●
工程團隊如何做專案與程式碼管理 （二）
●
工程團隊如何做專案與程式碼管理 （三）

246. 246