Git Flow來(lái)源
Git 作為一個(gè)代碼管理系統(tǒng)洛搀，難免會(huì)涉及到多人合作的情景待锈。
在使用Git的過(guò)程中如果沒(méi)有清晰流程和規(guī)劃宅荤，每個(gè)人都提交一堆雜亂無(wú)章的commit，項(xiàng)目很快就會(huì)變得難以協(xié)調(diào)和維護(hù)诡渴。
所以對(duì)于Git版本管理同樣需要一個(gè)清晰的流程和規(guī)范捐晶。
Vincent Driessen在2010年的時(shí)候發(fā)布了一篇文章 A Successful Git Branching Model
（一個(gè)成功的Git分支模型），該文章被很多人所認(rèn)同妄辩，逐漸的就成為一種標(biāo)準(zhǔn)租悄，今天來(lái)簡(jiǎn)單介紹一下Git Flow。
Git Flow流程圖
Git Flow流程圖.png
這是Git Flow的流程圖恩袱，該流程圖上有2條持久主線：master、develop和三條非持久線feature branches胶哲、release branches畔塔、hotfixes
分支介紹
主分支
-
master
- 只能用于存放所有的發(fā)布
- 每次有了新的commit之后，立即打一個(gè)tag來(lái)記錄
-
develop
- 用于存放不穩(wěn)定版本的發(fā)布
- develop并不是直接用于開發(fā)feature的鸯屿，開發(fā)feature需要專門的branch
- develop在第一時(shí)間從master上分離出來(lái)
- 需要開發(fā)任何功能的時(shí)候澈吨，從develop創(chuàng)建出新的feature branch，開發(fā)完成后合并回develop（合并的時(shí)候使用 --no-ff）寄摆，然后刪掉feature branch
- 當(dāng)下一個(gè)正式版本需要的所有功能開發(fā)完成之后谅辣，從develop上面創(chuàng)建新的release branch，并在release branch 合并到master后（合并的時(shí)候使用 --no-ff）合并回develop（合并的時(shí)候使用 --no-ff）婶恼，然后刪掉release branch
輔助分支
-
feature branches
- 每次開發(fā)新功能是從develop創(chuàng)建
- 開發(fā)完成后合并到develop（合并的時(shí)候使用 --no-ff）桑阶，然后被刪掉
- feature分支常用命名feature-name或者feature/name
-
release branches
- 每次下一個(gè)版本的功能開發(fā)完畢后，從develop上創(chuàng)建
- 創(chuàng)建完成后勾邦，更新版本號(hào)蚣录，然后單獨(dú)做一個(gè)新的commit
- 如果有bug修復(fù)，直接在release branch上創(chuàng)建
- bugx修復(fù)完成后眷篇，合并到master和develop上（合并的時(shí)候使用 --no-ff）萎河，然后被刪掉
- release分支常用命名release-name或者release/name
-
hotfix branches
- 已正式發(fā)布的產(chǎn)品發(fā)現(xiàn)bug，直接從master或者出問(wèn)題的tag上創(chuàng)建hotfix branch，進(jìn)行緊急修復(fù)虐杯，修復(fù)完成后合并到master和develop和release branch（如果有的話）（合并的時(shí)候使用 --no-ff）玛歌，然后被刪掉
- hotfix分支常用命名hotfix-name或者hotfix/name
使用到的Git命令
git log //查看日志
git log --graph //圖形化log顯示
git branch name //創(chuàng)建名為name的分支
git checkout -b name //創(chuàng)建名為name的分支并切換到改分支
git merge name --no-ff//將名為name的分支合并到當(dāng)前所在的分支，--no-ff：不使用fast-forward方式合并擎椰，保留分支的commit歷史
git branch -d name //刪除名為name的分支
git tag name //在當(dāng)前分支上打一個(gè)名為name(如v1.0)的tag
