2. 河豚號(hào) > 生活百科 >

git使用開(kāi)發(fā)流程（公司新人git使用教程）

河豚俠 ? 生活百科 ? 2022-05-25 10:06:50 ?

一、分支管理規(guī)范

1. Git Flow 模型

 

Git 流程使用規(guī)范

 

(圖片來(lái)源：A successful Git branching model)

2. Git Flow 分支說(shuō)明

Master

發(fā)版分支 + 保護(hù)分支。功能代碼在 Release 分支上測(cè)試通過(guò)、或 BUG 已在 Hotfix 分支上修復(fù)，則需要將代碼合并到 Master 分支。代碼合并到 Master 分支，即代表可以隨時(shí)發(fā)版，發(fā)版成功時(shí)需要基于 Master 分支上的最新提交節(jié)點(diǎn)打 Tag。

Hotfix

修復(fù)分支 + 臨時(shí)分支。線上出現(xiàn)緊急 Bug 時(shí)，需要基于對(duì)應(yīng)版本的 Tag 創(chuàng)建修復(fù)分支，問(wèn)題修復(fù)完成時(shí)以此分支進(jìn)行提測(cè)。問(wèn)題修復(fù)后，需將代碼合并到 Develop 和 Master 分支。

基于發(fā)版 Tag 創(chuàng)建，最后合并到 Develop 和 Master 分支。

Release

預(yù)發(fā)布分支 + 臨時(shí)分支。功能開(kāi)發(fā)完成并合并到 Develop 分支時(shí)，基于 Develop 分支創(chuàng)建 Release 分支進(jìn)行提測(cè) 。Release 分支上出現(xiàn)影響發(fā)版的 Bug 時(shí)，需要?jiǎng)?chuàng)建 Feature 分支修改 Bug;當(dāng)測(cè)試通過(guò)后，需將代碼合并到 Develop 和 Master 分支。

基于 Develop 分支創(chuàng)建，最后合并到 Develop 和 Master 分支。

Develop

開(kāi)發(fā)分支 + 保護(hù)分支。多人協(xié)作開(kāi)發(fā)時(shí)的代碼合并總分支，功能分支向 Develop 分支合并時(shí)，往往會(huì)有 CodeReview 流程。

基于 Master 分支創(chuàng)建。

Feature

功能分支 + 臨時(shí)分支。有新需求時(shí)，基于最新的 Deveop 分支創(chuàng)建功能分支，功能開(kāi)發(fā)完成時(shí)，需將代碼合并到 Develop 分支。

基于 Develop 分支創(chuàng)建，最后合并到 Develop 分支。

3. Tag&Branch 的區(qū)別

Tag 和 Branch 類(lèi)似，都是引用或者說(shuō)者指針。在工程里 .git/refs 目錄下能夠清楚的看到，各個(gè) Tag 和 Branch 所指向的提交節(jié)點(diǎn)的 SHA-1 值。

區(qū)別：

Tag：Tag 的位置是固定的，在給指定提交打好標(biāo)簽以后，它就固定于此位置

Branch：Branch 的位置是會(huì)不斷變動(dòng)的，隨著分支的向前推移或者向后回滾，都在不斷變化

盡量使用 Tag，保存代碼片段。

二、Git Commit 提交規(guī)范

1. Commit Message 格式

():

<空行>

 

<空行>

 

 

可以看出分為三個(gè)部分，頭部、主體、底部。

頭部

():

type 類(lèi)型，修改的類(lèi)型級(jí)別：

feat：新功能(feature)

fix：修補(bǔ) bug

docs：文檔(documentation)

style： 格式(不影響代碼運(yùn)行的變動(dòng))

refactor：重構(gòu)(即不是新增功能，也不是修改 bug 的代碼變動(dòng))

test：增加測(cè)試

chore：構(gòu)建過(guò)程或輔助工具的變動(dòng)

scope 修改范圍：

主要是這次修改涉及到的部分，最好簡(jiǎn)單的概括

subject 修改的副標(biāo)題：

主要是具體修改的功能點(diǎn)

body：主要對(duì)本次 commit 的詳細(xì)描述，可以分成多行。

footer：主要放置不兼容變更和 Issue 關(guān)閉的信息。

為了方便代碼的快速提交，body 和 fotter 部分可以省略。

2. 使用介紹

需求開(kāi)發(fā)或者修改 Bug 時(shí)，提交代碼時(shí)要添加對(duì)應(yīng) Jira 編號(hào)：

git commit -m "feat(CHESS-1217): 我的頁(yè)面增加分享入口及分享功能開(kāi)發(fā)"

修改 Bug 時(shí)，需要指明修改代碼所在模塊：

git commit -m "fix(分享): 修改修改部分手機(jī)分享大圖為空問(wèn)題"

沒(méi)有具體模塊、或者多模塊代碼一起提交時(shí)，可使用其他提交方式：

git commit -m "fix(BUG): 修改推送紅點(diǎn)提示邏輯"

3. 相關(guān)工具

Git Hook 自定義攔截腳本：commit-msg

