投稿
  1. 簡單一點首頁
  2. 投稿

公司新人git使用教程，git使用開發流程

投稿專員 • • 投稿

一、分支管理規範

1. Git Flow 模型

Git 流程使用規範

（圖片來源：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

使用方式：

  1. 打開工程目錄下的 .git/hooks 文件夾
  2. 將 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 分支合併的過程中：

Git 流程使用規範

（圖片來源：ProcessOn 模板）

2. 代碼評審流程

Git 流程使用規範
  • 不同的顏色塊，代表不同的角色
  • 創建一個 Merge Request 可以進行多次 Push
  • 開發人員推動整個代碼評審流程的執行，包含及時通知組員評審代碼、通知組長合併代碼等

3. 保護分支設置

在 GitLab 打開要設置的工程 (Maintainers 角色)，選擇 Setting -> Repository -> Protected Branches：

Git 流程使用規範

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

Git 流程使用規範

通過以上設置之後，所有代碼只能通過創建 Merge Request 的方式合併到 develop 和 master 分支；為了代碼庫的安全，需要回收 Maintainers 權限，除組長外的開發人員都是 Developer 權限。

4. Merge Request

1. 創建 Merge Request

打開 Project -> Merge Requests -> New merge request，選擇分支創建合併請求：

Git 流程使用規範
  • 選擇源分支，需要合併的代碼所在的分支
  • 選擇目標分支，將最新代碼合併到的分支

2. 填寫必要信息

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

3. 代碼評審及合併請求

Git 流程使用規範
Git 流程使用規範
  • 只有評審成員評審通過時，合併按鈕才會高亮，才能合併代碼
  • 參與代碼評審的成員，認為代碼沒有問題時，可點擊該按鈕
  • 針對當前代碼創建的討論，有討論存在時，開發者需要及時解決
  • 如果代碼有問題，可直接創建一個討論，即 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）：

Git 流程使用規範

右側是創建好的 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 到遠程分支或者合併請求時，就會自動執行腳本：

Git 流程使用規範

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

Git 流程使用規範

3. GitLab + Jenkins 實現 CI 功能

Jenkins 配置

登錄 Jenkins 賬戶，打開“系統管理” -> “插件管理” -> “可選插件”安裝以下兩個插件：

Git 流程使用規範

打開“系統管理” -> “系統設置” -> “GitLab” 配置 GitLab 服務：

Git 流程使用規範

在 Jenkins 首頁，打開“項目”，“配置” -> “構建觸發器”配置以下信息：

Git 流程使用規範

打開“高級”，生成 Secret token，配置 GitLab 的時候，需要用到：

Git 流程使用規範

GitLab 配置

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

Git 流程使用規範

配置完成，當 push 代碼或者合併請求時，會自動觸發 Jenkins 構建。

原創文章，作者：投稿專員，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/233104.html

贊 (0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
投稿專員的頭像投稿專員
0 0
上一篇 2024-12-11 13:25
下一篇 2024-12-11 13:25

相關推薦

發表回復

登錄後才能評論