本文最后更新于 1043 天前，其中的信息可能已经有所发展或是发生改变。
分支说明
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 开发流程
-
开发人员基于
develop打feature分支，并推送到远端 -
在 Gitlab 提合并请求，标题里需要标识
WIP，例如WIP: Feature/0.1.1 popcode分发WIP：Work In Progress，避免此合并请求被合并
-
开发功能，并经常push
- 经常push可以让代码审核者关注进度，以及通过Code Review 提前发现问题。
- 建议经常更新
develop分支，并合并到当前feature分支，第一时间解决冲突，避免放到最后冲突一大堆了才去解决，导致误操作覆盖别人的代码。 - 同一分支合并使用
git fetch & git rebase并解决冲突。不同分支合并使用git fetch & git merge --no-ff并解决冲突。
-
功能开发完，自测通过，删除合并请求里的
WIP标识，并通知代码审核者。 -
代码审核者完成Code Review ，成功合并到
develop-
分支合并需要 PR 中勾选删除源分支。
-
-
当前版本的需求都合并到
develop后，进入release阶段。基于develop创建该版本的release分支，进行回归测试。 -
在
release分支上解决回归测试的bug。 -
发起
release分支合并到main的合并请求，并进行Code Review。- 分支合并需要 PR 中勾选删除源分支。
-
成功合并后，由Maintainer在
main分支上打该版本的tag，然后将release分支合并到develop分支 -
完成该版本发布
