***各產品使用統一的版本命名規則，規則如下：
主版本號.子版本號.修訂版本號[_fix號]
版本號各部分均由數字構成，主版本號和子版本號為1至2位數字組成，由0開始遞增，修訂版本號由3位數字組成，由000開始。fix號由fix+數字組成。
示例：0.1.001，0.2.013，0.10.023，0.1.001_fix1等均是合法的版本號。
在同一時刻，***各產品主版本號統一，子版本號可能會有較小的差異，修訂版本號按實際需要編制。
目前***研發面臨四個環境：線上（生產）環境、預生產環境、持續整合環境和測試環境。線上（生產）環境：產品正式使用環境，不允許未經測試的不穩定版本部署；並且要求持續執行，不允許長時間服務間斷。預生產環境：產品演示和模擬線上環境進行測試的部署環境。主要用於針對客戶進行演示，並進行無法在測試環境中進行的效能測試等作用。必要時，可作為上線環境的備用，臨時切換。持續整合環境：開發團隊日常開發的最新功能的部署環境；不要求穩定，主要用於開發團隊驗證功能。測試環境：測試團隊進行產品測試時使用的部署環境；當產品階段性完成進入alpha測試階段，由測試團隊接手，進行系統測試的部署環境。
針對目前的產品環境情況，**託管系統劃分為五類分支：develop、master、release/v版本號、hotfix/v版本號_fixn
develop：面向開發環境，此分支**代表目前開發進度。最新研發的功能都隨時在此分支體現。此分支**由各個開發人員進行提交。要求提交的**需要通過本地編譯和測試。禁止提交未通過編譯的**。
release/v版本號：在產品開發達到可以提交測試的程度時，由開發負責人從develop分支建立」release/v版本號」（如release/v0.9.1）分支，面向測試環境，此分支**代表發布測試環境**。在此分支只允許進行bug修復，不得進行新特性開發。完成測試後，該分支合併至master和develop分支。上線後，該分支可以刪除。
master：面向生產環境，此分支**代表線上（生產）環境的**。只從release和hotfix分支合併通過測試的**。開發**嚴禁提交到此分支。此分支**由各產品研發負責人進行合併和提交，上線成功後，應對**打上名為版本號的tag，如v0.9.1，v0.9.1_fix1均是合法的tag名。
hotfix/v版本號_fixn：線上**出現重大問題時的快速修復分支，要求hotfix分支必須從master分支上的tag建立，命名規則為v版本號_fixn，n為序號。要求修復後，必須提交測試，測試通過後，將提交合併到master和develop分支之上。
為了更加有效率的開發、更加有效率的team work。提交產品**是需要有一定規則。有利於對於**進行分析、管理，並且方便進行**追蹤有助於提高開發效率。
**提交需要注意以下幾點：
提交注釋需要遵守以下規則：
提交狀態
格式示例
說明新增功能
add: 新增xx功能
新增乙個系統功能
修改功能
modify：修改xx功能，（原因說明）
修改乙個系統功能（此問題未出現在issue系統中）或需求修改
刪除功能
remove：刪除xx功能，（原因說明）
刪除乙個功能
重構功能
refactoring：重構xx功能，（原因說明）
重構某些**
修復問題
fix #***x：修復***x問題，（原因說明）
修復issue track系統（jira等）提出的問題，有實際編號。#後跟issue編號。
其他問題
other：其他原因
其他提交原因（此提交狀態不建議使用）
產品**review主要需要達到如下幾個目的：
產品**review的主要關注點：
專案質量管理 規劃質量管理與控制
規劃質量管理，是識別專案及其可交付成果的質量要求和標準，並準備對策確保符合質量要求的過程。規劃質量管理過程的主要作用是 為整個專案中如何管理和確認質量提供了指南和方向。規劃質量管理的輸入 專案管理計畫 干係人登記冊 風險登記冊 需求檔案 事業環境因素 組織過程資產 規劃質量管理的工具與技術 成本效益...
質量管理手冊
公司的質量管理工作都是以質量管理手冊為核心開展的。那麼，質量管理手冊到底如何制定呢？首先，應該有乙個公司的質量方針和質量目標。質量方針表達公司希望通過質量工作達到什麼樣的乙個願景，比如為人們提供優質的網路通訊服務。在制定質量目標時，因該先參考公司所在行業的標準，制定出質量標準，選擇適合各個產品線中各...
L質量管理
l質量管理 質量管理概念 質量管理流程 建立質量標準體系 專案實施中進行質量監控 實際和標準對比 糾偏糾錯 質量管理理論 tqm 全面質量管理 全面方法 科學管理方法 數理統計 全過程 市場調研 選型 研發 實驗 全員參與 銷售 研發 服務 全面結果 產品質量 工作質量 工程質量 服務質量 iso9...