使用環(huán)境：python3.7

使用方式：

打開(kāi)工程目錄下的 .git/hooks 文件夾

將 commit-msg 腳本復(fù)制到文件夾下，即可

全局設(shè)置：通過(guò)以下方式，可全局設(shè)置，每次 git clone 時(shí)，自動(dòng)將 commit-msg 腳本添加到工程的 hooks 目錄中：全局設(shè)置 commit-msg。

其他工具：

Commitizen：輔助撰寫(xiě)合格 Commit message 的工具

Commitlint：Commit message 規(guī)則校驗(yàn)工具

4. 拓展

GitLab 與 Jira 關(guān)聯(lián)

效果：Git Commit 時(shí)，在 message 里面添加工單號(hào)，可在 Jira 對(duì)應(yīng)工單詳情頁(yè)查看到本次提交。

配置：官方文檔。

三、代碼評(píng)審流程

1. 評(píng)審環(huán)節(jié)

代碼評(píng)審發(fā)生在 Feature 分支向 Develop 分支合并的過(guò)程中：

 

Git 流程使用規(guī)范

 

(圖片來(lái)源：ProcessOn 模板)

2. 代碼評(píng)審流程

 

Git 流程使用規(guī)范

 

不同的顏色塊，代表不同的角色

創(chuàng)建一個(gè) Merge Request 可以進(jìn)行多次 Push

開(kāi)發(fā)人員推動(dòng)整個(gè)代碼評(píng)審流程的執(zhí)行，包含及時(shí)通知組員評(píng)審代碼、通知組長(zhǎng)合并代碼等

3. 保護(hù)分支設(shè)置

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

 

Git 流程使用規(guī)范

 

將 master 和 develop 分支設(shè)置為保護(hù)分支，只能是 Maintainers 角色 可以合并請(qǐng)求，并且禁止直接 push 代碼。

 

Git 流程使用規(guī)范

 

通過(guò)以上設(shè)置之后，所有代碼只能通過(guò)創(chuàng)建 Merge Request 的方式合并到 develop 和 master 分支;為了代碼庫(kù)的安全，需要回收 Maintainers 權(quán)限，除組長(zhǎng)外的開(kāi)發(fā)人員都是 Developer 權(quán)限。

4. Merge Request

1. 創(chuàng)建 Merge Request

打開(kāi) Project -> Merge Requests -> New merge request，選擇分支創(chuàng)建合并請(qǐng)求：

 

Git 流程使用規(guī)范

 

選擇源分支，需要合并的代碼所在的分支

選擇目標(biāo)分支，將最新代碼合并到的分支

2. 填寫(xiě)必要信息

 

Git 流程使用規(guī)范
Git 流程使用規(guī)范

 

Title：簡(jiǎn)單總結(jié)本次 Merge 的修改點(diǎn)

Description：詳細(xì)描述修改內(nèi)容，影響范圍等

Assignee：委托人，選擇具有 Maintainers 角色的成員，該成員會(huì)收到合并請(qǐng)求的郵件通知，最后由該成員合并請(qǐng)求

Approvers：一般選擇小組成員，小組成員具有審核代碼權(quán)限，對(duì)不合格代碼可以要求開(kāi)發(fā)者修改

分支選擇，功能分支向 develop 分支合并時(shí)，會(huì)有刪除源分支選項(xiàng)，建議勾選

針對(duì)本次合并的提交，一次合并請(qǐng)求可以包含多次提交

3. 代碼評(píng)審及合并請(qǐng)求

 

Git 流程使用規(guī)范
Git 流程使用規(guī)范

 

只有評(píng)審成員評(píng)審?fù)ㄟ^(guò)時(shí)，合并按鈕才會(huì)高亮，才能合并代碼

參與代碼評(píng)審的成員，認(rèn)為代碼沒(méi)有問(wèn)題時(shí)，可點(diǎn)擊該按鈕

針對(duì)當(dāng)前代碼創(chuàng)建的討論，有討論存在時(shí)，開(kāi)發(fā)者需要及時(shí)解決

如果代碼有問(wèn)題，可直接創(chuàng)建一個(gè)討論，即 3 列表會(huì)增加，開(kāi)發(fā)者修改之后可點(diǎn)擊 5 關(guān)閉討論

代碼修改之后，或者不需要修改，點(diǎn)擊關(guān)閉討論

5. 其他注意事項(xiàng)

1. 提交合并請(qǐng)求時(shí)，先同步最新代碼

提交合并代碼前，建議先執(zhí)行 git fetch 和 git merge/rebase 將 develop 分支下的最新代碼更新到開(kāi)發(fā)分支，再提交合并請(qǐng)求，避免造成沖突。

2. 合并代碼到 master 分支

通過(guò) develop 分支提測(cè)且測(cè)試通過(guò)后，將 develop 分支的代碼合并到 master 分支進(jìn)行發(fā)版，版本發(fā)布完成時(shí)及時(shí)打標(biāo)簽。

四、Git 項(xiàng)目集成構(gòu)建

1. 簡(jiǎn)介

GitLab-CI

