Slide 1

Slide 1 text

$ git let it flow! CJ 2016/12/27
 F2E&RGBA 設計 Meetup ⼗十⼆二⽉月號

Slide 2

Slide 2 text

CJies Tan front end n00b @ iCHEF cjies.com

Slide 3

Slide 3 text

what is git?

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

dropbox git 檢查點 ⼿手動 / ⾃自動上傳 commit 修改記錄錄 檔案為單位 ⼀一⾏行行為單位 內容差異異 別想了了 diff 版本控制 集中式 (dropbox 掛了了就真 GG) 分散式 (每⼀一個⼈人都有完整備份)

Slide 7

Slide 7 text

gitlab bitbucket github git server(s)

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

a successful git branching model to versioning your source code. - Vincent Driessen, 2010 http://nvie.com/posts/a-successful-git-branching-model/

Slide 14

Slide 14 text

commit 點 branch 線 merge ⾯面

Slide 15

Slide 15 text

single branching master

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

master & develop develop master • 永遠在 production-ready 狀狀態 • 開發⽤用主線,永遠是最新的狀狀態

Slide 18

Slide 18 text

feature branch • 從 develop 分⽀支出來來開發新功能 • 完成後合併回 develop • 可多個 features 並⾏行行 • ⽤用完即棄 feature 1 develop feature 2

Slide 19

Slide 19 text

release branch • develop 發佈到 master 的記錄錄 • 過程中只修 bugs • 完成後合併進 master & develop • ⽤用版號命名 release develop master

Slide 20

Slide 20 text

hotfix branch • 對 master 做緊急修正 • 過程中⼀一樣只修 bugs • 完成後合併進 master & develop • ⽤用完即棄 hotfix master develop

Slide 21

Slide 21 text

pros of git flow

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

• 描述做了了什什麼事情及⽬目的 • 進⾏行行討論 & code reviews • 清楚知道哪個部分有被更更動 • 留留下記錄錄,⽅方便便之後重新翻閱 (merge requests in gitlab)

Slide 30

Slide 30 text

pull requests @ iCHEF • 固定 PULL_REQUEST_TEMPLATE • 進⾏行行 code reviews • linter & test pass • 如有界⾯面更更動需提供截圖 • 不不能擺著超過⼀一個禮拜

Slide 31

Slide 31 text

⾄至少獲得2個 approve pull requests @ iCHEF

Slide 32

Slide 32 text

summary • git flow 只是⼀一種 branching strategy • 團隊合作更更有效率,分⼯工更更加明確 • 規則是死的 ⼈人是活的,尋找團隊適合的 workflow • 溝通最重要...

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

$ exit thanks for your listening