分支管理v1.md 1.9 KB
为保证功能未完成时，不会上线到生产环境产生问题。开发过程中需要进行规范。
bug修复
根据实际情况采用以下两种方式之一
简单性的bug
- 切换到master分支，直接修改，测试，成功后提交并推送到远程服务器
复杂性的bug（修改过程可能影响到其他功能使用）
- 从master分支创建新分支
fix_姓名缩写_日期 - 修改，测试
- 测试通过后，将分支合并到
master分支，并创建Tag，标识发布新版本，系统更新日志里面补充更新内容 - 合并到
master分支后，该分支使命已完成，则删除该分支，后续如果有新bug出现，则重新创建分支进行修复。
新功能开发
- 从master分支创建新分支
dev_姓名缩写_日期或功能名称 - 开发完成或者部分完成需要测试时，合并到
test分支 - 如果功能还有bug，则继续在当前分支进行开发，开发完成后再合并到
test分支进行测试 test分支测试通过后，再将该分支合并到develop分支- 合并后，在
develop分支进行上线前测试 - 测试通过后，将
develop分支合并到master分支，并创建Tag，标识发布新版本，系统更新日志里面补充更新内容 - 合并到
master分支后，该分支使命已完成，则删除该分支，后续如果有新bug出现，则重新创建分支进行修复。
如果新功能开发时间比较漫长，则需要每天将
master分支合并到当前分支里，保证自己分支的代码不落后主分支如果新功能基于另一个开发人员的功能，则可以选择在对方的分支上进行开发，无需另外创建分支
分支合并操作，通过git仓库发起合并请求
