Download as PDF, PPTX
Uploaded byMu Chun Wang
Git 經驗分享
本文档分享了Git的基本指令和分支策略，包括常用的指令如git checkout、git merge、git pull等，以及不同的工作模型，如分散式贡献者模型和共处一地贡献者模型。还介绍了各种分支策略，如主线开发和一功能一分支，并对各自的优缺点进行了讨论。最后，提到了GitHub Flow和GitLab Flow等现代开发流程的特点。
More Related Content
Git 經驗分享
- 1.
- 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 利用 binarysearch 的方式找到特定的 <commit>
- 10. 10 git reflog 整個 repo的所有 HEAD 切換記錄
- 11. 11 git push 將本機的 branch推到遠端機器
- 12. 12 git pull 從遠端機器拉 branch回本機並且合併
- 13. 13 git fetch 從遠端機器拉 branch回本機，但不做 合併
- 14.
- 15. 15 git diff 查看檔案或 <commit>之間的變更內容
- 16.
- 17.
- 18.
- 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.
- 26. 26 分散式貢獻者模型 ● 優點 – 強制 codereview ● 缺點
- 27. 27 分散式貢獻者模型 ● 優點 – 強制 codereview ● 缺點 – 分享成果變的很複雜
- 28. 28 分散式貢獻者模型 ● 優點 – 強制 codereview ● 缺點 – 分享成果變的很複雜 – 貢獻者可能要自己設定程式碼代管系統
- 29. 29 分散式貢獻者模型 ● 優點 – 強制 codereview ● 缺點 – 分享成果變的很複雜 – 貢獻者必須要自己設定程式碼代管系統 脫離現代軟體開發方式
- 30.
- 31.
- 32.
- 33.
- 34.
- 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.
- 40. 40 共處一地貢獻者模型 ● 優點 – 強制 codereview ● 缺點 最流行的存取模型
- 41. 41 共處一地貢獻者模型 ● 優點 – 強制 codereview ● 缺點 – 愈多的 <commit> 會造成除錯時的困難 最流行的存取模型
- 42. 42 共處一地貢獻者模型 ● 優點 – 強制 codereview ● 缺點 – 愈多的 <commit> 會造成除錯時的困難 – 每個團體成員都會複製一個儲存庫 最流行的存取模型
- 43. 43 共處一地貢獻者模型 ● 優點 – 強制 codereview ● 缺點 – 愈多的 <commit> 會造成除錯時的困難 – 每個團體成員都會複製一個儲存庫 – 合併一個新成果要多不少步驟 最流行的存取模型
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51. 51 共享維護模型 ● 優點 – 鼓勵清楚的 masterbranch ● 缺點 一開始的存取模型
- 52. 52 共享維護模型 ● 優點 – 鼓勵清楚的 masterbranch ● 缺點 – 鼓勵但不強制大家 code review 一開始的存取模型
- 53. 53 共享維護模型 ● 優點 – 鼓勵清楚的 masterbranch ● 缺點 – 鼓勵但不強制大家 code review – 必須給所有開發者有寫入的權限 一開始的存取模型
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81. 81 一功能一分支 ● 又稱 DymitrukModel ● 新工作都開新分支 (feature branch) 出來開發，儘 量讓分支不要太大
- 82. 82 一功能一分支 ● 又稱 DymitrukModel ● 新工作都開新分支 (feature branch) 出來開發，儘 量讓分支不要太大 ● 功能完成後合併到整合分支 (integration branch)
- 83. 83 一功能一分支 ● 又稱 DymitrukModel ● 新工作都開新分支 (feature branch) 出來開發，儘 量讓分支不要太大 ● 功能完成後合併到整合分支 (integration branch) ● 建置主管可選擇要合併到整合分支的功能有哪些
- 84. 84 一功能一分支 ● 又稱 DymitrukModel ● 新工作都開新分支 (feature branch) 出來開發，儘 量讓分支不要太大 ● 功能完成後合併到整合分支 (integration branch) ● 建置主管可選擇要合併到整合分支的功能有哪些 ● 整合分支測試完後再合併到主線
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93.
- 94.
- 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 vsGitHub Flow
- 99. 99 Dymitruk Model vsGitHub Flow ● Dymitruk Model ：建置時要明確選擇所需要的功 能分支合併到整合分支，然後再合併至主線
- 100. 100 Dymitruk Model vsGitHub Flow ● Dymitruk Model ：建置時要明確選擇所需要的功 能分支合併到整合分支，然後再合併至主線 ● GitHub Flow ：當 PR 接受後就馬上合併至主線， 較類似主線開發
- 101.
- 102.
- 103.
- 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.
- 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.
- 121.
- 122.
- 123.
- 124.
- 125.
- 126.
- 127.
- 128.
- 129.
- 130.
- 131.
- 132.
- 133. 133 專案可視度 ● Private ：必須明確指定使用者權限 ●Internal ：能登入 GitLab 就能 clone 專案
- 134. 134 專案可視度 ● Private ：必須明確指定使用者權限 ●Internal ：能登入 GitLab 就能 clone 專案 ● Public ：不需要認證就能 clone 專案
- 135. 135 專案可視度 ● Private ：必須明確指定使用者權限 ●Internal ：能登入 GitLab 就能 clone 專案 ● Public ：不需要認證就能 clone 專案 預設由 Admin 決定
- 136.
- 137.
- 138. 138 我的建議 ● Private ：適合需要權限控制嚴謹的專案 ●Internal ：使用 fork 及 MR 讓可受限制的開發者 ( 同部門不同專案、同公司不同部門 ) 協同開發
- 139. 139 我的建議 ● Private ：適合需要權限控制嚴謹的專案 ●Internal ：使用 fork 及 MR 讓可受限制的開發者 ( 同部門不同專案、同公司不同部門 ) 協同開發 ● Public ：使用 fork 及 MR 讓外部開發者協同開發
- 140.
- 141.
- 142.
- 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.
- 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.
- 154.
- 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.
- 160. 160 遇到的問題 ● 外部開發者的儲存庫不是 fork的，無法接觸 upstream
- 161.
- 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.
- 171.
- 172.
- 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.
- 181. 181 使用 bisect ● 當某個bug 出現，但卻無法得知是哪個 <commit> 造成時的好用工具
- 182. 182 使用 bisect ● 當某個bug 出現，但卻無法得知是哪個 <commit> 造成時的好用工具 ● 開發習慣必須良好，每完成一個小段落並且可以 編譯成功就馬上 commit ，而不是一次完成很大 的功能才 commit
- 183.
- 184.
- 185.
- 186.
- 187.
- 188.
- 189.
- 190. 190 使用情境 ● 本來要用 rebase，可是卻用錯指令變成 merge
- 191. 191 使用情境 ● 本來要用 rebase，可是卻用錯指令變成 merge ● 本來要合併到分支 A ，可是卻合併到分支 B
- 192. 192 使用情境 ● 本來要用 rebase，可是卻用錯指令變成 merge ● 本來要合併到分支 A ，可是卻合併到分支 B ● 本來已經準備要發佈新版本，並且合併到主線 了。但發現新版本還沒準備好，所以要取消發佈
- 193.
- 194.
- 195.
- 196.
- 197.
- 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.
- 206.
- 207.
- 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.
- 213.
- 214. 214 遇到的問題 ● 沒有每個工作都記錄在 Redmine上 ● 不知道開 sub-issue 的時機
- 215. 215 遇到的問題 ● 沒有每個工作都記錄在 Redmine上 ● 不知道開 sub-issue 的時機 ● 沒有按照 name convention 開 branch
- 216. 216 遇到的問題 ● 沒有每個工作都記錄在 Redmine上 ● 不知道開 sub-issue 的時機 ● 沒有按照 name convention 開 branch ● 不知道要使用 merge 還是 rebase
- 217.
- 218.
- 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.
- 226.
- 227. 227 遇到的問題 ● 開發後期才發現有不該被控管的檔案如何處理？ – 使用 BFG或 filter-branch 將資料清除
- 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.
- 237.
- 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.
- 243.
- 244. 244 References ● Git forTeams ● A successful Git branching model ● BFG Repo-Cleaner ● The Dymitruk Model ● GitLab Flow ● GitHub Flow ● MitakeTW@GitHub
- 245.
- 246.