GitLab-CI 是 GitLab Continuous Integration(GitLab 持續(xù)集成)的簡(jiǎn)稱(chēng)。

只要在項(xiàng)目倉(cāng)庫(kù)的根目錄添加 .gitlab-ci.yml 文件，并且配置了 Runner(運(yùn)行器)，那么每一次合并請(qǐng)求 MR 或者 push 都會(huì)觸發(fā) CI pipeline。

GitLab-Runner

GitLab-Runner 是 .gitlab-ci.yml 腳本的運(yùn)行器，GitLab-Runner 是基于 GitLab-CI 的 API 進(jìn)行構(gòu)建的相互隔離的機(jī)器(或虛擬機(jī))。GitLab Runner 不需要和 GitLab 安裝在同一臺(tái)機(jī)器上，同時(shí)考慮到 GitLab Runner 的資源消耗問(wèn)題和安全問(wèn)題，也不建議這兩者安裝在同一臺(tái)機(jī)器上。

Pipelines

Pipelines 是定義于 .gitlab-ci.yml 中的不同階段的不同任務(wù)。

Pipelines 可理解為流水線，流水線包含有多個(gè)階段(stages)，每個(gè)階段包含有一個(gè)或多個(gè)工序(jobs)，比如先購(gòu)料、組裝、測(cè)試、包裝再上線銷(xiāo)售，每一次 push 或者 MR 都要經(jīng)過(guò)流水線之后才可以合格出廠。而 .gitlab-ci.yml 正是定義了這條流水線有哪些階段，每個(gè)階段要做什么事。

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

配置以下參數(shù)：

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:

具體配置項(xiàng)的值可參考項(xiàng)目信息(Project -> Settings -> CI/CD -> Runners)：

 

Git 流程使用規(guī)范

 

右側(cè)是創(chuàng)建好的 Runners;對(duì)于多項(xiàng)目可以創(chuàng)建 Shared/Group Runners，多個(gè)項(xiàng)目可以共享，不用一一創(chuàng)建;不同 Runners 的創(chuàng)建，僅僅是 Token 不同。

添加構(gòu)建任務(wù)

在根目錄中創(chuàng)建 .gitlab-ci.yml 文件，具體代碼可參照以下示例。

Android 工程：

stages: # 構(gòu)建步驟

- build

build job:

stage: build

tags: # 根據(jù)tag，選擇執(zhí)行的runner

- tag_0.0.1

only: # 只有在列出的分支合并代碼時(shí)，才會(huì)觸發(fā)構(gòu)建

- develop

script: # 構(gòu)建執(zhí)行的腳本，順序執(zhí)行

- chmod a+x gradlew

- ./gradlew assembleDebug

artifacts: # 構(gòu)建后的產(chǎn)物

paths:

- app_debug/

iOS 工程文件配置類(lèi)似，只是 script 腳本不同;.gitlab-ci.yml 具體語(yǔ)法，可參考以下官方文檔：gitlab-ci 語(yǔ)法。

將代碼 push 到遠(yuǎn)程分支或者合并請(qǐng)求時(shí)，就會(huì)自動(dòng)執(zhí)行腳本：

 

Git 流程使用規(guī)范

 

點(diǎn)擊列表，可看到單個(gè) job 的執(zhí)行情況，包括控制臺(tái)日志輸出和文件產(chǎn)出：

 

Git 流程使用規(guī)范

 

3. GitLab + Jenkins 實(shí)現(xiàn) CI 功能

Jenkins 配置

登錄 Jenkins 賬戶(hù)，打開(kāi)“系統(tǒng)管理” -> “插件管理” -> “可選插件”安裝以下兩個(gè)插件：

 

Git 流程使用規(guī)范

 

打開(kāi)“系統(tǒng)管理” -> “系統(tǒng)設(shè)置” -> “GitLab” 配置 GitLab 服務(wù)：

 

Git 流程使用規(guī)范

 

在 Jenkins 首頁(yè)，打開(kāi)“項(xiàng)目”，“配置” -> “構(gòu)建觸發(fā)器”配置以下信息：

 

Git 流程使用規(guī)范

 

打開(kāi)“高級(jí)”，生成 Secret token，配置 GitLab 的時(shí)候，需要用到：

 

Git 流程使用規(guī)范

 

GitLab 配置

打開(kāi) Project -> Settings -> Integrattions 填寫(xiě)上一步生成的 URL 和 Secret Token 信息：

 

Git 流程使用規(guī)范

 

配置完成，當(dāng) push 代碼或者合并請(qǐng)求時(shí)，會(huì)自動(dòng)觸發(fā) Jenkins 構(gòu)建。

本文由網(wǎng)上采集發(fā)布，不代表我們立場(chǎng)，轉(zhuǎn)載聯(lián)系作者并注明出處：http://m.zltfw.cn/shbk/38997.html

相關(guān)推薦

聯(lián)系我們

在線咨詢(xún)：點(diǎn)擊這里給我發(fā)消息

微信號(hào)：15705946153

工作日：9:30-18:30，節(jié)假日休息