2021-01-28 gitflow工作流总结

1:新建一个项目,默认会有一个master分支,从master分支创建develope分支

2:项目启动进入开发阶段,从develope分支拉取feature分支给组内成员,命名方式为feature/负责的功能;比如负责的是个人信息功能,可以命名为feature/personal,如果多人负责同一功能,可以命名为feature/姓名首字母+功能,比如feature/zs-personal,
分支建好之后,组内成员在feature分支进行开发;此时需要注意:feature分支的代码最少每天提交到远程一次,最好的是完成一个小功能就提交一次

3:feature分支上的功能开发完成后,组内成员需要发起合并分支的请求,将feature分支的代码合并到develope分支,组长收到请求后进行合并,合并完成后feature分支可以删掉;
此时需要注意:个人觉得feature分支上的代码可以在完成一个较大功能后就发起一次合并请求,此时可以不删除feature分支,等全部功能完成再删除,之所以要经常合并,是为了
有效检查组员的进度和代码质量,防止意外发生

4:功能开发完成后,所有的代码都合并到develope分支,然后从develope分支拉取release分支,release分支的命名方式为release/版本号,比如release/v1.0.1;从release分支拉取bugfix分支来修复测试提出的bug,
bugfix分支的命名方式为:bugfix/bug编号,如果觉得一个bug就拉一个分支有些繁琐,可以每人拉取一个bugfix分支,命名方式为bugfix/姓名首字母;每修复一个bug就往develope分支合并一次代码;
bug合并阶段,组员可以提交合并请求由组长合并到release分支,也可以由组员自己合并,看实际情况来定

5:测试完毕，要发版的时候,将release分支代码合并到master分支上,再将master分支代码合并到develope分支上,并在master分支上打tag合;此时需要注意:并成功后不要删除release分支

6:版本发布完成后，release分支按照标准是要删掉的，但是我个人觉得可以保留前两个版本的release分支，里面的代码不要改动，有问题时可以直接切换回release分支，就不用从tag拉取代码了

7:线上有紧急bug需要处理时，从master分支拉hotfix分支进行处理(命名方式参考bugfix)，bug修复并测试完成后代码合并到master分支（此时hotfix不删除），再从master分支合并到develop分支，从master分支合并到release分支，并从master分支打tag

8:代码提交时的描述格式:
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

9:分支命名格式需要明确要求,防止出现命名格式五花八门的情况

10:怎么发起合并请求？怎么审核组员发出的合并请求？
这两个问题需要看使用的代码管理工具,以gitlab为例,进入到项目里面,在左侧会有Merge Request的选项,就可以创建和处理合并请求了