开发规范一：Git Flow + Gitlab 工作流

分支说明

main 分支

• 发布分支。
• 包含最新稳定版本，每个版本都是该分支上的一个tag。
• 长期分支。
• 保护分支，非Maintainer成员不能直接提交，只能从其他分支合并。

develop 分支

• 主开发分支。
• 新功能或 bug 修复分支都从这里拉取和提合并请求。
• 长期分支。
• 保护分支，非Maintainer成员不能直接提交，只能从其他分支合并。
• 建议设置为仓库默认分支

feature 分支

• 新功能特性分支。
• 从develop分支拉取，开发完毕并自测后需要合并到develop分支。
• 短期分支。
• 命名：feature/发布版本-功能名称。例如：feature/0.2.1-popcode分发。

bugfix 分支

• bug 修复分支。
• 从develop 分支拉取，开发完毕并自测后需要合并到develop分支。
• 短期分支。
• 命名：bugfix/发布版本-功能名称。例如：bugfix/0.2.1-登录报错。

release 分支

• 用于回归测试，联调
• 从develop分支拉取，回归测试完后合并到develop和main。
• 短期分支。
• 涉及测试发版时，需要建立此分支。
• 命名：release/发布版本，例如：release/0.2.1。
• 如果当前项目是多人并行开发，各个feature自测后，合并到develop，由于解决冲突不当，或者逻辑上和别的需求冲突，就会产生新的缺陷，这种情况就需要在release回归测试。

hotfix 分支

• 线上紧急 bug 修复的分支。
• 从main拉取修复，合并到main中，并发布紧急修复版。后续需要将此修复合并到develop分支中。
• 短期分支
• 命名：hotfix/基于版本。例如：hotfix/0.2.0。
• 如果多版本共存，就需要保留hotfix分支，后续该版本再出bug，继续在该版本的hotfix分支上修改，并基于此分支发布修复版。

Feature 开发流程

1. 开发人员基于develop打feature分支，并推送到远端
2. 在 Gitlab 提合并请求，标题里需要标识WIP，例如WIP: Feature/0.1.1 popcode分发
   • WIP：Work In Progress，避免此合并请求被合并
3. 开发功能，并经常push
   • 经常push可以让代码审核者关注进度，以及通过Code Review 提前发现问题。
   • 建议经常更新develop分支，并合并到当前feature分支，第一时间解决冲突，避免放到最后冲突一大堆了才去解决，导致误操作覆盖别人的代码。
   • 同一分支合并使用 git fetch & git rebase 并解决冲突。不同分支合并使用 git fetch & git merge --no-ff 并解决冲突。
4. 功能开发完，自测通过，删除合并请求里的WIP标识，并通知代码审核者。
5. 代码审核者完成Code Review ，成功合并到develop
   • 分支合并需要 PR 中勾选删除源分支。

6. 当前版本的需求都合并到develop后，进入release阶段。基于develop创建该版本的release分支，进行回归测试。
7. 在release分支上解决回归测试的bug。
8. 发起release分支合并到main的合并请求，并进行Code Review。
   • 分支合并需要 PR 中勾选删除源分支。
9. 成功合并后，由Maintainer在main分支上打该版本的tag，然后将release分支合并到develop分支
10. 完成该版本发布

Git 最佳实践(Gitflow)