配置庫管理及版本管理規範
版本信息 A代表新增，M代表修改，D代表刪除。
|
版本號 |
發佈日期 |
提交人 |
A.M.D |
摘要 |
|
V1.0 |
2019/1/8 |
楊彬彬 |
A |
初稿 |
|
|
|
|
|
|
|
|
|
|
|
|
- 規範項目代碼管理流程，明確開發人員和項目管理者的職責。
- 規範代碼庫分支管理和版本管理，使代碼分支及版本結構清晰，方便維護。
- 配置庫代碼管理工具
使用GitLab作爲代碼管理工具，GitLab 是一個用於倉庫管理系統的開源項目，使用Git作爲代碼管理工具，並在此基礎上搭建起來的web服務。
Git是一個開源的分佈式版本控制系統，用以有效、高速的處理從很小到非常大的項目版本管理。可以實現數據備份、記錄歷史、回到過去、多端共享、分工合作。
git的工作總共分四層，其中三層是在本地，包括了工作目錄，暫存區和本地倉庫。
工作目錄：
執行命令git init時所在的地方，也是執行一切文件操作的地方。
在.git文件夾目錄中，在工作區和版本庫中間起緩存作用的一個區域。它通過git add命令添加進暫存區。存儲了一些即將被commit的文件。
本地倉庫：
在.git文件夾目錄中，使用了git commit命令之後添加進的真正的“倉庫”。裏面存儲了每次commit的記錄，每次commit一次會讓HEAD指針指向新的目錄樹，而舊的目錄就存在版本庫中，可以使用命令來提出之前的目錄樹。
git所存儲的都是一系列的文件快照，然後git來跟蹤這些文件快照，發現哪個文件快照有變化它就會提示你需要添加到暫存區或是提交到本地倉庫來保證你的工作目錄是乾淨的。
進入工作區.git文件夾，如下.git目錄或文件結構說明：
|
目錄或文件 |
說明 |
|
config文件 |
項目的配置文件，裏面有中心服務器的信息和分支信息。 |
|
HEAD文件 |
指向當前的分支。 |
|
index文件 |
暫存區的相關信息。 |
|
logs目錄 |
相關操作產生的日誌。 |
|
objects目錄 |
存儲的就是所有的數據，也就是快照。 存放的是實際上的文件資源，每次當使用了git add命令之後，就已經把文件存到了objects目錄裏面。objects目錄中的object對象都有一個通過哈希算法計算出來的40位16進制的id，前兩位是目錄名，後38位是文件名。因爲哈希算法可以只比較哈希值，就能知道這兩個對象是不是一樣的，這樣可以提高效率。 |
|
refs目錄 |
存儲指向數據提交對象的指針。 |
|
角色名稱 |
職責 |
|
配置管理員 |
|
|
開發負責人 |
|
|
開發人員 |
|
|
測試負責人 |
|
|
測試人員 |
配置管理員負責建立配置倉庫，以便管理源代碼、相關文件及資料。每個開發人員在本地都有自己的版本庫，在服務器上有一個公共的版本庫。
根據配置管理的不同角色所分配的不同職責範圍，對本地庫和版本庫進行管理和操作。
本地庫由開發人員和開發負責人負責日常的更新和開發工作。
- 克隆遠程倉庫，搭建開發環境
開發人員根據配置管理提供的git訪問地址，將遠程倉庫克隆到本地，使工作區可以正常運行起來，並根據分支策略在開發分支上創建分支進行開發工作。
- 代碼提交
開發人員修改完成後提交代碼到暫存區，在暫存區域生成文件快照並提交到本地和遠程開發分支，由開發負責人來進行代碼的審覈和合並。建議開發人員及時同步代碼，以避免衝突和丟失修改。同時，開發人員必須保證上傳的代碼是通過編譯的。
在開發過程中，很多時候需要對一個項目進行分支操作，在開發分支上對項目進行開發。這由開發人員負責執行。
新員工入職後，如需配置庫權限，可走OA或郵件(抄送部門領導)發送給配置管理員申請權限，待領導同意或OA審批通過後，配置管理員爲其創建用戶並分配對應權限。用戶名生成規則爲郵箱前綴。
默認只有配置管理員有權限進行羣組的創建與編輯(可建子羣組)，如有需要可提OA或郵件(抄送部門領導)發送給配置管理員申請權限，待領導同意或OA審批通過後，配置管理員爲其創建羣組或調整相應權限。郵件或OA裏面需要註明具體信息，如：創建羣組的名稱，或調整羣組的具體權限信息等。
如需配置庫權限，可走OA或郵件(抄送部門領導)發送給配置管理員申請權限，待領導同意或OA審批通過後，配置管理員爲其創建用戶並分配對應權限。郵件或OA裏面需要註明申請的具體信息，如：
姓名：xxx
羣組名與角色：atp-bos master
項目名與角色：ATP/Common develop
權限截止日期：2019-07-08（永久權限不寫此項）
不同角色擁有不同權限，下面列出Gitlab各角色常用權限
- 工程權限
|
行爲 |
Guest |
Reporter |
Developer |
Master |
Owner |
|
創建issue |
✓ |
✓ |
✓ |
✓ |
✓ |
|
留言評論 |
✓ |
✓ |
✓ |
✓ |
✓ |
|
更新代碼 |
|
✓ |
✓ |
✓ |
✓ |
|
下載工程 |
|
✓ |
✓ |
✓ |
✓ |
|
創建代碼片段 |
|
✓ |
✓ |
✓ |
✓ |
|
創建合併請求 |
|
|
✓ |
✓ |
✓ |
|
創建新分支 |
|
|
✓ |
✓ |
✓ |
|
提交代碼到非保護分支 |
|
|
✓ |
✓ |
✓ |
|
強制提交到非保護分支 |
|
|
✓ |
✓ |
✓ |
|
移除非保護分支 |
|
|
✓ |
✓ |
✓ |
|
添加tag |
|
|
✓ |
✓ |
✓ |
|
創建wiki |
|
|
✓ |
✓ |
✓ |
|
創建里程碑 |
|
|
|
✓ |
✓ |
|
添加項目成員 |
|
|
|
✓ |
✓ |
|
推送保護分支 |
|
|
|
✓ |
✓ |
|
是否保護分支 |
|
|
|
✓ |
✓ |
|
修改/移除tag |
|
|
|
✓ |
✓ |
|
編輯工程 |
|
|
|
✓ |
✓ |
|
添加deploy keys |
|
|
|
✓ |
✓ |
|
配置hooks |
|
|
|
✓ |
✓ |
|
切換visibility level |
|
|
|
|
✓ |
|
切換工程namespace |
|
|
|
|
✓ |
|
移除工程 |
|
|
|
|
✓ |
|
移除保護分支 |
|
|
|
|
✓ |
- 羣組權限
|
行爲 |
Guest |
Reporter |
Developer |
Master |
Owner |
|
瀏覽組 |
✓ |
✓ |
✓ |
✓ |
✓ |
|
編輯組 |
|
|
|
|
✓ |
|
創建項目 |
|
|
|
✓ |
✓ |
|
管理組成員 |
|
|
|
|
✓ |
|
移除組 |
|
|
|
|
✓ |
默認保護master分支，可使用正則表達式保護分支。保護的分支不能進行push -f操作。
項目的可見性不能超出羣組的可見性範圍，項目或羣組有三種可見性：
Private:私有，必須配置權限纔可進行訪問。
Internal:內部，必須進行帳號密碼登錄後纔可進行訪問。
Public:公開，所有人都可進行訪問。
定期清理已離職或調出項目的成員權限
<暫無>
<暫無>
本公司採用git flow工作流模式進行分支管理。
圖 3-1 git flow工作流程圖
- 主分支master
代碼庫應該有一個、且僅有一個主分支。它是自動建立的，一般默認此分支是被保護的，版本庫初始化以後，就是在主分支在進行開發。此分支除第一次進行原子提交推送外，只能接收其它分支合併，任何人不能直接在master分支上進行修改和提交。
- 開發分支develop
用於日常開發，存放最新的開發版的一個主要分支。不管是要做新的feature還是需要做bug fix，都是從這個分支分出來做。在這個分支下主要負責記錄開發狀態下相對穩定的版本，即完成了某個feature或者修復了某個bug後的開發穩定版本，開發完成需要提交測試的功能都必須要合併到該分支。
- 輔助分支
feature: 開發新功能的分支, 基於 develop, 完成後 merge 回 develop。
release: 準備要發佈版本的分支, 用來修復 bug. 基於 develop, 完成後 merge 回 develop 和 master；
hotfix: 修復 master 上的問題, 等不及 release 版本就必須馬上上線. 基於 master, 完成後 merge 回 master 和 develop。
1.配置管理員在建立倉庫時創建一個master分支和develop分支。
2.開發人員根據開發的功能點從develop分支創建一個feature分支，當功能點開發測試完畢之後，就會合併到develop分支去，可以將feature分支刪除。
3.當需要發佈一個版本來測試時，開發人員從develop分支創建一個release分支來測試。
4.正式發佈後，過程中出現bug,從master分支創建一個hotfix分支，修補結束以後，再合併進master和develop分支。
- 主幹分支:master
- 開發分支:develop
- 創建特性分支，名稱要以f-開頭，加上特性名
- 創建發佈分支，名稱要以r-開頭，加上預發佈版本號
- 創建Bug修復分支，名稱要以b-開頭，加上Bug號
- 創建標籤：
- 當軟件包發佈到UAT環境時要在release分支上打標籤，名稱要以發佈版本號加上RC1，RC2等結尾。
- 當軟件包發佈到正式環境後要在master分支上創建標籤，名稱要以發佈版本號加上REALESE結尾。
爲了規範代碼庫分支管理和版本管理，使代碼分支及版本結構清晰，方便維護，並避免由於維護造成的錯誤的版本發佈等問題。
由對應分支修復的實際開發人員提交或合併到開發分支，開發負責人需要進行判斷是否需要合併，並協助解決衝突代碼。提交的信息必須按照代碼提交模板規定來書寫。
Commit message格式：
type(scope): subject
BugID：如果是修復Bug，請加上Bug號
type： 用於說明 commit 的類別，暫時只使用下面標識(後續可完善增加)。
|
feat： |
新功能（feature） |
|
fix： |
修補bug |
|
docs： |
文檔（documentation） |
|
style： |
格式（不影響代碼運行的變動） |
|
refactor： |
重構（即不是新增功能，也不是修改bug的代碼變動） |
|
chore： |
構建過程或輔助工具的變動 |
|
test： |
測試用例的修改 |
|
ci： |
自動化流程配置修改 |
|
revert： |
回滾到上一個版本 |
|
Other： |
其它 |
scope：【可選】用於說明commit的影響範圍
subject
subject是 commit 目的的簡短描述，不超過50個字符。
例如:
feat(ssr): 增加可視化功能
BugID:8023
1. 同步遠程倉庫代碼，和遠程倉庫進行代碼合併。
2. 將分支工作區修改的代碼和提交描述等提交到開發分支。
3. 開發負責人對提交的分支代碼進行審覈和合並，並解決衝突。
4. 同步到主分支上。
pull同步工作區，找到衝突文件，解決衝突重新提交。
標識、控制和追蹤軟件開發和實施過程中產生的各種軟件產品版本。
<主版本>.<次版本>.<增量版本>-<SNAPSHOT>
主版本：標示項目的重大架構變更。
次版本：表示重大Bug的修復，較大範圍的功能增加和變化。
增量版本：一般標示一些小的bug fix，不會有重大的功能變化。
SNAPSHOT：快照版本，只能用於開發階段對內發佈，對外發布時不允許出現SNAPSHOT版本。
eg：1.3.4-SNAPSHOT
【1】代表該版本是第一個重大版本；
【3】表示這是基於重大版本的第三個次要版本；
【4】表示該次要版本的第四個增量版本；
【SNAPSHOT】表示此版本爲快照版本；
版本號的修改由開發人員根據以上規則進行更改。
-
- 軟件產品包版本管理
預發佈環境：V主版本號.子版本號.增量版本號_日期版本號(yyMMdd)_階段版本號
如：V2.15.0_190108_RC1
正式環境：V主版本號.子版本號.增量版本號_日期版本號(yyMMdd)_RELEASE
如：V2.15.0_190108_RELEASE
主版本號：當功能模塊有較大的變動，比如增加多個模塊或者整體架構發生變化。此版本號由項目決定是否修改。
子版本號：當功能有一定的增加或變化，比如增加了對權限控制、增加自定義視圖等功能。此版本號由項目決定是否修改。
增量版本號：一般是 Bug 修復或是一些小的變動，要經常發佈修訂版，時間間隔不限，修復一個嚴重的bug即可發佈一個修訂版。此版本號由項目經理決定是否修改。
日期版本號:用於記錄修改項目的當前日期，每天對項目的修改都需要更改日期版本號。此版本號由開發人員決定是否修改。
階段版本號:此版本號用於標註當前版本的軟件處於哪個開發階段，當軟件進入到另一個階段時需要修改此版本號。此版本號由項目決定是否修改。
當軟件包正式發佈客戶後需要配置管理員進行歸檔操作。
-
- 出包步驟
- 項目負責人通知項目組準備出包，同時給出出包時間點，如半小時後出包。
- 開發人員收到出包通知後，儘快將完成的代碼進行提交到特性分支，並將特性分支代碼合併到develop分支。
- 提交代碼完成後，配置管理員基於develop分支拉release分支，並在構建時根據標籤命名標準構造新標籤號。如構建失敗則通知開發人員在release分支上修改後重新構建。
- 通過maven和jenkins進行構建、打包和發佈部署。
- 構建完成後通知相關人員。