git工作流程的記錄整理
git flow 普片認為最早是由荷蘭獨立軟體工程師 Vincent Driessen 在2010年發表的 一個成功的Git分支模型(A successful Git branching model) 這篇文章提出的。文章中提到文森特早在一些專案中使用git flow，並證明它是成功的。文中提及使用git flow的根據分支策略解決自動構建和部署問題。文森特後來製作了 nvie/gitflow 工具用於擴充套件git實現git flow功能，gitflow思想也推廣了出去。
倉庫在一般的情況下存在 master 和 develop 兩個主要分支。
master develop
根據專案的需要可能新增下面這些分支：
hotfix feature release
每個分支都有其職責，為團隊中的開發人員緩解功能跟蹤、預構建及快速修復等問題。在一些場景下gitflow會顯得很臃腫，在一些快速迭代的產品中會使你必須在 master , develop , release 三條分支中頻頻切換來完成合並維護，寫將會花費你大量的時間和精力。
對於giflow的過於繁瑣和複雜， Scott Chacon 提出gitflow的問題和 github-flow 的思想。
什麼是github-flow呢？
- 首先master分支中的任何內容都是可部署的
- 建立一個來自master的具有描述性的分支（如：new-oauth2-scopes）
- 在本地提交該分支，並定期將您的工作推送到伺服器上的同名分支
- 當您需要反饋或幫助時，或者您認為分支已準備好進行合併時，請開啟拉取請求（PR）
- 在其他人審閱並簽署該功能後，您可以將其合併到master中
- 一旦合併並推送到“master”，您就可以並且應該立即部署
在 github 有完整的指引
新分支只專注單個功能進行開發，使開發者更專注於編碼而已不是管理這些狀態。github-flow中增加了合併請求(PR)和檢查程式碼(review)部分更是為專案提供了很好的保護，在這步能很好的控制編碼風格和編碼錯誤等問題，檢查和稽核他人的程式碼不但讓組內成員相互學習提高專案參與感。同時也為團隊降低了人員流失所帶來的風險。合併前的部署環節為分支程式碼提前在生產環境測試，這將會是上線前的最終測試，通過測試後將合併至主分支釋出上線。
能看出github-flow比gitflow少了預釋出、修復、增加功能、開發的分支，工作流程簡單了許多。但是預釋出、修復、增加功能、開發等概念在整個軟體開發過程中任然是存在的，其他環節無需在編碼環節上體現出來。github-flow只專注編碼，其作為在軟體開發的編碼階段是具有非常高的參考價值。