Git flow 與團隊合作

Git Flow 進階操作與團隊合作

Transcript

1. 團隊合作
 Git tips and flow Bo-Yi Wu 2016.04.21 1
2. 關於我 http://blog.wu-boy.com/ https://github.com/appleboy https://www.facebook.com/appleboy46 2
3. ⼤綱 • Git ⼯作流程介紹 • Git 使⽤法則及⼩技巧 3
4. 先來看看團隊開發流程 4
5. 5 1.Develo p 2. Pull Request 3. Code Review 4. Deploy
6. Git flow 早先 Git 開發模式 6
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
10. Git flow 詳細流程可以參考 https://goo.gl/XIThFY 10
11. 有沒有覺得好多 Branch 搞得好複雜 11
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
15. 搞得好複雜 技術主管管理不易 15
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
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
27. 27 Assign Issue Create Branch Fix issue Code Review Testing
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
39. 整理完 commit log 後 請把 master merge 到您的 branch 39
40. Two way to merge master • git merge master • git rebase master 40
41. 41 git log --date-order
42. 42 git log --topo-order
44. 好處是確保你的 commit 
 保持在 Log 最上⾯ 之後追 commit log 會比較好找 44
45. 更新⽬前 branch 到最新 git pull --rebase origin master 45
46. Demo 46
47. Git diff 好⼯具 diff-so-fancy https://github.com/so-fancy/diff-so-fancy 47
49. Git tips 49
50. 救回已經 commit 的程式碼 git reflog 50
52. Any Question? 52