目前所在公司開發的系統為一個基礎版本（通用版）包含了行業內一些基礎功能實現，后期根據不同廠家進行定制版的開發，考慮獨立項目的話代碼維護不太方便，并且如果通用版本有變動的話，其他定制版本也都需要進行變動。

gitflow工作流

公司之前采用svn進行維護代碼，最近才開始進行轉變到用git 進行維護，在學習的過程中對比了一番最終選擇采用gitflow工作流進行管控， 具體介紹如下：

master分支:主分支，可隨時交付給用戶使用的版本

dev分支：開發分支，項目組內用于開發的分支，并且保證該分支代碼是可運行

feature分支：功能分支，項目中開發新需求或者修改bug都在此分支上進行。

release分支:測試分支，開發完成之后，基于dev創建該分支

hotfix分支:bug修復分支，用于修復bug，發現bug創建此分支進行修復，基于release或者master分支創建

由于現在處于開發階段故現在對分支的維護方面沒有那么完善，而且公司內部沒有測試人員，現在的測試流程都是寫完代碼內部自己進行測試，現在進行開發的時候一般都是基于dev分支創建feature分支：

創建feature分支以及合并方案

• 當前處于dev分支或者release分支，基于dev或者release創建新分支

• 創建新功能分支并且切換到該分支,當該功能開發完畢之后，如果該功能開發周期較長，每天從dev分支合并到功能分支上，避免跟dev分支差異較大

• 當功能開發完成合并到dev或者release分支當中，完成之后刪除本地分支，避免本地分支過多，分不清功能是否合并。

創建release分支以及合并方案

• 當前處于dev分支當中，基于dev分支創建release分支
• 創建該分支之后，進行打包發布測試，如果測試當中發現bug，創建hotfix分支，進行修復bug，創建hotfix分支主要想的是多人開發過程中，發現那個模塊誰負責，誰去修改bug
• 當該分支測試完成之后合并到master和dev分支當中

創建hotfix分支以及合并方案

• 當前處于release分支或者master分支當中
• 當release分支發現bug之后，根據release分支創建該分支，進行修復bug。
• 該分支修改完成之后如果是release的bug合并到release分支就可，如果是基于master分支創建的還需要合并到dev分支當中

命名規則

分支命名方式采用如下規則例如: add_user_0302add：代表工作類型user代表具體功能模塊：user:具體的功能模塊0302:分支創建時間 復制代碼

git注釋提交規范

注釋提交采用如下規則例如:[修復bug]：bug號1.修復的具體功能 復制代碼

---

基于上述規范根據我們項目組的情況，創建了如下三個版本的分支結構如下:

• master分支
• master-A分支
• master-B分支

master分支

基礎版本分支，開發一些通用功能（目前所有工作都是在此版本開發）

master-A分支

基于通用版本生成的一個分支版本，根據A客戶提出的新需求進行客制化的開發

master-B分支

基于通用版本生成的分支版本，根據B客戶提出的新需求進行客制化開發

master分支維護

master版本維護分如以下：devrelease/hotfix/feature/ 復制代碼

master-A/master-B維護

master-A或者master-B版本維護分支如下：dev-Arelease-A/hotfix-A/feature-A/ 復制代碼

基礎版本同步方案

當基礎版本有新功能開發，或者是修復之前遺留的bug，開發完成之后，合并到其他master-A或者master-B分支當中，避免重復開發帶來的時間成本。

開發注意事項

根據不同的業務創建分支的時候選擇創建不同的分支，例如master分支在進行創建功能分支的時候應該是：

• feature/add_user_0302

master-A創建功能分支應該是：

• feature-A/add_user_0302

注：此方案目前只是一個規劃，如果您有更好的方案還請留言告知

轉載于:https://juejin.im/post/5c79cfa5e51d4506e27fe61f

總結

以上是生活随笔為你收集整理的git项目根据不同需求进行独立开发的全部內容，希望文章能夠幫你解決所遇到的問題。

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