赞
踩
分组(Group)是以两级来进行管理。首先以所属产品域的大类,建立一级分组,然后在下面建立二级分组。
项目统一放在二级分组下,编码结构:项目描述 + 备注,以’-’为分隔。
由开发组leader或研发负责人在分组下根据仓库命名创建项目代码仓库。团队内成员,建议在一级分组上分配;外包人员,根据开发所涉及的具体项目逐个分配对应的二级分组权限。
角色 | 描述 | 权限范围 |
---|---|---|
Owner | 项目所有者 | 可以设置项目的访问权限-Visibility Level、删除项目、迁移项目、管理组成员;开发组leader设置该角色。 |
Maintainer | 项目维护者 | 可以创建项目、添加 tag 、保护分支、添加项目成员、编辑项目;研发负责人设置该角色。 |
Developer | 开发人员 | 可以clone、开发、commit、push。研发人员设置该角色。 |
Reporter | 测试人员 | 可以克隆代码,不能提交。测试人员、产品经理设置该角色。 |
Guest | 访客 | 可以创建issue、发表评论、不能读写版本库。 |
名称 | 命名规则 | 说明 |
---|---|---|
master | - | 稳定版本 |
develop | dev/develop | 最新版本 |
release | release/创建时间(YYYYMMDD) | 发布新版本 |
feature | feature/功能点名称 | 实现新特性 |
hotfix | hotfix/禅道bug号 | 修复线上紧急Bug |
bugfix | bugfix/禅道bug号 | 修复普通Bug |
创建项目时,会针对不同环境创建几个常用分支:
版本号为三位以‘.’分割的数字组成。第一个数字是主版本。第二个数字是次版本。第三个数字是补丁版本(hotfix 类的更新)。
设置提交代码的用户名称和邮箱为本人工号和工作邮箱。
提交规范一般包括:标题(类型、精简总结)、内容、备注 。其中精简总结和类型是必填的,其余都是选填。
名称 | 命名规则 |
---|---|
feat | 新功能 |
fix | 修复bug |
docs | 文档变更 |
style | 代码格式优化 |
refactor | 重构代码 |
perf | 性能、页面优化 |
test | 增加测试用例、单元测试 |
revert | 回退版本 |
build | 打包 |
chore | 构建过程或辅助工具的变动 |
必填的精简总结是非常重要的,一般是是总结概括的文字。要让人一眼就能看出来主要提交了什么,是添加了功能还是解决了问题,同时它也是大多数git管理工具默认展示的一行。需在第二行加上,禅道需求/任务/bug的id。如:
–fix: 修复了页面卡顿的bug。
–story: 1024
内容主要填写详细的改动内容。如果精简总结写的比较完美,内容不写也是没关系。如果更改确实很多,并且时间充裕的话,把本次提交内容的实现、需求以及背景都填写,是很负责的做法。比如:
–fix: 修复了页面卡顿的bug
–story: 123
在网络不好时,渲染页面的接口被重复调用。
此次更改了页面接口的逻辑判定,在并发请求中……采用了……所以……。
备注主要作用就是有一些额外的hook补充,比如提交记录之后,自动触发代码联动编译,或者自动生成git提交的通知。
不用生成readme文件
本地创建新目录,执行如下命令(注意替换成对应的仓库地址)
git clone --bare git@gitlab.old.com:group/xxxService.git
执行步骤二后本地目录会生成一个名为 xxxService.git 的目录,进入此目录,执行如下命令:
cd xxxService.git
git push –-mirror https://gitlab.new.com/test/xxxService.git
完成以上3个步,代码仓迁移即已完成。由于大多数项目之前已在本地clone并进行开发,需要修改已有代码的远程仓库地址。进入已有代码目录,执行如下命令:
git remote set-url origin https://gitlab.new.com/test/xxxService.git
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。