More Related Content More from Mu Chun Wang (20) Git 經驗分享24. 24
分散式貢獻者模型
● Git core 目前還在使用的模型
● 使用 diff 指令產生差異檔並寄送給相關開發者
●
可以不需使用任何版本控制軟體
●
鼓勵以完整的概念開發後再寄送差異檔
脫離現代軟體開發方式
83. 83
一功能一分支
● 又稱 Dymitruk Model
● 新工作都開新分支 (feature branch) 出來開發,儘
量讓分支不要太大
● 功能完成後合併到整合分支 (integration branch)
●
建置主管可選擇要合併到整合分支的功能有哪些
84. 84
一功能一分支
● 又稱 Dymitruk Model
● 新工作都開新分支 (feature branch) 出來開發,儘
量讓分支不要太大
● 功能完成後合併到整合分支 (integration branch)
●
建置主管可選擇要合併到整合分支的功能有哪些
●
整合分支測試完後再合併到主線
100. 100
Dymitruk Model vs GitHub Flow
● Dymitruk Model :建置時要明確選擇所需要的功
能分支合併到整合分支,然後再合併至主線
● GitHub Flow :當 PR 接受後就馬上合併至主線,
較類似主線開發
107. 107
GitLab Flow
● 導入位置 (location) 的概念
●
透過分支命名的慣例表示目前程式碼的環境
● 個別分支部署到個別的環境內,如: dev,staging,
production
● 應該使用語意化版本 (SemVer)
112. 112
gitworkflows (Git 團隊本身使用 )
● maint :最新穩定版的 Git 及發佈時所有的記錄
● master :應該進入下一次發佈的記錄
● next :實驗一些評估中的功能,會影響 master
的穩定性
● pu :提議更新,包含目前還不適合發行的記錄
113. 113
gitworkflows (Git 團隊本身使用 )
● maint :最新穩定版的 Git 及發佈時所有的記錄
● master :應該進入下一次發佈的記錄
● next :實驗一些評估中的功能,會影響 master
的穩定性
● pu :提議更新,包含目前還不適合發行的記錄
●
每個較低分支都包含一些不在較高分支的記錄
119. 119
GitLab Flow & gitworkflows - 缺點
●
必須要有指南才能知道該從哪個分支開始
●
分支名稱與團隊情境有緊密關係,很難在不同專
案建立一致的結構
146. 146
權限等級
● Owner :專案建立者,如部門經理、變更專案能見
度、移除專案
●
Master :專案執行者最高等級,如小組長、可建立專
案、可建立里程碑、可操作受保護的 branch 、可建立
環境變數、可建立 trigger
● Developer :一般開發者、可建立 MR 、可建立
branch 、可操作不受保護的 branch 、可新增 tag 、可
建立 wiki
●
Reporter :回報者、可取得所有程式碼
● Guest :訪客、可建立 issue 、可留言、觀看 build
log 、下載 build 完的產生物
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) ,不需
存取程式碼,但應該參與專案開發
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
●
…… 等
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
182. 182
使用 bisect
● 當某個 bug 出現,但卻無法得知是哪個
<commit> 造成時的好用工具
●
開發習慣必須良好,每完成一個小段落並且可以
編譯成功就馬上 commit ,而不是一次完成很大
的功能才 commit
192. 192
使用情境
● 本來要用 rebase ,可是卻用錯指令變成 merge
● 本來要合併到分支 A ,可是卻合併到分支 B
●
本來已經準備要發佈新版本,並且合併到主線
了。但發現新版本還沒準備好,所以要取消發佈
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
●
兩個使用者改到同一個檔案的同一行
– 模組化
●
一個使用者改檔案,另一個使用者卻把檔案刪掉
– 模組化
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
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
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 進儲存庫的檔案,如暫存檔、建置完
的檔案
●
取代字串,如密碼
– 敏感資料不想公開出來
239. 239
遇到的問題
● 大掃除後無法 push
– 必須使用 push -f 的方式,強制更新遠端的儲存庫
– 大掃除前先請所有開發者將本地所有分支都 push 到
遠端儲存庫,執行大掃除後再重新 clone 下來,保持
儲存庫的整潔及完整性
240. 240
遇到的問題
● 大掃除後無法 push
– 必須使用 push -f 的方式,強制更新遠端的儲存庫
– 大掃除前先請所有開發者將本地所有分支都 push 到
遠端儲存庫,執行大掃除後再重新 clone 下來,保持
儲存庫的整潔及完整性
●
敏感資料已經外流
241. 241
遇到的問題
● 大掃除後無法 push
– 必須使用 push -f 的方式,強制更新遠端的儲存庫
– 大掃除前先請所有開發者將本地所有分支都 push 到
遠端儲存庫,執行大掃除後再重新 clone 下來,保持
儲存庫的整潔及完整性
●
敏感資料已經外流
– 變更密碼、撤銷 api key ,並確認後續使用 env 取得
244. 244
References
● Git for Teams
● A successful Git branching model
● BFG Repo-Cleaner
● The Dymitruk Model
● GitLab Flow
● GitHub Flow
● MitakeTW@GitHub