代碼倉庫創建規范
1、 專案創建需符合Group規范，
2、 創建專案必須添加Project description說明，
3、 每個專案都需要README.md檔案，
4、 除檔案說明型別倉庫，所有代碼倉庫都需要.gitignore，
注：有模板的專案，要以統一的模板創建專案
Groups使用規范
Group 分為 rule(技術行為規范)、lab（技術預研）、common(基礎庫)、realicloud(基礎平臺)、rexxox(產品)、customer(定制化開發專案)
目錄結構及權限介紹
-
rule - Internal
-
- 主要用于存放技術行為規范相關資料
-
lab - Internal
-
- 主要用于存放技術預研，比如shader預研、售前demo技術預研等，
-
common - Internal
-
- 主要用于存放公共組件庫，基礎演算法庫
-
rexxxud - Private
-
- 主要用于存放底層基礎能力平臺相關微服務，如PaaS層的介面、網關鑒權服務等，
-
rexxxb - Private
-
- 主要存放產品相關業務代碼，如應用中心小程式等，
-
customer - Private
-
- 主要存放客戶制定化開發專案代碼，
權限說明：gitlab主要包括三種權限Private、Internal、Public，分別為只對組內用戶開放、注冊用戶可見和公開，公司gitlab一般不使用Public
關聯倉庫的管理
涉及內部倉庫之間的參考采用 submodule 進行版本管理，對于可開源發布的版本管理采用包管理，比如pip、npm、go get，
主專案管理形式如下：
A(主專案) --> B(common公共模塊)
|
|---> C(包管理)
|
|---> D(其他倉庫)
將參考專案作為submodule添加到主專案中：
# 添加submodule
$ git submodule add <遠程參考模塊倉庫地址>
子專案版本管理和主專案版本管理是分發的，主專案中的子專案更新需要手動操作：
# 更新子模塊
$ git submodule update --init
README檔案規范
README檔案結構如下：
<專案簡介/Introduction>
<快速使用/Quick start>
<檔案說明/Documentation>
Introduction用于闡述專案基本情況和功能（是什么，用來做什么的）Quick Start主要包括兩部分內容：簡易的安裝部署說明(Deployment)和使用案例(Example)，Documentation部分是核心的檔案，對于大型專案可以使用超鏈接代替
參考：
使用 Description Template
使用 merge request template
(待補充:https://docs.gitlab.com/ee/user/project/description_templates.html)
https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/merge_request_templates/Security Release.md
版本管理規范
專案代碼release包括三類：
- 大版本(x.0.0)
- 小版本(x.x.0)
- 補丁(x.x.x)
版本管理
git 流程模式有兩種：一種是Git flow作業流，一種是Github flow作業流，
Git Flow 分支模型
步驟
- master分支不做代碼提交，master為生產環境運行代碼
- 開發主要在develop分支上進行提交
- 功能開發切換一個新的功能分支上，功能分支完成后需合并到develop分支
- 用release分支做版本發布，release用于預發布環境測驗
- release分支從開發分支切出來，完成后需要合并到master分支和develop分支
- 預發布環境測驗無誤后，release分支合并到master分支，發布到生產環境測驗
- 生產環境測驗完成后release分支可以洗掉
- 生產環境運行中緊急修復采用hotfix分支，hotfix分支從mater分支切出
- hotfix分支修復后需合并會master分支和develop分支
功能開發
創建功能分支
# 從develop創建功能分支
$ git checkout -b myfeature develop
完成功能分支，合并develop，并推送到遠程倉庫
# 切換到develop分支
$ git checkout develop
# develop分支合并功能分支
$ git merge --no-ff myfeature
# 洗掉功能分支
$ git branch -d myfeature
# 推到遠程倉庫
$ git push origin develop
版本發布
版本發布前，創建版本分支
# 從develop分支切到版本發布分支
$ git checkout -b release-1.2 develop
完成版本測驗后，合并到master分支上
# 切換到master
$ git checkout master
# master合并release分支
$ git merge --no-ff release-1.2
# 給master分支打tag
$ git tag -a 1.2
生產環境測驗沒有問題后，將release分支合并會develop分支，并洗掉release分支
# 切換到develop分支
$ git checkout develop
# develop分支合并release分支
$ git merge --no-ff release-1.2
# 洗掉release分支
$ git branch -d release-1.2
臨時補丁
生產環境上發現bug，直接通過hotfix快速修復:
# 從master切出一條分支，緊急修復問題
$ git checkout -b hotfix-1.2 master
完成問題修復后，合并進master：
# 切到master分支
$ git checkout master
# master分支合并hotfix分支
$ git merge --no-ff hotfix-1.2
# 打上新tag
$ git tag -a 1.2
# 切換到develop分支
如果當前release分支還未洗掉，合并到release分支，再由release分支合并到develop分支:
$ git checkout release-1.2
# release-1.2合并hotfix分支
$ git merge --no-ff hotfix-1.2
# 洗掉hotfix分支
$ git branch -d hotfix-1.2
# 切換到develop分支
$ git checkout develop
# develop分支合并release分支
$ git merge --no-ff release-1.2
如果release分支已洗掉，則直接合并到develop分支：
# 切換到develop分支
$ git checkout develop
# develop分支合并release分支
$ git merge --no-ff hotfix-1.2
# 洗掉hotfix分支
$ git branch -d hotfix-1.2
原則
- 開發永遠不直接提交到master分支，master保留用于發布到生產中的代碼
- 盡量一個任務，一個功能分支
- 在合并到開發分支前，對每個merge requests測驗
- 新功能只添加到develop分支
優缺點
優點：
- 流程清晰，覆寫面全，通過分支模型將作業流串通
- git flow作為最早提出的分支模型，也是最廣泛使用的分支模型，受眾廣泛
- 以master作為生產分支，面向單版本的線上產品迭代
缺點：
- 分支十分復雜，敏捷性較差
- 僅master分支上做持續集成，而大部分工具默認將master分支設為默認分支，因此經常面臨分支切換，導致很繁瑣
- 修補分支和發布分支設定繁瑣，比如每次使用修補分支都需要同時合并到master和develop分支，但開發經常犯錯誤，比如忘記合并回develop分支
Github Flow 分支模型
面對git flow的繁瑣，github flow分支模型僅具有功能分支和主分支，將所有內容合并到master分支中并進行部署，采用pull request方式進行代碼合并，強調持續集成和連續交付，
優點：
- 流程十分簡單，可以滿足敏捷交付
- 不需要頻繁切換分支，在自己的倉庫進行開發，統一合并master
- 每次提交均需要測驗
缺點：
- 對自動化測驗要求較高，需要大量的單元測、端到端測驗和集成測驗
- 模型過于簡單，對于部署、發版和集成上存在著大量問題
Gitlab Flow 分支模型
結合了git flow分支模型和github flow分支模型：
步驟
- 需要一個staging環境和pre-production環境（兩個生產環境鏡像）
- 從主倉庫 fork 到自己的倉庫
- 所有請求直接提交到master分支，每次提交都做持續集成和測驗，主要是自動化測驗
- 每個merge requests需要描述符合提交規范，每個人出了代碼輸出作業，需要每天抽出時間進行code review，
- 部署發布的時候，從master中摘取(cherry Pick)核心發布功能到"release-x.x.x-alpha"分支進行測驗，并在其上進行修復
- 測驗通過后，切換到"release-x.x.x"分支并洗掉"release-x.x.x-alpha"分支，將"release-x.x.x"分支發布到生產環境中進行測驗
- 生產環境測驗通過后，將"release-x.x.x"合并回master
要使用好cherry-pick，每個提交要清晰簡潔
功能開發
# fork到用戶倉庫
# 拉取到本地修改
$ git clone <your repo>
# 切出一個分支
$ git branch -b feature/xx
# 提交
$ git commit
# 上傳到自己的倉庫
$ git push origin
# 向主倉庫發起merge requests請求，合并到主倉庫master
# CI通過并且其他人code review后同意即可合并到主倉庫
預發布
# 從最新的release版本切出一個新的版本分支release-x.x.x-alpha
$ git checkout -b release-x.x.x-alpha
# 從master分支cherry-pick所需提交記錄
$ git cherry-pick hash1 hash2 hash3
# 上傳到自己的倉庫
$ git push origin
# 向主倉庫發起merge requests請求，合并到release-x.x.x-alpha
# CI通過并且其他人code review后同意即可合并到主倉庫
優缺點
優點：
- 相比git flow分支模型更簡單，減少了分支數量
- 和github flow分支模型一樣，更強調測驗，對所有提交都需進行測驗或code review
缺點：
- 需要自動化測驗流程支撐，需要有較好的持續集成和連續交付基礎
commit規范
git commit 提交樣式規范：
<型別>: <標題>
<空一行>
<內容>
<空一行>
<結尾>
<型別>
用于說明 commit 的類別，只允許使用下面7個標識，
- feat：新功能（feature）
- fix：修補bug
- docs：檔案（documentation）
- style： 格式（不影響代碼運行的變動）
- refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
- test：測驗相關改動
- chore：構建程序(CI/CD)或輔助工具的變動
<題目>
commit 目的的簡短描述，不超過50個字符
<內容>
對本次 commit 的詳細描述，可以分成多行，可詳細說明代碼變動的動機
<結尾>
Footer 部分只用于以下兩種情況：
不兼容變動
如果當前代碼與上一個版本不兼容，則 Footer 部分以BREAKING CHANGE開頭，后面是對變動的描述、以及變動理由和遷移方法，
BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
}
After:
scope: {
myAttr: '@',
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
關閉 Issue
如果當前 commit 針對某個issue，那么可以在 Footer 部分關閉這個 issue ，
Closes #234
Example
feat(compiler): comments for if-else conditions #10286
In order to fix these 2 issues, I need to have access to the HTML comments before a v-else block
vue-styleguidist/vue-styleguidist#430
vue-styleguidist/vue-styleguidist#322
To give you an example, here is a format that does not work with the current parser.
Since we cannot have the comments as normal nodes, I thought we could have the missing comment beside the ifCondition.
closes #10288
Revert
還有一種特殊情況，如果當前 commit 用于撤銷以前的 commit，則必須以revert:開頭，后面跟著被撤銷 Commit 的 Header，
revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
Body部分的格式是固定的，必須寫成This reverts commit <hash>.，其中的hash是被撤銷 commit 的 SHA 識別符號，
如果當前 commit 與被撤銷的 commit，在同一個發布（release）里面，那么它們都不會出現在 Change log 里面，如果兩者在不同的發布，那么當前 commit，會出現在 Change log 的Reverts小標題下面，
Commitizen
可以使用典型的git作業流程或通過使用CLI向導Commitizen來添加提交訊息格式，
安裝
npm install -g commitizen
然后，在專案目錄里，運行下面的命令，使其支持 Angular 的 Commit message 格式，
commitizen init cz-conventional-changelog --save --save-exact
以后，凡是用到git commit命令，一律改為使用git cz，這時，就會出現選項，用來生成符合格式的 Commit message，
生成 Change log
如果你的所有 Commit 都符合 Angular 格式，那么發布新版本時， Change log 就可以用腳本自動生成，生成的檔案包括以下三個部分：
- New features
- Bug fixes
- Breaking changes.
每個部分都會羅列相關的 commit ，并且有指向這些 commit 的鏈接，當然，生成的檔案允許手動修改，所以發布前，你還可以添加其他內容，
conventional-changelog 就是生成 Change log 的工具，運行下面的命令即可，
$ npm install -g conventional-changelog
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -w
整理自CTO-石老大
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/106578.html
標籤：其他
上一篇：MFC 用向導添加WM_CLOSE訊息，會生成OnClose函式，如何在這個函式中獲取WM_CLOSE的WPARAM和LPARAM引數