如何在团队软件开发中正确使用github

工作流总结

提交新功能时要遵循以下工作流。

工作流简单总结：

1. 新建Issue
2. 新建Debug/Feature branch
3. 修改、添加完成后使用Pull Request提交
4. 等待Reviewer审核，并对Reviewer回应进行修改
5. Merge Pull Request合并到main/dev

Branch命名规则

正式软件中，版本控制非常重要，版本之间不能有冲突。因此，正式开发时，应该建立多个分支，开发新功能时应该建立新的分支。

分支	命名	说明
主分支	master	用户使用的正式版本都在主分支发布，正式版本必须可用的，稳定的，可直接发布的版本 不可直接在master branch开发！
开发主分支	dev	涵盖了所有已完成的功能的分支 不可在dev branch开发！所有开发分支请克隆dev进行开发！
功能分支	feature-*	新功能分支，某个功能正在开发阶段
发布版本	release-*	发布定期（未来）要上线的功能
修复bug分支	bugfix-release-*	修复bug分支
紧急修复分支	bugfix-master-*	紧急修复线上代码bug，此分支拥有审核最高priority

各分支介绍

1. 主分支master

• 稳定的、可发布的版本

2. 开发主分支dev

• dev分支用于日常开发，保持最新已开发完全的功能
• 如果想要发布最新dev版本，则把master与dev进行合并
• 请使用dev进行新功能开发，但不能在dev上直接开发：
  用dev为base新建分支->在新分支上开发->merge新分支与开发分支
  

3. 功能分支feature

• 添加新功能前请先在任务软件完成该功能的documentation
• 完成该功能和Merge到dev分支然后删除该分支（即可以理解为这是从dev克隆来的一个分支，在dev基础上加新功能）
  

4. 发布版本release

• 预发布，此分支是在正式发布、合并入master之前的测试分支
• 测试完成后合并入master
• 完成Merge后删除该分支

5. 修复bug分支

• 预发布bug修复，修复完毕合并入release：请在命名是标注对应的release版本！
• 完成Merge后删除该分支
  

6. 紧急修复分支

• bugfix-master需和最新master分支保持同步，此分支用于master的bug修补
• 此分支拥有最优先审核排名
• bug解决之后与master和dev进行合并
• 完成Merge后删除该分支

Github工作流程

Create Branch

github网站操作

1. 选择要复制的branch并点击
   
   2.输入新分支的名字并点击creach branch
   
   git操作
   （略）

Github Pull Request

如果你想要使用合并请求（pull request），但是你之前从来没有提交过代码，请遵循以下步骤：

• 搭建开发环境
• 如果是重大修改，请先创建一个issue或者表明正在处理已存的issue

之后：

• 新建一个分支 (add new branch)
  采用$ git checkout -b issue_1 或者在git desktop: current branch -> new branch
• 在分支进行修改，修改应遵循文件基础格式
• 运行测试
• 提交合并请求（pull request）

pull request步骤
（略）
pull request格式

• 所有branch合并入main或者dev分支都需要提交Pull Request

ADD FEATURE:

### 与此次Pull request关联的功能doc（通常在任务软件里能找到）

### 功能描述

### 测试用例(Use Cases)

### 功能效果截图

BUG FIX:

### 与此次Pull request关联的issue

### 修改描述

### 测试用例(Use Cases)

### 修复后的效果截图

### 修复后可能出现、存在的漏洞

• 标题范例：
  尝试用x方法实现y， 优化x，修复在x状态下对y的异常处理，加入x新功能等等
  注意事项：

• 每个Pull Request请尽量围绕一个issue，避免超大Pull Request
  请详细描述进行的修改，不要假定对方（Reviewer）熟悉事情的前因后果

New issue步骤
（略）
New issue格式

### 问题简短介绍

### 重现步骤
  1.
  2.
  ...
 
### bug/错误代码截图与报错信息