gitflow 工作流定義了乙個圍繞專案發布的嚴格分支模型。雖然比功能分支工作流複雜幾分，但提供了用於乙個健壯的用於管理大型專案的框架。
gitflow 工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配乙個很明確的角色，並定義分支之間如何和什麼時候進行互動。除了使用功能分支，在做準備、維護和記錄發布也使用各自的分支。當然你可以用上功能分支工作流所有的好處：pull requests、隔離實驗性開發和更高效的協作。
為 master 分支配套乙個 develop 分支。簡單來做可以本地建立乙個空的 develop 分支，push 到伺服器上：git branch develop
git push -u origin develop
每個新功能位於乙個自己的分支，這樣可以push到**倉庫以備份和協作。但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當新功能完成時，合併回develop分支。新功能提交應該從不直接與master分支互動。
git checkout -b feature-some developgit status
git add
git commit
git pull
git push
git pull origin develop
git checkout develop
git merge --no-ff feature-some
git push origin develop
git branch -d feature-some
# if you pushed branch to origin:
git push origin --delete feature-some
發布release分支時，合併release到master和develop， 同時在master分支上打個tag記住release版本號，然後可以刪除release分支了。
新的分支來做發布準備，確定了發布的版本號，並建立分支。這個分支是清理發布、執行所有測試、更新文件和其它為下個發布做準備操作的地方，像是乙個專門用於改善發布的功能分支。
git checkout -b release-0.1.0 developgit checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1
對外發布後，處理專案bug。為了處理 bug，從 master 分支上拉出了乙個hotfix分支，提交修改以解決問題，然後直接合併回 master 分支：
git checkout -b hotfix-
#001 master
# fix the bug
git checkout master
git merge hotfix-
#001
git push
git checkout develop
git merge issue-
#001
git push
git branch -d issue-
#00
git flow工作流總結
寫在前面 文章的出處是由於作者本人對於gitlab 以及sourcetree的使用實在是摸不著頭腦，所以決定將各個地方詳細的截圖下來 因為我找的資料裡面對我來說都是不夠用的 由於在學校的時候沒有接觸過git，所以實習有些不適應，就這些天的使用就行相關的總結。現在在實習公司用的gitlab sourc...
Gitflow 工作流簡介
gitflow工作流通過為功能開發 發布準備和專案維護分配獨立的分支，讓發布迭代過程更流暢。gitflow工作流定義了乙個圍繞專案發布的嚴格分支模型，它會相對複雜一點，但提供了用於乙個健壯的用於管理大型專案的框架，非常適合用來管理大型專案的發布和維護。貫穿整個開發周期，master和develop分...
git flow工作流實際專案實踐
公司專案的開發流程主要是這樣 分為 develop分支 master分支 平時我開發的時候，主要在develop分支上改動 一般來講，有以下幾種改動方式 1.直接在develop上修改 這種一般是當前沒有大需求，沒有其他同事一起開發的情況下為了快速完成乙個任務才選擇直接改develop上的 實際上這...