版本控制指引（版本控制指引是什么）
概念
產(chǎn)品版本
項目/子項目所定義的版本，兩節(jié)：x.y。如智計劃1.2，那么這個產(chǎn)品版本號為1.2。
工程版本
代碼構(gòu)建產(chǎn)物的版本。工程版本號通常為四節(jié),x.y.z.build。x.y 繼承產(chǎn)品版本號；z在敏捷項目團隊中是沖刺編號，在瀑布團隊中為流水號。該節(jié)用于區(qū)分不同的研發(fā)、上線周期；build為構(gòu)建流水號，通常由構(gòu)建工具自動生成。
測試代碼同樣也有工程版本號。目前測試代碼沒有發(fā)布流程，也沒有通過工具發(fā)布，所以z.build由測試團隊人員自行決定。原則上每一次正式交付，變更z。
發(fā)布標簽
每一次發(fā)布到生產(chǎn)，在git代碼庫中，給對應(yīng)的commit標記一個標簽，值為部署物的工程版本，即x.zy.z.build。
目標
統(tǒng)一分支管理策略以及定義。版本化一切，最終提高項目的團隊合作效率、加速新功能開發(fā)和發(fā)布管理。
原則
- 采用GitHub Flow策略（推薦）或基于主干開發(fā)策略。
- 要求項目有完善的自動化測試、持續(xù)集成和部署等相關(guān)的基礎(chǔ)設(shè)施。
- 版本化一切。
- 團隊有代碼審查的相應(yīng)流程。
- 具備自動部署的條件
規(guī)范
代碼倉庫
- 必須：代碼應(yīng)放在集團統(tǒng)一的代碼倉庫。
- 必須：工程的可見性不能設(shè)置為public。
- 必須：只允許給項目相關(guān)開發(fā)人員配置權(quán)限，并應(yīng)該遵循最小授權(quán)原則。
- 必須：代碼項目創(chuàng)建在團隊空間內(nèi)，不允許放在個人空間。
- 建議：團隊空間命名格式為：group/[subgroup]。group為產(chǎn)品線簡稱，如果產(chǎn)品線有多個子產(chǎn)品，再加上subgroup。subgroup為子產(chǎn)品簡稱。如 gaia/gfs，group=gaia，subgroup=gfs。
- 建議：代碼項目命名格式為：項目代號-模塊[-子模塊][-孫模塊]。如：gaia-gfs-demo，halo-wechat。這樣，GIT中完整的空間-項目名為：gaia/gfs/gaia-gfs-demo。
分支命名【GitHub Flow】
- 必須：master分支被保護，不允許直接提交至master。
- 必須：創(chuàng)建分支使用有意義的名稱頭，功能開發(fā)用 feature/{JIRA編號}-*，bug修復(fù)用 bug/{JIRA編號}-*，熱修復(fù)用 hotfix/{JIRA編號}-*。如 feature/XM1907901-1390-enable_audit_log_for_inventory, bug/XM1907901-1403-xxxxxxx。
- 建議：創(chuàng)建分支開始后，就創(chuàng)建一個MR，用于描述思路，并記錄討論過程。
- 建議：未完成的MR以WIP:開頭，如：“WIP:用戶1分鐘未有動作，自動鎖屏”。
- 必須：至少有一個成員同意合并，才允許合并分支。
- 建議：合并分支時，使用 –squash，或選中g(shù)itlab界面上的"[X]Squash commits when merge request is accepted"。
版本
- 必須：每一次準備發(fā)布生產(chǎn)的交付物，打上發(fā)布標簽，并記錄Release Notes。
- 建議：數(shù)據(jù)庫有版本號。不同版本的數(shù)據(jù)庫變更腳本，支持冪等操作，以便自動化完成升級/降級。
- 建議：測試用例、測試數(shù)據(jù)也有版本號，要么和代碼工程版本一致，要么自定義，和代碼工程版本有對應(yīng)關(guān)系。
- 建議：推薦使用Flyway，EntityFramework Migrations來管理DB版本。
推薦實踐
版本號使用場景
- 敏捷項目沖刺開始，定義本沖刺版本的前三節(jié)。
- 提交、解決、關(guān)閉bug時，正確填入了DevOps中對應(yīng)的工程版本號。
- DevOps構(gòu)建時，根據(jù)前三節(jié)，自動補充最后一節(jié)的編譯流水號。
- 發(fā)布至生產(chǎn)環(huán)境時，DevOps根據(jù)工程版本，自動生成tag標簽。
- 如果只通過DevOps部署，則沒有沖刺版本。DevOps根據(jù)產(chǎn)品版本，自動加上制品的上傳批次號，如1.2.13，以追蹤各環(huán)境和不同版本部署物的對應(yīng)關(guān)系。
假設(shè)場景
|
項目名稱 | 開發(fā)啟動時間 | 移交測試時間 | 回歸時間 | 上線時間 |
XX項目 | 9月1日 | 9月15日 | 9月25日 | 9月26日 |
開發(fā)流程
|
序號 | 時間 | 事項 | 描述 | 命令 | 說明 |
1 | 9月1日 | 從master新建分支 | 從master創(chuàng)建分支。分支名稱：feature/11-Add_redis_support | git checkout master git pull git checkout -b feature/11-add_redis_support git push –set-upstream origin feature/11-add_redis_support | 所有參與人員都提交到此分支 |
2 | 9月2日 | 設(shè)計、編寫代碼與測試 | 提交、提交、提交 | git add –allgit commit -a -m "move display name to redis" git push | |
3 | 9月3日 | 開啟MR，以開啟討論和Review | 從gitlab的站點中創(chuàng)建一個MR。 | 如果并未做完，MR以"WIP:"開頭 | |
4 | 9月15日 |
討論、修改、測試 | 討論方案、修正review的改進項。 | git add . | |
5 | 9月16日 | 循環(huán)修復(fù)bug并不斷push到遠程分支。 | git commit -am "move on and on" | ||
6 | …… | 每日merge master代碼到分支。 | git merge master | ||
7 | 9月25日 | 自動化、人工驗收全部通過，MR通過 | master代碼可以發(fā)布時，打上版本號標簽，1.1.0 | git tag add "1.1.0" git push –tag | 選中 "Squash commits when merge request is accepted.“ 選中 "Delete source branch when merge request is accepted" |
8 | 9月26日 | 部署 | 生產(chǎn)環(huán)境部署master。 | 通告其他分支開發(fā)人員盡快merge master代碼 |
