Git flow 與團隊合作
Download as PPTX, PDF42 likes11,261 views
该文档讨论了团队合作中的Git工作流程，包括Git Flow和GitHub Flow的优缺点。Git Flow适用于复杂项目，但对开发者造成理解负担；而GitHub Flow简化了流程，使得版本管理更容易。文中还提供了Git使用法则和一些最佳实践，以提升团队开发效率。
Git flow 與團隊合作
- 1. 團隊合作 Git tips and flow Bo-Yi Wu 2016.04.21 1
- 3. 大綱 • Git 工作流程介紹 • Git 使用法則及小技巧 3
- 4. 先來看看團隊開發流程 4
- 6. Git flow 早先 Git 開發模式 6
- 7. 7
- 8. Main Branch • Develop – 最新的開發分支 • Master – Production 專屬分支 8
- 9. Support branch • Feature – 開發新功能，從 develop 分支出來，完成後 merge 回 develop • Release – 準備 release 版本，從 develop 分支出來，只修 bugs， 完成後 merge 回 develop 和 master • Hotfix – 重大 bugs 修復，從 master 分支出來，完成後 Merge 回 develop 和 master 9
- 12. Create branch • Master • Develop • Feature Merge Branch • Master • Develop Code Conflict • Master • Develop 該從哪邊拉 branch 要 merge 回哪個 branch 要解決多次相同 Conflict 12
- 13. 對團隊來說 • 開發者不易瞭解整個 Git flow • 開發者不知道從哪個 Branch 繼續開發 • 開發完成後該 merge 回 master 或 develop? • 需要解決多次衝突 (Merge 回多個分支) 13
- 14. PM: 那個新功能沒上 Production RD: 抱歉忘記 Merge 回 Master (回去檢查看看是不是忘記 Merge?) 14
- 16. Github Flow 16
- 17. 只有一個 Branch 叫 Master 不需要知道其他 Branch 作用 因為最終都會合併到 Master 分支 17
- 18. Github 流程 • 開發都從 master branch 開分支 • 隨時都可以發 Pull Request • Review 過的 Pull Request 才可以 Merge • 隨時都可以發佈新版本 18
- 19. Github Flow 優勢 • 只需要維護 Master 分支 – 禁止任何開發者使用 git push origin master –f – 請將 master 設定無法使用 –f 覆蓋 • 開發者容易理解及學習 • 管理者方便 Code Review 及發佈新版 – 不用再擔心少 Merge branch – 不用再擔心開發人員玩壞 branch 19
- 20. 20
- 21. 21 1.Develop 2. Pull Request 3. Code Review 4. Deploy Github Flow 快速上版
- 22. 該如何制訂 Production 編號 請善用 git tag 來 release production 22
- 23. 上 Hotfix 版本 Tag 上 production • git checkout –b hotfix 1.0.0 • git commit –a –m ‘xxxx’ • git tag –a 1.0.1 –m ‘1.0.1’ • git checkout master • git cherry-pick commit-id Master 上 production • git commit –a –m ‘xxxx’ • git tag –a 1.0.1 –m ‘1.0.1’ 23
- 24. 24 Tag 1.0.0 Patch-1 Tag 1.0.1 Patch-1 Commit C Commit A Commit B Tag 上 production git cherry-pick patch-1
- 25. 團隊 Git 使用法則 25
- 26. Git commit • 標題不要過長 (請勿超過 50 字元) • 標題請務必連結上 Issue Track System – jira, github, redmine… 等 • 內容請補上 What, Why and How – 或者是在 Issue Track 上描述清楚 • 不要紀錄無關緊要的 commit – 像是 fix typo, update readme … 等 26
- 28. 為什麼要 Code Review • 降低 Production 出包機率 • 可以學習 coder 為什麼要這樣寫 • 可以學習 reviewer 會怎麼建議 • 團隊素質水準提高 28
- 29. 29 Fix Issue Code Review Fix Issue Code Review Fix issue git commit –a –m ‘fix typo’ git commit –a –m ‘update readme’ git commit –a –m ‘fix typo’
- 30. Git log • git commit –a –m ‘fix typo 1’ • git commit –a –m ‘fix typo 2’ • git commit –a –m ‘fix typo 3’ • git commit –a –m ‘fix typo 4’ • git commit –a –m ‘fix typo 5’ • git commit –a –m ‘fix typo 6’ 30
- 31. 31 https://github.com/h5bp/Front-end-Developer-Interview- Questions/pull/241/commits
- 32. Merge 到 Master 分支前 請務必 squash your commit. 32
- 33. Two way to squash your commit • Git reset (一般用法) • Git rebase (進階用法) 33
- 34. git reset • git reset --soft HEAD^ – 合併多個 commit – 修改上一個 commit message • git reset --hard HEAD^ (小心使用) – 回復到上一個 commit 狀態 – 這次修改，但是尚未 commit 的更動會消失 34
- 35. Demo 35
- 36. git rebase –i commitID -i 互動模式 36
- 37. 37
- 38. 38
- 39. 整理完 commit log 後 請把 master merge 到您的 branch 39
- 40. Two way to merge master • git merge master • git rebase master 40
- 43. 43
- 44. 好處是確保你的 commit 保持在 Log 最上面 之後追 commit log 會比較好找 44
- 45. 更新目前 branch 到最新 git pull --rebase origin master 45
- 46. Demo 46
- 48. 48
- 49. Git tips 49
- 50. 救回已經 commit 的程式碼 git reflog 50
- 51. 51
- 52. Any Question? 52