利用git 進行多人協做開發

如今，大部分項目都是用 git 來管理代碼的，但當項目變大、多人協做時，git 的使用就變得複雜了，這時就須要在 git 使用的流程上來思考如何更優的使用 git。

對於大部分 web 項目而言，並不像軟件、APP 項目同樣有版本的劃分，而是不斷的更新、迭代，這就使得 web 項目的 git 使用要複雜一些，須要管理好哪些是正在開發的代碼、哪些是提交測試的代碼、哪些是已經上線的代碼、多人共同開發時如何避免代碼衝突與線上新代碼被舊代碼覆蓋等等。

1. 一個分支

若是項目比較小，不頻繁更新時，能夠只用 master 一個分支。

使用流程：

1. 提交代碼到本地 master 分支，並推送到遠程 master 分支
2. 持續集成構建或本地構建，而後上傳到服務器

上傳到服務器有兩種方式：

1. 持續集成構建，而後同步到服務器
2. 本地構建，而後上傳到服務器（爲了簡潔清晰，後面的圖例中會隱藏這種方式）

2. 開發分支與我的分支

若是項目稍大些，頻繁更新時，就須要另一個開發分支：

• master：主分支，對應線上代碼
• dev：開發分支，對應開發代碼

使用流程：

1. 提交代碼到本地 dev 分支
2. 在須要構建項目時 merge 到本地 master 分支，並推送到遠程 master 分支
3. 持續集成構建，而後同步到服務器

若是是多人蔘與的項目，就須要我的開發分支了：

• master：主分支，對應線上代碼
• man1：我的 man1 開發分支
• man2：我的 man2 開發分支

使用流程：

1. 提交代碼到本地 man1 分支（以 man1 我的爲例）
2. 在須要構建項目時 merge 到本地 master 分支，並推送到遠程 master 分支（有可能須要先 pull 遠程的代碼）
3. 持續集成構建，而後同步到服務器

在適當的時候，每個我的分支（如 man1, man2）都須要 pull 一下 master 分支，以保證本身本地的代碼的版本不會低於服務器。

3. 多個服務器環境

若是項目比較大，而且對應多個服務器環境（測試環境、產品環境）：

• master：主分支
• prod：產品分支，對應產品服務器環境
• test：測試分支，對應測試服務器環境
• dev：開發分支

使用流程：

構建測試環境：

1. 提交代碼到本地 dev 分支
2. 在須要構建項目時 merge 到本地 test 分支，並推送到遠程 test 分支
3. 持續集成構建，而後同步到測試服務器

構建產品環境能夠由遠程的 test 分支 merge 到遠程 prod 分支進行持續集成構建，也可由本地 dev 或 test 分支 merge 到本地 prod 分支，並推送到遠程 prod 分支進行持續集成構建。

若是是多人蔘與的項目，就須要我的開發分支了：

• master：主分支
• prod：產品分支，對應產品服務器環境
• test：測試分支，對應測試服務器環境
• man1：我的 man1 開發分支
• man2：我的 man2 開發分支

使用流程：

構建測試環境：

1. 提交代碼到本地 man1 分支（以 man1 我的爲例）
2. 在須要構建項目時 merge 到本地 test 分支，並推送到遠程 test 分支（有可能須要先 pull 遠程的代碼）
3. 持續集成構建，而後同步到測試服務器

構建產品環境能夠由遠程的 test 分支 merge 到遠程 prod 分支進行持續集成構建，也可由本地 man1 或 test 分支 merge 到本地 prod 分支，並推送到遠程 prod 分支進行持續集成構建。

在適當的時候，每個我的分支（如 man1, man2）都須要 pull 一下 prod 分支（若有須要，也能夠 pull test 分支），以保證本身本地的代碼的版本不會低於服務器。

4. 多個需求同時開發

有時候會有多個需求同時開發，而且相互獨立，爲了避免影響每一個需求的測試與上線，須要爲每一個需求建立一個分支。

• master：主分支
• prod：產品分支，對應產品服務器環境
• test：測試分支，對應測試服務器環境
• man1：我的 man1 開發分支
• man2：我的 man2 開發分支
• task1：需求 task1 開發分支
• task2：需求 task2 開發分支

使用流程：

構建測試環境與以前的步驟一致，但構建產品環境時，爲了保證各個需求不相互影響，通常由本地直接合併到 prod 分支：

1. 本地 task1 分支 merge 到本地 prod 分支，並推送到遠程 prod 分支進行持續集成構建
2. 每個我的分支（如 man1, man2）都須要 pull 一下 prod 分支，以保證本身本地的代碼的版本不會低於服務器
3. 最後刪除 task1 分支

5. 多人協做開發修改公共文件

由於不一樣分支修改同一個文件而致使的文件衝突是多人協做開發中比較常見的問題之一，避免這種問題的思路主要有如下的幾種：

1. 在代碼層面，儘可能避免多個成員都會改動的文件，儘可能將代碼分解到每一個人只負責本身的那塊代碼，不須要去改別人的代碼
2. 在工程層面，儘可能減小公共文件，儘可能每一個文件只由一我的負責
3. 在 git 層面，若是有必要，能夠單獨建一個分支，用於更新某些公共文件，並及時的更新到其餘分支

6. 其餘分支

有一些經常使用的分支，可能咱們會用到：

• bug 分支：用於緊急修復產品環境的 bug

7. 根據狀況調整、簡化流程

上面的圖例只有測試服務器和產品服務器，更多服務器類型的工做流程是相似的；圖例也只有 man1 和 man2 兩個我的分支，更多我的分支的工做流程也是相似的。

上面的圖例主要用於如下特色的項目（須要把整個項目打包成一個總體）：

• 單頁面 web 前端應用，整個項目只有一個 html 文件，頁面之間的切換由本地路由控制，每次更新到服務器都須要打包全部頁面
• Java、Go 等後端應用，每次都須要打包成一個總體，多是一個文件，或者一批文件（不打包成一個總體的方式除外，好比分散 java class 文件）
• 使用持續集成構建的方式更新代碼到服務器

這樣作主要是爲了不一些問題：

• 線上新代碼被舊代碼覆蓋：多人同時開發項目，都須要更新到測試機，若是不是統一 push 到 test 分支作持續集成構建，很難保證線上新代碼不會被舊代碼覆蓋
• 未測試的代碼被更新到產品環境：這個問題也須要注意，由於這個問題並不能從流程上徹底杜絕，須要各位在開發中留意

對於像下面這種特色的項目，能夠根據狀況調整、簡化流程：

• 多頁面 web 前端應用，把某一個頁面更新到服務器並不影響其餘頁面
• NodeJs、PHP、Python 等後端應用，只上傳本身更新的文件，而不影響服務器上其餘文件（把全部代碼打包成一個總體的方式除外）
• 使用本地構建的方式更新代碼到服務器

好比：

• master：主分支
• man1：我的 man1 開發分支
• man2：我的 man2 開發分支
• task1：需求 task1 開發分支
• task2：需求 task2 開發分支

使用流程：

若是多個需求沒有衝突，能夠同時在 man1 我的分支上開發，並根據須要上傳到不一樣的服務器。

若是多個需求有衝突，能夠每一個需求都新建一個分支，如上圖所示：

1. 提交代碼到本地 task1 分支（以 task1 我的爲例）
2. 根據須要上傳到不一樣的服務器
3. 若是代碼經過產品環境後，更新到每一個我的分支，並刪除 task1 分支