一、分支管理規範
1. Git Flow 模型

(圖片來源:A successful Git branching model)
2. Git Flow 分支說明
Master
發版分支 + 保護分支。功能代碼在 Release 分支上測試通過、或 BUG 已在 Hotfix 分支上修復,則需要將代碼合併到 Master 分支。代碼合併到 Master 分支,即代表可以隨時發版,發版成功時需要基於 Master 分支上的最新提交節點打 Tag。
Hotfix
修復分支 + 臨時分支。線上出現緊急 Bug 時,需要基於對應版本的 Tag 創建修復分支,問題修復完成時以此分支進行提測。問題修復後,需將代碼合併到 Develop 和 Master 分支。
基於發版 Tag 創建,最後合併到 Develop 和 Master 分支。
Release
預發布分支 + 臨時分支。功能開發完成併合併到 Develop 分支時,基於 Develop 分支創建 Release 分支進行提測 。Release 分支上出現影響發版的 Bug 時,需要創建 Feature 分支修改 Bug;當測試通過後,需將代碼合併到 Develop 和 Master 分支。
基於 Develop 分支創建,最後合併到 Develop 和 Master 分支。
Develop
開發分支 + 保護分支。多人協作開發時的代碼合併總分支,功能分支向 Develop 分支合併時,往往會有 CodeReview 流程。
基於 Master 分支創建。
Feature
功能分支 + 臨時分支。有新需求時,基於最新的 Deveop 分支創建功能分支,功能開發完成時,需將代碼合併到 Develop 分支。
基於 Develop 分支創建,最後合併到 Develop 分支。
3. Tag&Branch 的區別
Tag 和 Branch 類似,都是引用或者說者指針。在工程里 .git/refs 目錄下能夠清楚的看到,各個 Tag 和 Branch 所指向的提交節點的 SHA-1 值。
區別:
- Tag:Tag 的位置是固定的,在給指定提交打好標籤以後,它就固定於此位置
- Branch:Branch 的位置是會不斷變動的,隨著分支的向前推移或者向後回滾,都在不斷變化
盡量使用 Tag,保存代碼片段。
二、Git Commit 提交規範
1. Commit Message 格式
<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>
可以看出分為三個部分,頭部、主體、底部。
頭部
<type>(<scope>): <subject>
type 類型,修改的類型級別:
- feat:新功能(feature)
- fix:修補 bug
- docs:文檔(documentation)
- style: 格式(不影響代碼運行的變動)
- refactor:重構(即不是新增功能,也不是修改 bug 的代碼變動)
- test:增加測試
- chore:構建過程或輔助工具的變動
scope 修改範圍:
- 主要是這次修改涉及到的部分,最好簡單的概括
subject 修改的副標題:
- 主要是具體修改的功能點
body:主要對本次 commit 的詳細描述,可以分成多行。
footer:主要放置不兼容變更和 Issue 關閉的信息。
為了方便代碼的快速提交,body 和 fotter 部分可以省略。
2. 使用介紹
需求開發或者修改 Bug 時,提交代碼時要添加對應 Jira 編號:
git commit -m "feat(CHESS-1217): 我的頁面增加分享入口及分享功能開發"
修改 Bug 時,需要指明修改代碼所在模塊:
git commit -m "fix(分享): 修改修改部分手機分享大圖為空問題"
沒有具體模塊、或者多模塊代碼一起提交時,可使用其他提交方式:
git commit -m "fix(BUG): 修改推送紅點提示邏輯"
3. 相關工具
Git Hook 自定義攔截腳本:commit-msg
使用環境:python3.7
使用方式:
- 打開工程目錄下的 .git/hooks 文件夾
- 將 commit-msg 腳本複製到文件夾下,即可
全局設置:通過以下方式,可全局設置,每次 git clone 時,自動將 commit-msg 腳本添加到工程的 hooks 目錄中:全局設置 commit-msg。
其他工具:
- Commitizen:輔助撰寫合格 Commit message 的工具
- Commitlint:Commit message 規則校驗工具
4. 拓展
GitLab 與 Jira 關聯
效果:Git Commit 時,在 message 裡面添加工單號,可在 Jira 對應工單詳情頁查看到本次提交。
配置:官方文檔。
三、代碼評審流程
1. 評審環節
代碼評審發生在 Feature 分支向 Develop 分支合併的過程中:

(圖片來源:ProcessOn 模板)
2. 代碼評審流程

- 不同的顏色塊,代表不同的角色
- 創建一個 Merge Request 可以進行多次 Push
- 開發人員推動整個代碼評審流程的執行,包含及時通知組員評審代碼、通知組長合併代碼等
3. 保護分支設置
在 GitLab 打開要設置的工程 (Maintainers 角色),選擇 Setting -> Repository -> Protected Branches:

將 master 和 develop 分支設置為保護分支,只能是 Maintainers 角色 可以合併請求,並且禁止直接 push 代碼。

通過以上設置之後,所有代碼只能通過創建 Merge Request 的方式合併到 develop 和 master 分支;為了代碼庫的安全,需要回收 Maintainers 許可權,除組長外的開發人員都是 Developer 許可權。
4. Merge Request
1. 創建 Merge Request
打開 Project -> Merge Requests -> New merge request,選擇分支創建合併請求:

