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>(<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 构建。
上一篇: github是什么网站(GitHub网站的基本使用)
下一篇: Shell中关于exit 0的那些坑