版本管理規範
主要分為4個分支，dev，test，master, release
dev用於本地開發
test用於發布測試環境
master 主線**庫
release分支，代表發布的線上版本
開發人員在dev分支上開發，開發完成需要發布到測試環境的時候，合併**到test分支，然後將test分支**發布到測試環境，測試環境測試出來的bug，直接在test分支修改，當測試環境全部測試通過，準備發布到正式環境的時候，將test**合併到master分支和dev分支，並且建立乙個release分支並打tag，
分支名稱為release_v版本號_yyyymmddhhmmss
下一次迭代開發內容接著在dev分支上開發
當線上環境出現bug，需要修復的時候，直接在release分支修改發布測試環境，測試通過之後發布正式環境，然後將**合併到dev分支
在測試環境沒有測試通過之前，禁止發布版本到正式環境，正式版本發布前半小時，必須郵件通知所有相關人員
每次提交**，必須詳細編寫comment
，格式為 type：主題，如果為修改bug，必須標註對應的jira編號
type用於說明 commit 的類別，只允許使用下面8個標識。
主題必須能清晰的表述這次提交**的變動
控制提交粒度，不要一次性提交包括多個問題的**，乙個問題的相關**
作為一次提交
版本號規範，v主版本號.子版本號.修正版本號
主版本號.子版本號
由產品經理確定，修正版本號從0開始計算，每次修改bug或者增加小功能時+1
推送本地**到伺服器時，需要先將伺服器最新**同步到本地，然後進行合併，再進行push操作。
在push之前，可有兩種操作方式：git pull和 git fetch + git rebase。
建議使用 git fetch + git rebase兩步操作。
在實際使用中，git fetch更安全一些。因為在merge前，我們可以檢視更新情況，然後再決定是否合併。
而使用git rebase後產生的結果會比使用git merge更為簡潔。
git pull：相當於是從遠端獲取最新版本並merge到本地。合併結果將會應用到本地分支。
git fetch：相當於是從遠端獲取最新版本到本地，不會自動merge。本地分支**不變，需要繼續進行merge或rebase。
git pull相當於 git fetch + git merge。
git merge：將兩個分支進行合併，合併的結果是生成乙個新的快照（並提交）。
git rebase：將兩個分支進行合併，合併結果比較整潔，不會生產新的快照。
如下所示，假設當前工作分支為mywork，有人也在"origin"分支上做了一些修改並且做了提交了. 這就意味著"origin"和"mywork"這兩個分支各自"前進"了，它們之間"分叉"了：
以下是git merge後的結果：
以下是git rebase後的結果：
可通過以下命令進行全域性設定：
$ git config --global pull.rebase true
以後用git pull就等於git fetch+git rebase了
rebase原則：只對尚未推送或分享給別人的本地修改執行變基操作清理歷史，從不對已推送至別處的提交執行變基操作。
為防止產生不可預料的事情，已經推送到伺服器的分支直接經過merge合併，不使用rebase。
版本管理規範
1 目的 標識 控制和追蹤軟體開發和實施過程中產生的各種軟體產品版本。2 適用範圍 適用於大運會專案所有軟體源 產品版本的管理。3 職責 3.1 測試管理 確保專案版本按照正確的版本管理規範執行和使用。3.2 配置管理員 負責定期檢查各專案對版本管理規範的執行度 根據發展需要對規範進行完善。3.3 ...
版本管理規範
專案 產品 大版本管理及分支策略 產品內部功能特性迭代的節奏以及版本管理 以產品為基礎各個專案的版本管理 產品自身的 分支管理方法，以不同產品版本為基礎的各個專案的 版本管理 業務微服務版本管理 產品或者專案是由多個業務微服務組成的，業務微服務的版本管理主要關注微服務本身功能特性的迭代 服務端api...
版本管理規範
master 顧名思義，既然名字叫master，那麼該分支就是主分支的意思。在git repo下主分支的職責主要就是負責記錄stable版本的迭代，當在beta版本的專案或是開發版本的專案得到了充分的驗證之後，我才能將分支併入master分支。master分支永遠是production ready的...