- 選擇源分支,需要合併的代碼所在的分支
- 選擇目標分支,將最新代碼合併到的分支
2. 填寫必要信息


- Title:簡單總結本次 Merge 的修改點
- Description:詳細描述修改內容,影響範圍等
- Assignee:委託人,選擇具有 Maintainers 角色的成員,該成員會收到合併請求的郵件通知,最後由該成員合併請求
- Approvers:一般選擇小組成員,小組成員具有審核代碼許可權,對不合格代碼可以要求開發者修改
- 分支選擇,功能分支向 develop 分支合併時,會有刪除源分支選項,建議勾選
- 針對本次合併的提交,一次合併請求可以包含多次提交
3. 代碼評審及合併請求


- 只有評審成員評審通過時,合併按鈕才會高亮,才能合併代碼
- 參與代碼評審的成員,認為代碼沒有問題時,可點擊該按鈕
- 針對當前代碼創建的討論,有討論存在時,開發者需要及時解決
- 如果代碼有問題,可直接創建一個討論,即 3 列表會增加,開發者修改之後可點擊 5 關閉討論
- 代碼修改之後,或者不需要修改,點擊關閉討論
5. 其他注意事項
1. 提交合併請求時,先同步最新代碼
提交合併代碼前,建議先執行 git fetch 和 git merge/rebase 將 develop 分支下的最新代碼更新到開發分支,再提交合併請求,避免造成衝突。
2. 合併代碼到 master 分支
通過 develop 分支提測且測試通過後,將 develop 分支的代碼合併到 master 分支進行發版,版本發布完成時及時打標籤。
四、Git 項目集成構建
1. 簡介
GitLab-CI
GitLab-CI 是 GitLab Continuous Integration(GitLab 持續集成)的簡稱。
只要在項目倉庫的根目錄添加 .gitlab-ci.yml 文件,並且配置了 Runner(運行器),那麼每一次合併請求 MR 或者 push 都會觸發 CI pipeline。
GitLab-Runner
GitLab-Runner 是 .gitlab-ci.yml 腳本的運行器,GitLab-Runner 是基於 GitLab-CI 的 API 進行構建的相互隔離的機器(或虛擬機)。GitLab Runner 不需要和 GitLab 安裝在同一台機器上,同時考慮到 GitLab Runner 的資源消耗問題和安全問題,也不建議這兩者安裝在同一台機器上。
Pipelines
Pipelines 是定義於 .gitlab-ci.yml 中的不同階段的不同任務。
Pipelines 可理解為流水線,流水線包含有多個階段(stages),每個階段包含有一個或多個工序(jobs),比如先購料、組裝、測試、包裝再上線銷售,每一次 push 或者 MR 都要經過流水線之後才可以合格出廠。而 .gitlab-ci.yml 正是定義了這條流水線有哪些階段,每個階段要做什麼事。
2. GitLab-CI 功能配置
GitLab-Runner 安裝(macOS)
Install and start gitlab-runner:
brew install gitlab-runner
brew services start gitlab-runner
Register gitlab-runner:
gitlab-runner register
配置以下參數:
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com ):
Please enter the gitlab-ci token for this runner:
Please enter the gitlab-ci description for this runner:
Please enter the gitlab-ci tags for this runner (comma separated):
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
具體配置項的值可參考項目信息(Project -> Settings -> CI/CD -> Runners):

右側是創建好的 Runners;對於多項目可以創建 Shared/Group Runners,多個項目可以共享,不用一一創建;不同 Runners 的創建,僅僅是 Token 不同。
添加構建任務
在根目錄中創建 .gitlab-ci.yml 文件,具體代碼可參照以下示例。
Android 工程:
stages: # 構建步驟
- build
build job:
stage: build
tags: # 根據tag,選擇執行的runner
- tag_0.0.1
only: # 只有在列出的分支合併代碼時,才會觸發構建
- develop
script: # 構建執行的腳本,順序執行
- chmod a+x gradlew
- ./gradlew assembleDebug
artifacts: # 構建後的產物
paths:
- app_debug/
iOS 工程文件配置類似,只是 script 腳本不同;.gitlab-ci.yml 具體語法,可參考以下官方文檔:gitlab-ci 語法。
將代碼 push 到遠程分支或者合併請求時,就會自動執行腳本:

點擊列表,可看到單個 job 的執行情況,包括控制台日誌輸出和文件產出:

3. GitLab + Jenkins 實現 CI 功能
Jenkins 配置
登錄 Jenkins 賬戶,打開「系統管理」 -> 「插件管理」 -> 「可選插件」安裝以下兩個插件:

打開「系統管理」 -> 「系統設置」 -> 「GitLab」 配置 GitLab 服務:

在 Jenkins 首頁,打開「項目」,「配置」 -> 「構建觸發器」配置以下信息:

打開「高級」,生成 Secret token,配置 GitLab 的時候,需要用到:

GitLab 配置
打開 Project -> Settings -> Integrattions 填寫上一步生成的 URL 和 Secret Token 信息:

配置完成,當 push 代碼或者合併請求時,會自動觸發 Jenkins 構建。
原創文章,作者:投稿專員,如若轉載,請註明出處:https://www.506064.com/zh-tw/n/233104.html