Git工作流概述

集中式工作流

基於master分支開發

流程：

1. 創建origin/master分支
2. 協作開發者A、B把origin/master 分支clone到本地
3. 協作開發者A、B在本地master分支進行開發
4. A開發完push到遠程master分支
5. B開發完push到遠程master分支

衝突處理

push時本地代碼與遠程master有分歧時推不上去，用git pull --rebase origin master把遠程master的代碼與本地代碼進行合併同步，如果merge的過程中存在CONFLICT，解決完conflict再push到master。

重點

1. 每次開發前都從origin/master 分支先pull一下
2. 提交之前也 git pull --rebase

功能分支工作流

功能分支工作流開發工工作在特性分支開發，在最終合併到master之前不會影響master分支的代碼，保證了master分支可以作爲一個穩定的可發佈版本。

流程

1. 確定開發的功能後以master爲基礎創建一個功能分支 例如 dev git checkout -b dev master
2. 在特性分支上進行開發，開發之後push到中央倉庫的功能分支，其他人也可以提交到該功能分支
3. 該功能分支開發完成之後，提交一個pull request請求合併到master，項目成員進行討論
4. pull request合併後該分支刪除

   git checkout master
   git pull
   git pull origin dev
   git push
   

重點

1. 功能分支與master主分支在同一個中央倉庫
2. pull request進行code review
3. 互不影響，多個功能同時開發
4. 合併分支的時候，加上 no-ff 參數

Git flow 工作流

Gitflow 工作流，擴展了集中式工作流與功能分支工作流。包含 開發分支devleop，特性分支 feature-xx，發行分支release-xx，維護分支 master，修復分支 hotfix

流程

1. 項目創建的時候同時創建master和develop分支
2. 項目成員clone把項目到本地
3. 開發feature的時候以develop進行checkout
   git checkout -b develop origin/develop
4. feature 開發完後發起 pull request合併到到develop
5. 版本開發完成後準備發行，以develop創建一個release-xx發行分支
6. release發行完成，把release-xx合併到維護分支master，並打上tag標籤
7. 發行後修改bug，以master分支checkout一個hotfix-xx分支，修改後合併到master分支，同時要合併到develop分支。

重點

1. 各分支的意義
   • feature (多個) 主要是自己玩了，差不多的時候要合併回 develop 去。不與 master 交互。
   • develop (同時間一個) 主要是和 feature 以及 release 交互
   • release (同時間一個) 總是基於 develop，最後又合併回 develop。當然對應的 tag 要合併到 master 分支，生命週期短，僅是爲了發佈程序
   • hotfix (同一時間一個) 總是基於 master，並最後合併到 master 和 develop。生命同期較短，用來修復 bug 或小粒度修改發佈
   • master (僅一個) 關聯 tag 和發佈
2. 特性分支都是基於開發分支develop
3. 發行分支創建好之後，要修改部分內容要往release分支合併
4. 發行後的維護需要從master 進行checkout

Forking 工作流

把中央倉庫fork到自己的代碼倉庫，在自己的代碼倉庫開發，完了之後提交pull request 合併到中央倉庫的主分支

流程

1. fork
2. git remote add
3. pull request

重點

1. Forking工作流的一個主要優勢是，貢獻的代碼可以被集成，而不需要所有人都能push代碼到僅有的中央倉庫中。
   開發者push到自己的服務端倉庫，而只有項目維護者才能push到正式倉庫。

GitHub Flow

GitHub Flow 推薦做法是隻有一個主分支 master，團隊成員們的分支代碼通過 pull Request 來合併到 master 上

GitHub Flow 模型簡單說明

1. 只有一個長期分支 master ,而且 master 分支上的代碼，永遠是可發佈狀態,一般 master 會設置 protected 分支保護，只有有權限的人才能推送代碼到 master 分支。
2. 如果有新功能開發，可以從 master 分支上檢出新分支。
3. 在本地分支提交代碼，並且保證按時向遠程倉庫推送。
4. 當你需要反饋或者幫助，或者你想合併分支時，可以發起一個 pull request。
5. 當 review 或者討論通過後，代碼會合併到目標分支。
6. 一旦合併到 master 分支，應該立即發佈。

特色之 Pull Request

GitHub Flow 最大的特色就是 Pull Request 的提出，這是一個偉大的發明，它的用處並不僅僅是合併分支，還有以下功能：

1. 可以很好控制分支合併權限。

2. 分支不是你想合併就合併，需要對方同意吶

3. 問題討論 或者 尋求其他小夥伴們的幫助。
   和拉個討論組差不多，可以選擇相關的人蔘與，而且參與的人還可以向你的分支提交代碼，可以說，是非常適合代碼交流了。

4. 代碼 Review 。
   如果代碼寫的很爛，有了 pull request 提供的評論功能支持，準備好接受來自 review 的實時吐槽吧。當然你如果寫的很棒，肯定也能被雙擊666的。

特色之 issue tracking 問題追蹤

日常開發中，會用到很多第三方庫，然後使用過程中，出現了問題，是不是第一個反應是去這個第三方庫的 GitHub 倉庫去搜索一下 issue ，看沒有人遇到過，項目維護者修復了沒有，一般未解決的 issue 是 open 狀態，已解決的會被標記爲 closed。這就是 issue tracking。

如果你是一個項目維護者，除了標記 issue 的開啓和關閉，還可以給它標記上不同的標籤，來優化項目。當提交的時候，如果提交信息中有 fix #1 等字段，可以自動關閉對應編號的 issue。

Gitlab flow

集百家之長，推薦使用

團隊配合

一個版本劃分爲主線和輔線，A負責主線開發，B負責輔線和線上bug修復，下個版本互換，A負責輔線和線上bug修復,B負責主線開發

推薦相關資料

• Git工作流——集中式工作流
• Git手冊
• infoQ別再推薦 Git Flow 了
• Git三大特色之WorkFlow(工作流)