Upgrade to Pro — share decks privately, control downloads, hide ads and more …

git, let it flow!

2df110b2f72dd43622abfb80584bd7ec?s=47 cjies
December 27, 2016

git, let it flow!

如何讓多人協作更加輕鬆,版控更加明確。Git flow here you are! 😉

F2E&RGBA 設計 Meetup 十二月號

2df110b2f72dd43622abfb80584bd7ec?s=128

cjies

December 27, 2016
Tweet

More Decks by cjies

Other Decks in Programming

Transcript

  1. $ git let it flow! CJ 2016/12/27
 F2E&RGBA 設計 Meetup

    ⼗十⼆二⽉月號
  2. CJies Tan front end n00b @ iCHEF cjies.com

  3. what is git?

  4. ⛰ git ⼀一開始是為了了 更更好地管理理 Linux 核⼼心⽽而開發的 Linux

  5. 連猴⼦子都能懂的Git⼊入⾨門指南 https://backlogtool.com/git-guide/tw/

  6. dropbox git 檢查點 ⼿手動 / ⾃自動上傳 commit 修改記錄錄 檔案為單位 ⼀一⾏行行為單位

    內容差異異 別想了了 diff 版本控制 集中式 (dropbox 掛了了就真 GG) 分散式 (每⼀一個⼈人都有完整備份)
  7. gitlab bitbucket github git server(s)

  8. Q&A? 喘氣⼀一下...

  9. 團隊開發⼀一般會遇到的問題

  10. 各⾃自寫各的,不不知道怎麼整合? 不不⼩小⼼心覆蓋了了別⼈人的東⻄西 豬隊友上傳有問題的程式,就下班了了... 無法確認誰的才是最終版本 ⼤大家被搞得⼀一團亂 GG

  11. None
  12. git flow 其實這才是今天的主題...

  13. a successful git branching model to versioning your source code.

    - Vincent Driessen, 2010 http://nvie.com/posts/a-successful-git-branching-model/
  14. commit 點 branch 線 merge ⾯面

  15. single branching master

  16. develop hotfix release feature feature master v1.0 v1.1 v1.2

  17. master & develop develop master • 永遠在 production-ready 狀狀態 •

    開發⽤用主線,永遠是最新的狀狀態
  18. feature branch • 從 develop 分⽀支出來來開發新功能 • 完成後合併回 develop •

    可多個 features 並⾏行行 • ⽤用完即棄 feature 1 develop feature 2
  19. release branch • develop 發佈到 master 的記錄錄 • 過程中只修 bugs

    • 完成後合併進 master & develop • ⽤用版號命名 release develop master
  20. hotfix branch • 對 master 做緊急修正 • 過程中⼀一樣只修 bugs •

    完成後合併進 master & develop • ⽤用完即棄 hotfix master develop
  21. pros of git flow

  22. 更更加了了解專案整體、各⽀支線的發展狀狀況 ⾃自⼰己的⽀支線⾃自⼰己開,分⼯工更更加明確 可以更更加容易易抓到戰犯 bug pick what you want

  23. Q&A? 繼續喘氣⼀一下...

  24. question 1: 我需要 git flow 嗎? (真的有幫到我?)

  25. git flow 好像很複雜耶... @@ (有更更簡單的嗎?) question 2:

  26. how to use git flow? https://speakerdeck.com/cjies/git-flow?slide=16 http://danielkummer.github.io/git-flow-cheatsheet/ question 3:

  27. pull requests 除了了 git flow 既定流程外,還有⼀一個更更重要的...

  28. what is pull requests? feature develop 利利⽤用 pull requests 確認是否能進⾏行行

    merge ?
  29. • 描述做了了什什麼事情及⽬目的 • 進⾏行行討論 & code reviews • 清楚知道哪個部分有被更更動 •

    留留下記錄錄,⽅方便便之後重新翻閱 (merge requests in gitlab)
  30. pull requests @ iCHEF • 固定 PULL_REQUEST_TEMPLATE • 進⾏行行 code

    reviews • linter & test pass • 如有界⾯面更更動需提供截圖 • 不不能擺著超過⼀一個禮拜
  31. ⾄至少獲得2個 approve pull requests @ iCHEF

  32. summary • git flow 只是⼀一種 branching strategy • 團隊合作更更有效率,分⼯工更更加明確 •

    規則是死的 ⼈人是活的,尋找團隊適合的 workflow • 溝通最重要...
  33. references • http://nvie.com/posts/a-successful-git-branching-model • https://ihower.tw/blog/archives/5140 • https://yangsu.github.io/pull-request-tutorial • https://about.gitlab.com/2014/09/29/gitlab-flow

  34. $ exit thanks for your listening