您当前的位置:首页 > 淘宝百科

git使用开发流程(公司新人git使用教程)

时间:2023-01-09 08:01:10

git使用开发流程(公司新人git使用教程)

一、分支管理规范

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 类型,修改的类型级别:

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 构建。

分支

|| 相关文章
    无相关信息
最新文章