基於master分支開發流程：
建立origin/master分支
協作開發者a、b把origin/master 分支clone到本地
協作開發者a、b在本地master分支進行開發
a開發完push到遠端master分支
b開發完push到遠端master分支
衝突處理
push時本地**與遠端master有分歧時推不上去，用git pull --rebase origin master把遠端master的**與本地**進行合併同步，如果merge的過程中存在conflict，解決完conflict再push到master。
重點每次開發前都從origin/master 分支先pull一下
提交之前也 git pull --rebase
功能分支工作流開發工工作在特性分支開發，在最終合併到master之前不會影響master分支的**，保證了master分支可以作為乙個穩定的可發布版本。流程
確定開發的功能後以master為基礎建立乙個功能分支 例如 devgit checkout -b dev master在特性分支上進行開發，開發之後push到**倉庫的功能分支，其他人也可以提交到該功能分支
該功能分支開發完成之後，提交乙個pull request請求合併到master，專案成員進行討論
pull request合併後該分支刪除
git checkout master
git pull
git pull origin dev
git push
功能分支與master主分支在同乙個**倉庫
pull request進行code review
互不影響，多個功能同時開發
合併分支的時候，加上 no-ff 引數
gitflow 工作流，擴充套件了集中式工作流與功能分支工作流。包含 開發分支devleop，特性分支 feature-xx，發行分支release-xx，維護分支 master，修復分支 hotfix流程
專案建立的時候同時建立master和develop分支
專案成員clone把專案到本地
開發feature的時候以develop進行checkout
git checkout -b develop origin/developfeature 開發完後發起 pull request合併到到develop
版本開發完成後準備發行，以develop建立乙個release-xx發行分支
release發行完成，把release-xx合併到維護分支master，並打上tag標籤
發行後修改bug，以master分支checkout乙個hotfix-xx分支，修改後合併到master分支，同時要合併到develop分支。 重點
各分支的意義
特性分支都是基於開發分支develop
發行分支建立好之後，要修改部分內容要往release分支合併
發行後的維護需要從master 進行checkout
把**倉庫fork到自己的**倉庫，在自己的**倉庫開發，完了之後提交pull request 合併到**倉庫的主分支流程
fork
git remote add
pull request 重點
forking工作流的乙個主要優勢是，貢獻的**可以被整合，而不需要所有人都能push**到僅有的**倉庫中。
開發者push到自己的服務端倉庫，而只有專案維護者才能push到正式倉庫。
github flow 推薦做法是只有乙個主分支 master，團隊成員們的分支**通過 pull request 來合併到 master 上github flow 模型簡單說明
只有乙個長期分支 master ,而且 master 分支上的**，永遠是可發布狀態,一般 master 會設定 protected 分支保護，只有有許可權的人才能推送**到 master 分支。
如果有新功能開發，可以從 master 分支上檢出新分支。
在本地分支提交**，並且保證按時向遠端倉庫推送。
當你需要反饋或者幫助，或者你想合併分支時，可以發起乙個 pull request。
當 review 或者討論通過後，**會合併到目標分支。
一旦合併到 master 分支，應該立即發布。
特色之 pull request
github flow 最大的特色就是 pull request 的提出，這是乙個偉大的發明，它的用處並不僅僅是合併分支，還有以下功能：
可以很好控制分支合併許可權。
分支不是你想合併就合併，需要對方同意吶
問題討論 或者 尋求其他小夥伴們的幫助。
和拉個討論組差不多，可以選擇相關的人參與，而且參與的人還可以向你的分支提交**，可以說，是非常適合**交流了。
特色之 issue tracking 問題追蹤
日常開發中，會用到很多第三方庫，然後使用過程中，出現了問題，是不是第乙個反應是去這個第三方庫的 github 倉庫去搜尋一下 issue ，看沒有人遇到過，專案維護者修復了沒有，一般未解決的 issue 是 open 狀態，已解決的會被標記為 closed。這就是 issue tracking。
如果你是乙個專案維護者，除了標記 issue 的開啟和關閉，還可以給它標記上不同的標籤，來優化專案。當提交的時候，如果提交資訊中有 fix #1 等字段，可以自動關閉對應編號的 issue。
集百家之長，推薦使用乙個版本劃分為主線和輔線，a負責主線開發，b負責輔線和線上bug修復，下個版本互換，a負責輔線和線上bug修復,b負責主線開發
工作流概述
工作流 workflow 是對工作流程及其各操作步驟之間業務規則的抽象 概括 描述。工作流建模，即將工作流程中的工作如何前後組織在一起的邏輯和規則在計算機中以恰當的模型進行表示並對其實施計算。工作流要解決的主要問題是 為實現某個業務目標，在多個參與者之間，利用計算機，按某種預定規則自動傳遞文件 資訊...
工作流概述
工作流程圖是通過適當的符號記錄全部工作事項，用以描述工作活動流向順序。它是用圖的形式反映乙個組織系統中各項工作之間的邏輯關係,用以描述工作流程之間的聯絡與統一的關係.工作流程圖由乙個開始點 乙個結束點及若干中間環節組成，中間環節的每個分支也都要求有明確的分支判斷條件。所以工作流程圖對於工作標準化有著...
Activiti工作流概述
一 概述 工作流 workflow 就是 業務過程的部分或整體在計算機應用環境下的自動化 它主要解決的是 使在多個參與者之間按照某種預定義的規則傳遞文件 資訊或任務的過程自動進行，從而實現某個預期的業務目標，或者促使此目標的實現 工作流管理系統 workflow management system,...