# 如何利用GitHub进行协作开发

## 开发模式
### PR开发流程

![PR开发流程示意图](figure/pr-flow.png "PR开发流程示意图")

1. 上游仓库通常保留Release,  main,  pre 和 dev 三个分支：
   - main分支一般为活跃的开发主版本，受到保护，**不接收下游分支的直接合并**，只可以从dev分支合并, 需管理员在github上手动完成合并
   - pre分支为预发布版本，用于测试与文档维护，不进行任何代码维护（包括注释），只可以从main分支合并而来。
   - dev分支为开发分支，通常不接收直接修改，只允许从dev热分支或下游分支合并
   - dev热分支，也为开发分支，主要针对特定功能或issue的开发或解决
   - Release分支为稳定发布版本，由pre分支对应的测试稳定版本签出合并得到
2. 如果作为开发者，准备对代码进行贡献，可以直接从上游仓库fork到个人仓库；
   - github默认只fork main分支，无特殊需求，可以直接从main主分支添加新功能。下游对应的main分支可以随时同步上游的变化。
   - 如果有其它需求，只能选择fork 所有分支，并选择特定分支进行修改。
3. 如果只是想要使用代码，clone相关分支到本地即可，在需要贡献代码时，再进行fork与pull request 操作
4. 下游开发者，每次代码贡献，**务必从上游fork最新的代码**，再进行修改与合并。main分支时刻保持与上游同步。建议在下游操作时，就解决分支的相关冲突。此外，下游开发者尽可能不要修改下游的main或对应的fork分支，一般通过新建分支，在新分支上进行修改，然后再合并到上游dev或相应的热分支。
5. 在pull request中务必选择dev 开头的分支，或有需要，请联系管理员，新建dev 热分支
6. dev热分支与dev分支的合并均在github或codespace中进行，完成合并后的main分支，务必需要在本地进行初步测试，再合并到pre分支进行预发布版本的测试。
7. 为了让不同开发者的代码尽可能差异最小化，建议开发者尽可能在完成较小功能时，就实现PR，合并到dev分支以及main分支
8. 以上流程为试行，在后期开发过程中再根据实际情况进行调整