Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Git 經驗分享

2,649 views

Published on

Git 經驗分享

Published in: Technology

Git 經驗分享

  1. 1. Git 經驗分享 Kewang
  2. 2. 2 基本指令
  3. 3. 3 git checkout 移動到特定 <commit> ,不會更改現有 branch 的歷史
  4. 4. 4 git reset 移動到特定 <commit> ,或許會更改現 有 branch 的歷史
  5. 5. 5 git revert 還原特定 <commit> ,會增加新的歷史
  6. 6. 6 git merge 合併兩個 branch ,並分為 fast-forward 或 true merge 兩種
  7. 7. 7 git rebase 可以把特定 branch 接到另一個 branch 上面
  8. 8. 8 git cherry-pick 將特定的 <commit> 合併到特定 branch 上面
  9. 9. 9 git bisect 利用 binary search 的方式找到特定的 <commit>
  10. 10. 10 git reflog 整個 repo 的所有 HEAD 切換記錄
  11. 11. 11 git push 將本機的 branch 推到遠端機器
  12. 12. 12 git pull 從遠端機器拉 branch 回本機並且合併
  13. 13. 13 git fetch 從遠端機器拉 branch 回本機,但不做 合併
  14. 14. 14 git blame 看檔案的每一行是誰做的最後變更
  15. 15. 15 git diff 查看檔案或 <commit> 之間的變更內容
  16. 16. 16 資料流
  17. 17. 17
  18. 18. 18 存取模型
  19. 19. 19 分散式貢獻者模型
  20. 20. 20 分散式貢獻者模型 ● Git core 目前還在使用的模型
  21. 21. 21 分散式貢獻者模型 ● Git core 目前還在使用的模型 ● 使用 diff 指令產生差異檔並寄送給相關開發者
  22. 22. 22 分散式貢獻者模型 ● Git core 目前還在使用的模型 ● 使用 diff 指令產生差異檔並寄送給相關開發者 ● 可以不需使用任何版本控制軟體
  23. 23. 23 分散式貢獻者模型 ● Git core 目前還在使用的模型 ● 使用 diff 指令產生差異檔並寄送給相關開發者 ● 可以不需使用任何版本控制軟體 ● 鼓勵以完整的概念開發後再寄送差異檔
  24. 24. 24 分散式貢獻者模型 ● Git core 目前還在使用的模型 ● 使用 diff 指令產生差異檔並寄送給相關開發者 ● 可以不需使用任何版本控制軟體 ● 鼓勵以完整的概念開發後再寄送差異檔 脫離現代軟體開發方式
  25. 25. 25 分散式貢獻者模型 ● 優點 ● 缺點
  26. 26. 26 分散式貢獻者模型 ● 優點 – 強制 code review ● 缺點
  27. 27. 27 分散式貢獻者模型 ● 優點 – 強制 code review ● 缺點 – 分享成果變的很複雜
  28. 28. 28 分散式貢獻者模型 ● 優點 – 強制 code review ● 缺點 – 分享成果變的很複雜 – 貢獻者可能要自己設定程式碼代管系統
  29. 29. 29 分散式貢獻者模型 ● 優點 – 強制 code review ● 缺點 – 分享成果變的很複雜 – 貢獻者必須要自己設定程式碼代管系統 脫離現代軟體開發方式
  30. 30. 30 分散式貢獻者模型
  31. 31. 31 分散式貢獻者模型 脫離現代軟體開發方式
  32. 32. 32 共處一地貢獻者模型
  33. 33. 33 共處一地貢獻者模型 ● 透過中央程式碼代管系統管理
  34. 34. 34 共處一地貢獻者模型 ● 透過中央程式碼代管系統管理 ● 上游 (upstream) 專案擁有完整的控制權
  35. 35. 35 共處一地貢獻者模型 ● 透過中央程式碼代管系統管理 ● 上游 (upstream) 專案擁有完整的控制權 ● 貢獻者在代管系統建立專案複本 (fork)
  36. 36. 36 共處一地貢獻者模型 ● 透過中央程式碼代管系統管理 ● 上游 (upstream) 專案擁有完整的控制權 ● 貢獻者在代管系統建立專案複本 (fork) ● 貢獻者變更複本並以合併請求 (Pull Request / Merge Request) 的形式送到上游專案
  37. 37. 37 共處一地貢獻者模型 ● 透過中央程式碼代管系統管理 ● 上游 (upstream) 專案擁有完整的控制權 ● 貢獻者在代管系統建立專案複本 (fork) ● 貢獻者變更複本並以合併請求 (Pull Request / Merge Request) 的形式送到上游專案 ● GitHub 為濫觴
  38. 38. 38 共處一地貢獻者模型 ● 透過中央程式碼代管系統管理 ● 上游 (upstream) 專案擁有完整的控制權 ● 貢獻者在代管系統建立專案複本 (fork) ● 貢獻者變更複本並以合併請求 (Pull Request / Merge Request) 的形式送到上游專案 ● GitHub 為濫觴 最流行的存取模型
  39. 39. 39 共處一地貢獻者模型 ● 優點 ● 缺點 最流行的存取模型
  40. 40. 40 共處一地貢獻者模型 ● 優點 – 強制 code review ● 缺點 最流行的存取模型
  41. 41. 41 共處一地貢獻者模型 ● 優點 – 強制 code review ● 缺點 – 愈多的 <commit> 會造成除錯時的困難 最流行的存取模型
  42. 42. 42 共處一地貢獻者模型 ● 優點 – 強制 code review ● 缺點 – 愈多的 <commit> 會造成除錯時的困難 – 每個團體成員都會複製一個儲存庫 最流行的存取模型
  43. 43. 43 共處一地貢獻者模型 ● 優點 – 強制 code review ● 缺點 – 愈多的 <commit> 會造成除錯時的困難 – 每個團體成員都會複製一個儲存庫 – 合併一個新成果要多不少步驟 最流行的存取模型
  44. 44. 44 共處一地貢獻者模型 最流行的存取模型
  45. 45. 45 共享維護模型
  46. 46. 46 共享維護模型 ● 一個共享的儲存庫,所有人都擁有寫入權限
  47. 47. 47 共享維護模型 ● 一個共享的儲存庫,所有人都擁有寫入權限 ● 團隊成員彼此要有互信基礎
  48. 48. 48 共享維護模型 ● 一個共享的儲存庫,所有人都擁有寫入權限 ● 團隊成員彼此要有互信基礎 ● 所有開發者都在本機工作,完成後再將成果推送 到儲存庫
  49. 49. 49 共享維護模型 ● 一個共享的儲存庫,所有人都擁有寫入權限 ● 團隊成員彼此要有互信基礎 ● 所有開發者都在本機工作,完成後再將成果推送 到儲存庫 一開始的存取模型
  50. 50. 50 共享維護模型 ● 優點 ● 缺點 一開始的存取模型
  51. 51. 51 共享維護模型 ● 優點 – 鼓勵清楚的 master branch ● 缺點 一開始的存取模型
  52. 52. 52 共享維護模型 ● 優點 – 鼓勵清楚的 master branch ● 缺點 – 鼓勵但不強制大家 code review 一開始的存取模型
  53. 53. 53 共享維護模型 ● 優點 – 鼓勵清楚的 master branch ● 缺點 – 鼓勵但不強制大家 code review – 必須給所有開發者有寫入的權限 一開始的存取模型
  54. 54. 54 共享維護模型 一開始的存取模型
  55. 55. 55 分支策略
  56. 56. 56 主線開發
  57. 57. 57 主線開發
  58. 58. 58 主線開發
  59. 59. 59 主線開發 ● 最容易理解、最簡單
  60. 60. 60 主線開發 ● 最容易理解、最簡單 ● 所有開發者持續將成果合併到單一分支
  61. 61. 61 主線開發 ● 最容易理解、最簡單 ● 所有開發者持續將成果合併到單一分支 ● 維持分支能夠部署的狀態,不應該發生問題
  62. 62. 62 主線搭配分支開發
  63. 63. 63 主線搭配分支開發
  64. 64. 64 主線搭配分支開發
  65. 65. 65 主線搭配分支開發 ● 專案變大後的必經之路
  66. 66. 66 主線搭配分支開發 ● 專案變大後的必經之路 ● 工作變多:依照工作項目開分支
  67. 67. 67 主線搭配分支開發 ● 專案變大後的必經之路 ● 工作變多:依照工作項目開分支 ● 開發者變多:依照開發者開分支
  68. 68. 68 主線搭配分支開發 ● 專案變大後的必經之路 ● 工作變多:依照工作項目開分支 ● 開發者變多:依照開發者開分支 ● 有成果後就把分支合併進主線
  69. 69. 69 主線搭配分支開發 ● 專案變大後的必經之路 ● 工作變多:依照工作項目開分支 ● 開發者變多:依照開發者開分支 ● 有成果後就把分支合併進主線 ● 主線使用持續部署的方式交付整合後的成果
  70. 70. 70 優點
  71. 71. 71 優點 ● 在專案內不會有過多的分支出現,減少找不到變 更的困擾
  72. 72. 72 優點 ● 在專案內不會有過多的分支出現,減少找不到變 更的困擾 ● 程式變更記錄小,當出現問題時較容易找出問題
  73. 73. 73 優點 ● 在專案內不會有過多的分支出現,減少找不到變 更的困擾 ● 程式變更記錄小,當出現問題時較容易找出問題 ● 主線已可供部署,較不會發生上線後緊急修正
  74. 74. 74 缺點
  75. 75. 75 缺點 ● 若沒有測試基礎設施,當合併至主線後發生錯誤 的機率就會變高
  76. 76. 76 缺點 ● 若沒有測試基礎設施,當合併至主線後發生錯誤 的機率就會變高 ● 持續部署的次數頻繁,所以較適合在使用者自動 更新軟體的情境
  77. 77. 77 一功能一分支
  78. 78. 78 一功能一分支
  79. 79. 79 一功能一分支
  80. 80. 80 一功能一分支 ● 又稱 Dymitruk Model
  81. 81. 81 一功能一分支 ● 又稱 Dymitruk Model ● 新工作都開新分支 (feature branch) 出來開發,儘 量讓分支不要太大
  82. 82. 82 一功能一分支 ● 又稱 Dymitruk Model ● 新工作都開新分支 (feature branch) 出來開發,儘 量讓分支不要太大 ● 功能完成後合併到整合分支 (integration branch)
  83. 83. 83 一功能一分支 ● 又稱 Dymitruk Model ● 新工作都開新分支 (feature branch) 出來開發,儘 量讓分支不要太大 ● 功能完成後合併到整合分支 (integration branch) ● 建置主管可選擇要合併到整合分支的功能有哪些
  84. 84. 84 一功能一分支 ● 又稱 Dymitruk Model ● 新工作都開新分支 (feature branch) 出來開發,儘 量讓分支不要太大 ● 功能完成後合併到整合分支 (integration branch) ● 建置主管可選擇要合併到整合分支的功能有哪些 ● 整合分支測試完後再合併到主線
  85. 85. 85 優點
  86. 86. 86 優點 ● 類似主線開發,可以快速部署
  87. 87. 87 優點 ● 類似主線開發,可以快速部署 ● 建置時可以選擇哪些分支應該合併進主線
  88. 88. 88 缺點
  89. 89. 89 缺點 ● 功能分支完成卻沒有立刻合併到主線時,會花費 額外心力維持功能分支與主線的程式碼一致
  90. 90. 90 缺點 ● 功能分支完成卻沒有立刻合併到主線時,會花費 額外心力維持功能分支與主線的程式碼一致 ● 功能分支命名原則會成為團隊內的語言,若同時 有許多功能則會提高菜鳥加入的門檻
  91. 91. 91 缺點 ● 功能分支完成卻沒有立刻合併到主線時,會花費 額外心力維持功能分支與主線的程式碼一致 ● 功能分支命名原則會成為團隊內的語言,若同時 有許多功能則會提高菜鳥加入的門檻 ● 當功能分支合併進主線後,開發者必須刪除功能 分支,會多一些額外工作
  92. 92. 92 GitHub Flow
  93. 93. 93 GitHub Flow
  94. 94. 94 GitHub Flow ● 所有主線的內容都可以被部署
  95. 95. 95 GitHub Flow ● 所有主線的內容都可以被部署 ● 新工作都開新功能分支 (feature branch) 出來開發
  96. 96. 96 GitHub Flow ● 所有主線的內容都可以被部署 ● 新工作都開新功能分支 (feature branch) 出來開發 ● 功能分支會持續合併來自主線的內容
  97. 97. 97 GitHub Flow ● 所有主線的內容都可以被部署 ● 新工作都開新功能分支 (feature branch) 出來開發 ● 功能分支會持續合併來自主線的內容 ● 當功能分支完成時,對主線發出拉取請求 (Pull Request, PR)
  98. 98. 98 Dymitruk Model vs GitHub Flow
  99. 99. 99 Dymitruk Model vs GitHub Flow ● Dymitruk Model :建置時要明確選擇所需要的功 能分支合併到整合分支,然後再合併至主線
  100. 100. 100 Dymitruk Model vs GitHub Flow ● Dymitruk Model :建置時要明確選擇所需要的功 能分支合併到整合分支,然後再合併至主線 ● GitHub Flow :當 PR 接受後就馬上合併至主線, 較類似主線開發
  101. 101. 101 GitLab Flow
  102. 102. 102 GitLab Flow
  103. 103. 103 GitLab Flow
  104. 104. 104 GitLab Flow ● 導入位置 (location) 的概念
  105. 105. 105 GitLab Flow ● 導入位置 (location) 的概念 ● 透過分支命名的慣例表示目前程式碼的環境
  106. 106. 106 GitLab Flow ● 導入位置 (location) 的概念 ● 透過分支命名的慣例表示目前程式碼的環境 ● 個別分支部署到個別的環境內,如: dev,staging, production
  107. 107. 107 GitLab Flow ● 導入位置 (location) 的概念 ● 透過分支命名的慣例表示目前程式碼的環境 ● 個別分支部署到個別的環境內,如: dev,staging, production ● 應該使用語意化版本 (SemVer)
  108. 108. 108 gitworkflows (Git 團隊本身使用 )
  109. 109. 109 gitworkflows (Git 團隊本身使用 ) ● maint :最新穩定版的 Git 及發佈時所有的記錄
  110. 110. 110 gitworkflows (Git 團隊本身使用 ) ● maint :最新穩定版的 Git 及發佈時所有的記錄 ● master :應該進入下一次發佈的記錄
  111. 111. 111 gitworkflows (Git 團隊本身使用 ) ● maint :最新穩定版的 Git 及發佈時所有的記錄 ● master :應該進入下一次發佈的記錄 ● next :實驗一些評估中的功能,會影響 master 的穩定性
  112. 112. 112 gitworkflows (Git 團隊本身使用 ) ● maint :最新穩定版的 Git 及發佈時所有的記錄 ● master :應該進入下一次發佈的記錄 ● next :實驗一些評估中的功能,會影響 master 的穩定性 ● pu :提議更新,包含目前還不適合發行的記錄
  113. 113. 113 gitworkflows (Git 團隊本身使用 ) ● maint :最新穩定版的 Git 及發佈時所有的記錄 ● master :應該進入下一次發佈的記錄 ● next :實驗一些評估中的功能,會影響 master 的穩定性 ● pu :提議更新,包含目前還不適合發行的記錄 ● 每個較低分支都包含一些不在較高分支的記錄
  114. 114. 114 GitLab Flow & gitworkflows - 優點
  115. 115. 115 GitLab Flow & gitworkflows - 優點 ● 分支名稱符合情境脈絡
  116. 116. 116 GitLab Flow & gitworkflows - 優點 ● 分支名稱符合情境脈絡 ● 不需猜測分支的作用,在合併進度時更易使用正 確的分支
  117. 117. 117 GitLab Flow & gitworkflows - 缺點
  118. 118. 118 GitLab Flow & gitworkflows - 缺點 ● 必須要有指南才能知道該從哪個分支開始
  119. 119. 119 GitLab Flow & gitworkflows - 缺點 ● 必須要有指南才能知道該從哪個分支開始 ● 分支名稱與團隊情境有緊密關係,很難在不同專 案建立一致的結構
  120. 120. 120 GitFlow
  121. 121. 121
  122. 122. 122 優點
  123. 123. 123 優點 ● 不需在初期就建立全面的測試基礎設施
  124. 124. 124 優點 ● 不需在初期就建立全面的測試基礎設施 ● 遵守相同慣例就能判斷工作時所應該使用的分支
  125. 125. 125 優點 ● 不需在初期就建立全面的測試基礎設施 ● 遵守相同慣例就能判斷工作時所應該使用的分支 ● 適合需要分版本的軟體
  126. 126. 126 缺點
  127. 127. 127 缺點 ● 對於不熟悉產品開發各階段的菜鳥來說,會有很 高的負擔
  128. 128. 128 缺點 ● 對於不熟悉產品開發各階段的菜鳥來說,會有很 高的負擔 ● 用錯分支必須花上很大的力氣才能將所有回復
  129. 129. 129 缺點 ● 對於不熟悉產品開發各階段的菜鳥來說,會有很 高的負擔 ● 用錯分支必須花上很大的力氣才能將所有回復 ● 無法持續部署
  130. 130. 130 GitLab 專案可視度
  131. 131. 131 專案可視度
  132. 132. 132 專案可視度 ● Private :必須明確指定使用者權限
  133. 133. 133 專案可視度 ● Private :必須明確指定使用者權限 ● Internal :能登入 GitLab 就能 clone 專案
  134. 134. 134 專案可視度 ● Private :必須明確指定使用者權限 ● Internal :能登入 GitLab 就能 clone 專案 ● Public :不需要認證就能 clone 專案
  135. 135. 135 專案可視度 ● Private :必須明確指定使用者權限 ● Internal :能登入 GitLab 就能 clone 專案 ● Public :不需要認證就能 clone 專案 預設由 Admin 決定
  136. 136. 136 我的建議
  137. 137. 137 我的建議 ● Private :適合需要權限控制嚴謹的專案
  138. 138. 138 我的建議 ● Private :適合需要權限控制嚴謹的專案 ● Internal :使用 fork 及 MR 讓可受限制的開發者 ( 同部門不同專案、同公司不同部門 ) 協同開發
  139. 139. 139 我的建議 ● Private :適合需要權限控制嚴謹的專案 ● Internal :使用 fork 及 MR 讓可受限制的開發者 ( 同部門不同專案、同公司不同部門 ) 協同開發 ● Public :使用 fork 及 MR 讓外部開發者協同開發
  140. 140. 140 GitLab 權限使用情境
  141. 141. 141 權限等級
  142. 142. 142 權限等級 ● Owner :專案建立者,如部門經理、變更專案能 見度、移除專案
  143. 143. 143 權限等級 ● Owner :專案建立者,如部門經理、變更專案能 見度、移除專案 ● Master :專案執行者最高等級,如小組長、可建 立專案、可建立里程碑、可操作受保護的 branch 、可建立環境變數、可建立 trigger
  144. 144. 144 權限等級 ● Owner :專案建立者,如部門經理、變更專案能 見度、移除專案 ● Master :專案執行者最高等級,如小組長、可建 立專案、可建立里程碑、可操作受保護的 branch 、可建立環境變數、可建立 trigger ● Developer :一般開發者、可建立 MR 、可建立 branch 、可操作不受保護的 branch 、可新增 tag 、可建立 wiki
  145. 145. 145 權限等級 ● Owner :專案建立者,如部門經理、變更專案能 見度、移除專案 ● Master :專案執行者最高等級,如小組長、可建 立專案、可建立里程碑、可操作受保護的 branch 、可建立環境變數、可建立 trigger ● Developer :一般開發者、可建立 MR 、可建立 branch 、可操作不受保護的 branch 、可新增 tag 、可建立 wiki ● Reporter :回報者、可取得所有程式碼
  146. 146. 146 權限等級 ● Owner :專案建立者,如部門經理、變更專案能見 度、移除專案 ● Master :專案執行者最高等級,如小組長、可建立專 案、可建立里程碑、可操作受保護的 branch 、可建立 環境變數、可建立 trigger ● Developer :一般開發者、可建立 MR 、可建立 branch 、可操作不受保護的 branch 、可新增 tag 、可 建立 wiki ● Reporter :回報者、可取得所有程式碼 ● Guest :訪客、可建立 issue 、可留言、觀看 build log 、下載 build 完的產生物
  147. 147. 147 Git for Teams 的建議
  148. 148. 148 Git for Teams 的建議 ● Owner :適合不屬於團隊的管理人員
  149. 149. 149 Git for Teams 的建議 ● Owner :適合不屬於團隊的管理人員 ● Master :適合專案領導者及聰明的專案管理人 員,可能會需要隨時間調整團隊組成及權限
  150. 150. 150 Git for Teams 的建議 ● Owner :適合不屬於團隊的管理人員 ● Master :適合專案領導者及聰明的專案管理人 員,可能會需要隨時間調整團隊組成及權限 ● Developer :團隊中的大多數成員,可以限制個 別成員對特定 branch 的存取
  151. 151. 151 Git for Teams 的建議 ● Owner :適合不屬於團隊的管理人員 ● Master :適合專案領導者及聰明的專案管理人 員,可能會需要隨時間調整團隊組成及權限 ● Developer :團隊中的大多數成員,可以限制個 別成員對特定 branch 的存取 ● Reporter : CTO ,因為不太會直接寫程式碼
  152. 152. 152 Git for Teams 的建議 ● Owner :適合不屬於團隊的管理人員 ● Master :適合專案領導者及聰明的專案管理人 員,可能會需要隨時間調整團隊組成及權限 ● Developer :團隊中的大多數成員,可以限制個 別成員對特定 branch 的存取 ● Reporter : CTO ,因為不太會直接寫程式碼 ● Guest :適合給利害關係人 (stakeholder) ,不需 存取程式碼,但應該參與專案開發
  153. 153. 153 外包使用情境
  154. 154. 154 使用方式
  155. 155. 155 使用方式 ● 有內部開發者及外部開發者,但不希望外部開發 者輕易動到程式碼時
  156. 156. 156 使用方式 ● 有內部開發者及外部開發者,但不希望外部開發 者輕易動到程式碼時 ● 開啟 fork 功能,讓外部開發者自己 fork 回去,開 發完時用 PR(MR) 的方式合併回 upstream
  157. 157. 157 使用方式 ● 有內部開發者及外部開發者,但不希望外部開發 者輕易動到程式碼時 ● 開啟 fork 功能,讓外部開發者自己 fork 回去,開 發完時用 PR(MR) 的方式合併回 upstream ● 可以做 code review
  158. 158. 158 使用方式 ● 有內部開發者及外部開發者,但不希望外部開發 者輕易動到程式碼時 ● 開啟 fork 功能,讓外部開發者自己 fork 回去,開 發完時用 PR(MR) 的方式合併回 upstream ● 可以做 code review ● 到職的新人可以用相同方式避免弄髒原程式碼
  159. 159. 159 遇到的問題
  160. 160. 160 遇到的問題 ● 外部開發者的儲存庫不是 fork 的,無法接觸 upstream
  161. 161. 161 SemVer Semantic Versioning
  162. 162. 162 版本格式:主版號 . 次版號 . 修訂號
  163. 163. 163 版本格式:主版號 . 次版號 . 修訂號 ● 主版號:當你做了不相容的 API 修改
  164. 164. 164 版本格式:主版號 . 次版號 . 修訂號 ● 主版號:當你做了不相容的 API 修改 ● 次版號:當你做了向下相容的功能性新增
  165. 165. 165 版本格式:主版號 . 次版號 . 修訂號 ● 主版號:當你做了不相容的 API 修改 ● 次版號:當你做了向下相容的功能性新增 ● 修訂號:當你做了向下相容的問題修正
  166. 166. 166 版本格式:主版號 . 次版號 . 修訂號 ● 主版號:當你做了不相容的 API 修改 ● 次版號:當你做了向下相容的功能性新增 ● 修訂號:當你做了向下相容的問題修正 ● 先行版號及版本編譯資訊可以加到「主版號 . 次 版號 . 修訂號」的後面,作為延伸
  167. 167. 167 版本格式:主版號 . 次版號 . 修訂號 ● 主版號:當你做了不相容的 API 修改 ● 次版號:當你做了向下相容的功能性新增 ● 修訂號:當你做了向下相容的問題修正 ● 先行版號及版本編譯資訊可以加到「主版號 . 次 版號 . 修訂號」的後面,作為延伸 ● 以 0.1.0 作為你的初始化開發版本,並在後續的 每次發行時遞增次版號
  168. 168. 168 版本格式:主版號 . 次版號 . 修訂號 ● 主版號:當你做了不相容的 API 修改 ● 次版號:當你做了向下相容的功能性新增 ● 修訂號:當你做了向下相容的問題修正 ● 先行版號及版本編譯資訊可以加到「主版號 . 次版號 . 修訂號」的後面,作為延伸 ● 以 0.1.0 作為你的初始化開發版本,並在後續的每次發 行時遞增次版號 ● 1.0.0 版的定義:你的軟體被用於正式環境、有個穩定 的 API 被使用者依賴、擔心向下相容的問題
  169. 169. 169 各軟體生態系 ● Java : Maven ● Node.js : npm ● Ruby : gem ● PHP : composer ● Python : pip ● …… 等
  170. 170. 170 Rebase or Merge
  171. 171. 171
  172. 172. 172 cherry-pick
  173. 173. 173 使用方式 ● git cherry-pick <commit> ● git cherry-pick -e <commit> ● git cherry-pick -n <commit>
  174. 174. 174 使用方式 ● git cherry-pick <commit> – 通常是在 production 修正 bug 後,把同一個 bug 也在 dev 修復 ● git cherry-pick -e <commit> ● git cherry-pick -n <commit>
  175. 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. 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. 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. 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. 179 用 git 找 bug
  180. 180. 180 使用 bisect
  181. 181. 181 使用 bisect ● 當某個 bug 出現,但卻無法得知是哪個 <commit> 造成時的好用工具
  182. 182. 182 使用 bisect ● 當某個 bug 出現,但卻無法得知是哪個 <commit> 造成時的好用工具 ● 開發習慣必須良好,每完成一個小段落並且可以 編譯成功就馬上 commit ,而不是一次完成很大 的功能才 commit
  183. 183. 183 還原某次的變更
  184. 184. 184 還沒 commit
  185. 185. 185 還沒 commit
  186. 186. 186 已經 commit
  187. 187. 187 已經 commit
  188. 188. 188 還原某次的合併
  189. 189. 189 使用情境
  190. 190. 190 使用情境 ● 本來要用 rebase ,可是卻用錯指令變成 merge
  191. 191. 191 使用情境 ● 本來要用 rebase ,可是卻用錯指令變成 merge ● 本來要合併到分支 A ,可是卻合併到分支 B
  192. 192. 192 使用情境 ● 本來要用 rebase ,可是卻用錯指令變成 merge ● 本來要合併到分支 A ,可是卻合併到分支 B ● 本來已經準備要發佈新版本,並且合併到主線 了。但發現新版本還沒準備好,所以要取消發佈
  193. 193. 193 還沒 push
  194. 194. 194 還沒 push
  195. 195. 195 已經 push
  196. 196. 196 已經 push
  197. 197. 197 合併衝突原因
  198. 198. 198 原因
  199. 199. 199 原因 ● coding style ,如空白、 TAB 、括號、換行 ...... 等
  200. 200. 200 原因 ● coding style ,如空白、 TAB 、括號、換行 ...... 等 – 團隊內部最好制定 coding style ,如: EditorConfig
  201. 201. 201 原因 ● coding style ,如空白、 TAB 、括號、換行 ...... 等 – 團隊內部最好制定 coding style ,如: EditorConfig ● 兩個使用者改到同一個檔案的同一行
  202. 202. 202 原因 ● coding style ,如空白、 TAB 、括號、換行 ...... 等 – 團隊內部最好制定 coding style ,如: EditorConfig ● 兩個使用者改到同一個檔案的同一行 – 模組化
  203. 203. 203 原因 ● coding style ,如空白、 TAB 、括號、換行 ...... 等 – 團隊內部最好制定 coding style ,如: EditorConfig ● 兩個使用者改到同一個檔案的同一行 – 模組化 ● 一個使用者改檔案,另一個使用者卻把檔案刪掉
  204. 204. 204 原因 ● coding style ,如空白、 TAB 、括號、換行 ...... 等 – 團隊內部最好制定 coding style ,如: EditorConfig ● 兩個使用者改到同一個檔案的同一行 – 模組化 ● 一個使用者改檔案,另一個使用者卻把檔案刪掉 – 模組化
  205. 205. 205 與 Redmine 整合
  206. 206. 206 使用方式
  207. 207. 207 使用方式 ● 每個工作都詳實紀錄在 Redmine 上面
  208. 208. 208 使用方式 ● 每個工作都詳實紀錄在 Redmine 上面 ● 開 branch 時依照 issue number 建立,如 feature/145-add-oauth 、 bug/286-login-fail
  209. 209. 209 使用方式 ● 每個工作都詳實紀錄在 Redmine 上面 ● 開 branch 時依照 issue number 建立,如 feature/145-add-oauth 、 bug/286-login-fail ● issue 處理完畢後,合併到其他 branch 建議使用 true merge 方式處理,在線圖上會清楚表現出來
  210. 210. 210 使用方式 ● 每個工作都詳實紀錄在 Redmine 上面 ● 開 branch 時依照 issue number 建立,如 feature/145-add-oauth 、 bug/286-login-fail ● issue 處理完畢後,合併到其他 branch 建議使用 true merge 方式處理,在線圖上會清楚表現出來 ● issue 處理完畢時,可以加上 GitHub 的方式直 接關閉 issue
  211. 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. 212 遇到的問題
  213. 213. 213 遇到的問題 ● 沒有每個工作都記錄在 Redmine 上
  214. 214. 214 遇到的問題 ● 沒有每個工作都記錄在 Redmine 上 ● 不知道開 sub-issue 的時機
  215. 215. 215 遇到的問題 ● 沒有每個工作都記錄在 Redmine 上 ● 不知道開 sub-issue 的時機 ● 沒有按照 name convention 開 branch
  216. 216. 216 遇到的問題 ● 沒有每個工作都記錄在 Redmine 上 ● 不知道開 sub-issue 的時機 ● 沒有按照 name convention 開 branch ● 不知道要使用 merge 還是 rebase
  217. 217. 217 不想所有檔案被控管
  218. 218. 218 使用 .gitignore
  219. 219. 219 使用 .gitignore ● 定義不需要被 git 控管的檔案規則
  220. 220. 220 使用 .gitignore ● 定義不需要被 git 控管的檔案規則 ● 暫存檔、建置完的 binary 檔,一般來說是不需被 git 控管
  221. 221. 221 使用 .gitignore ● 定義不需要被 git 控管的檔案規則 ● 暫存檔、建置完的 binary 檔,一般來說是不需被 git 控管 ● 密碼、 token 等各種敏感資料需依照實際情況決 定,如透過 env 取得
  222. 222. 222 使用 .gitignore ● 定義不需要被 git 控管的檔案規則 ● 暫存檔、建置完的 binary 檔,一般來說是不需被 git 控管 ● 密碼、 token 等各種敏感資料需依照實際情況決 定,如透過 env 取得 – 可多利用 framework 已內建的環境切換功能
  223. 223. 223 使用 .gitignore ● 定義不需要被 git 控管的檔案規則 ● 暫存檔、建置完的 binary 檔,一般來說是不需被 git 控管 ● 密碼、 token 等各種敏感資料需依照實際情況決 定,如透過 env 取得 – 可多利用 framework 已內建的環境切換功能 ● https://www.gitignore.io
  224. 224. 224 使用 .gitignore ● 定義不需要被 git 控管的檔案規則 ● 暫存檔、建置完的 binary 檔,一般來說是不需被 git 控管 ● 密碼、 token 等各種敏感資料需依照實際情況決 定,如透過 env 取得 – 可多利用 framework 已內建的環境切換功能 ● https://www.gitignore.io – 內建數十種語言、 OS 及 framework
  225. 225. 225 遇到的問題
  226. 226. 226 遇到的問題 ● 開發後期才發現有不該被控管的檔案如何處理?
  227. 227. 227 遇到的問題 ● 開發後期才發現有不該被控管的檔案如何處理? – 使用 BFG 或 filter-branch 將資料清除
  228. 228. 228 儲存庫大掃除
  229. 229. 229 使用 BFG 或 filter-branch
  230. 230. 230 使用 BFG 或 filter-branch ● 刪除某些特大檔
  231. 231. 231 使用 BFG 或 filter-branch ● 刪除某些特大檔 – git 對於 binary 檔案不會使用 delta 的方式儲存,而是 直接新增 binary 檔案。所以如果儲存庫過大的話,可 以考慮刪除某些特大檔的歷史,如圖檔
  232. 232. 232 使用 BFG 或 filter-branch ● 刪除某些特大檔 – git 對於 binary 檔案不會使用 delta 的方式儲存,而是 直接新增 binary 檔案。所以如果儲存庫過大的話,可 以考慮刪除某些特大檔的歷史,如圖檔 ● 刪除某些檔案
  233. 233. 233 使用 BFG 或 filter-branch ● 刪除某些特大檔 – git 對於 binary 檔案不會使用 delta 的方式儲存,而是 直接新增 binary 檔案。所以如果儲存庫過大的話,可 以考慮刪除某些特大檔的歷史,如圖檔 ● 刪除某些檔案 – 不小心 commit 進儲存庫的檔案,如暫存檔、建置完 的檔案
  234. 234. 234 使用 BFG 或 filter-branch ● 刪除某些特大檔 – git 對於 binary 檔案不會使用 delta 的方式儲存,而是 直接新增 binary 檔案。所以如果儲存庫過大的話,可 以考慮刪除某些特大檔的歷史,如圖檔 ● 刪除某些檔案 – 不小心 commit 進儲存庫的檔案,如暫存檔、建置完 的檔案 ● 取代字串,如密碼
  235. 235. 235 使用 BFG 或 filter-branch ● 刪除某些特大檔 – git 對於 binary 檔案不會使用 delta 的方式儲存,而是 直接新增 binary 檔案。所以如果儲存庫過大的話,可 以考慮刪除某些特大檔的歷史,如圖檔 ● 刪除某些檔案 – 不小心 commit 進儲存庫的檔案,如暫存檔、建置完 的檔案 ● 取代字串,如密碼 – 敏感資料不想公開出來
  236. 236. 236 遇到的問題
  237. 237. 237 遇到的問題 ● 大掃除後無法 push
  238. 238. 238 遇到的問題 ● 大掃除後無法 push – 必須使用 push -f 的方式,強制更新遠端的儲存庫
  239. 239. 239 遇到的問題 ● 大掃除後無法 push – 必須使用 push -f 的方式,強制更新遠端的儲存庫 – 大掃除前先請所有開發者將本地所有分支都 push 到 遠端儲存庫,執行大掃除後再重新 clone 下來,保持 儲存庫的整潔及完整性
  240. 240. 240 遇到的問題 ● 大掃除後無法 push – 必須使用 push -f 的方式,強制更新遠端的儲存庫 – 大掃除前先請所有開發者將本地所有分支都 push 到 遠端儲存庫,執行大掃除後再重新 clone 下來,保持 儲存庫的整潔及完整性 ● 敏感資料已經外流
  241. 241. 241 遇到的問題 ● 大掃除後無法 push – 必須使用 push -f 的方式,強制更新遠端的儲存庫 – 大掃除前先請所有開發者將本地所有分支都 push 到 遠端儲存庫,執行大掃除後再重新 clone 下來,保持 儲存庫的整潔及完整性 ● 敏感資料已經外流 – 變更密碼、撤銷 api key ,並確認後續使用 env 取得
  242. 242. 242 Git for Teams
  243. 243. 243
  244. 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. 245 References ● 工程團隊如何做專案與程式碼管理 (二) ● 工程團隊如何做專案與程式碼管理 (三)
  246. 246. 246

×