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

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

1. 一個分支

如果項目比較小，不頻繁更新時，可以只用?master?一個分支。

使用流程：

提交代碼到本地?master?分支，并推送到遠程?master?分支

持續集成構建或本地構建，然后上傳到服務器

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

持續集成構建，然后同步到服務器

本地構建，然后上傳到服務器（為了簡潔清晰，后面的圖例中會隱藏這種方式）

2. 開發分支與個人分支

如果項目稍大些，頻繁更新時，就需要另外一個開發分支：

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

使用流程：

提交代碼到本地?dev?分支

在需要構建項目時?merge?到本地?master?分支，并推送到遠程?master?分支

持續集成構建，然后同步到服務器

如果是多人參與的項目，就需要個人開發分支了：

• master：主分支，對應線上代碼
• man1：個人?man1?開發分支
• man2：個人?man2?開發分支

使用流程：

提交代碼到本地?man1?分支（以?man1?個人為例）

在需要構建項目時?merge?到本地?master?分支，并推送到遠程?master?分支（有可能需要先?pull?遠程的代碼）

持續集成構建，然后同步到服務器

在適當的時候，每一個個人分支（如?man1, man2）都需要?pull?一下?master?分支，以保證自己本地的代碼的版本不會低于服務器。

3. 多個服務器環境

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

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

使用流程：

構建測試環境：

提交代碼到本地?dev?分支

在需要構建項目時?merge?到本地?test?分支，并推送到遠程?test?分支

持續集成構建，然后同步到測試服務器

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

如果是多人參與的項目，就需要個人開發分支了：

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

使用流程：

構建測試環境：

提交代碼到本地?man1?分支（以?man1?個人為例）

在需要構建項目時?merge?到本地?test?分支，并推送到遠程?test?分支（有可能需要先?pull?遠程的代碼）

持續集成構建，然后同步到測試服務器

構建產品環境可以由遠程的?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?分支：

本地?task1?分支?merge?到本地?prod?分支，并推送到遠程?prod?分支進行持續集成構建

每一個個人分支（如?man1, man2）都需要?pull?一下?prod?分支，以保證自己本地的代碼的版本不會低于服務器

最后刪除?task1?分支

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

因為不同分支修改同一個文件而導致的文件沖突是多人協作開發中比較常見的問題之一，避免這種問題的思路主要有以下的幾種：

在代碼層面，盡量避免多個成員都會改動的文件，盡量將代碼分解到每個人只負責自己的那塊代碼，不需要去改別人的代碼

在工程層面，盡量減少公共文件，盡量每個文件只由一個人負責

在 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?個人分支上開發，并根據需要上傳到不同的服務器。

如果多個需求有沖突，可以每個需求都新建一個分支，如上圖所示：

提交代碼到本地?task1?分支（以?task1?個人為例）

根據需要上傳到不同的服務器

如果代碼通過產品環境后，更新到每個個人分支，并刪除?task1?分支

轉載于:https://www.cnblogs.com/axl234/p/10413689.html

總結

以上是生活随笔為你收集整理的利用git 进行多人协作开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。