以gitee作为开发流程管理媒介
登陆后创建一个组织
在组织里面进行仓库的创建
正常的导入仓库
进行仓库分支配置
拉入成员
- 进入组织首页点击设置
- 找到成员管理
就可以进行成员管理了
配置issues
issues既能作为项目管理者对项目的进度任务分配，也能作为项目开发人员对项目管理者的问题反馈
添加issues标签
设置便捷标签应用于快速定位业务需求
创建issue并分配到个人，可以指定交付时间
开发规范
分支使用约定
对于分支的管理，我们采用分支开发模式。具体约定如下：
develop分支为当前开发分支（常驻分支），对应下一个上线版本的开发内容，版本固定为1.0.0-SNAPSHOTmaster分支为对应生产版本的分支（常驻分支），对应下一个生产版本的SNAPSHOT，比如1.0.2-SNAPSHOTtags分支里对应了各个生产上线版本（常驻分支），比如1.0.1，由master分支release时自动生成。每次release完成后，需将该版本更新日志列出feat-xxx分支为功能开发分支，当不确定该功能具体上线时间点时，创建功能分支。要求内容尽量原子化，不要大杂烩。确定上线点时合并功能分支至develop分支，合并完成后删除该功能分支。版本为1.0.0-FEAT-XXX-SNAPSHOTfix-xxx分支为紧急修复分支，当线上环境有问题需要紧急修复时，创建修复分支。修复流程为从master分支迁出本分支，修复并测试完成后，合并至master上线后，需要再同步合并至develop分支，完成后删除该修复分支。版本号同master分支 分支命名均为小写，以中横线-做分割。
代码提交约定
- 提交的内容必须本地编译通过，不可以将本地编译不通过的内容提交
- 提交的内容要求原子化，不要一次性提交太多彼此没有关系的修改，可以多次
commit，一次push
提交信息里应包括三个字段：type（必需）、scope（可选）和subject（必需），冒号后有一个空格。
<type>(<scope>): <subject>
比如：
feat(fish-param): 增加参数初始化功能 (#12)
fix(octopus-admin): 解决用户权限问题 (#11)
类型type
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
范围scope
scope用于说明 commit的范围，为本次工程修改的模块名，牵扯多个模块时，可不填。
描述subject
subject是 commit 目的的简短描述，不超过50个字符。
- 每次提交尽量针对某个issue，在内容末尾增加对该issue的参考，采用英文括号包裹。例如：本项目issue：(#30)或者同组其他项目issue：(document#23) 。
- 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
- 第一个字母小写
- 结尾不加句号（.）
